RE: SNMP syslocation field for GPS coordinates, and use with automation tools
Yes. But don’t just put in coordinates... Put in other details and use a standard separator 😊 alan
Yes, that's along the lines of what I was thinking. Pre-define a certain number of columns of data that will fit in the snmp syslocation field in most devices (some vendors have surprisingly short string length limits, grrrrrr). And use something like a pipe delimited CSV format in that field, so it has the comma separated decimal degrees lat/long in one column, and human readable street address in another. Also worth noting that many recent SNMP-enabled, high capacity point to point microwave radios have built in GPS receivers for timing and location purposes, which gather elevation data (in meters above MSL usually). Perhaps a column for elevation in meters MSL. The sort of data that is useful for a mobile network operator with thousands of point to point RF links on rooftops and towers, for auditing and compliance purposes. On Fri, Dec 9, 2016 at 2:09 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Yes. But don’t just put in coordinates... Put in other details and use a standard separator 😊
alan
Since we all live on standards, I can suggest RFC7946, GeoJSON (https://tools.ietf.org/html/rfc7946) for all of your location specification needs: { "type" : "Point", "coordinates" : [ -121.556359, 39.5137752 ] } or one line (55 characters, no spaces, hopefully short enough): {"type":"Point","coordinates":[-121.556359,39.5137752]} GeoJSON supports "properties" which you can define how you like: { "type" : "Point", "coordinates" : [ -121.556359, 39.5137752 ], "properties" : { "address" : "121 Gigawatts Ave, Springfield, OH 45501 US", "hardware" : "Cisco 2924", "elevation" : "124m" } } Note that many formats now list Longitude first, Latitude second. http://www.macwright.org/lonlat/ I tend to try to offer/use machine-readable formats first, then human-readable, because I live for automation. GeoJSON benefits from being both. Beckman On Fri, 9 Dec 2016, Eric Kuhnke wrote:
Yes, that's along the lines of what I was thinking. Pre-define a certain number of columns of data that will fit in the snmp syslocation field in most devices (some vendors have surprisingly short string length limits, grrrrrr). And use something like a pipe delimited CSV format in that field, so it has the comma separated decimal degrees lat/long in one column, and human readable street address in another.
Also worth noting that many recent SNMP-enabled, high capacity point to point microwave radios have built in GPS receivers for timing and location purposes, which gather elevation data (in meters above MSL usually). Perhaps a column for elevation in meters MSL. The sort of data that is useful for a mobile network operator with thousands of point to point RF links on rooftops and towers, for auditing and compliance purposes.
On Fri, Dec 9, 2016 at 2:09 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Yes. But don’t just put in coordinates... Put in other details and use a standard separator 😊
alan
--------------------------------------------------------------------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ---------------------------------------------------------------------------
This is an excellent suggestion and I'll do more research into use of the geojson format from this RFC. Looks very similar to data that can be fed through a small perl or python script to batch output google earth KML format files, to give people a quick and easy GUI overview of an area. My thought on the one line format is: {"type":"Point","coordinates":[-121.556359,39.5137752]} It may be better to just put the raw coordinates as "-121.556359,39.5137752" in a specific pipe delimited place in the snmp location string on the device, and have the python script running on the system that is batch-querying all of the devices create the geojson on its side after retrieving the coordinates, rather than putting the geojson format in the device itself. This will hopefully allow for enough length to put a full human readable street address in the syslocation field along with the gps coordinates on even the most manufacturer-hobbled of devices. As for the lat/long vs long/lat format question, that is a tough one... Many users who've been using google maps or google earth are accustomed to pasting in coordinates in a format like 39.5137,-121.5563 (lat/long), but as that URL points out a large amount of GIS software does it the other way around. I've seen a lot of other software not listed on that page which operates in the format lat,long for human data entry of coordinates, or when it uses two different fields for lat and long (in a GUI or its backend storage), always places the lat field first and long second. On Mon, Dec 12, 2016 at 9:36 AM, Peter Beckman <beckman@angryox.com> wrote:
Since we all live on standards, I can suggest RFC7946, GeoJSON (https://tools.ietf.org/html/rfc7946) for all of your location specification needs:
{ "type" : "Point", "coordinates" : [ -121.556359, 39.5137752 ] }
or one line (55 characters, no spaces, hopefully short enough):
{"type":"Point","coordinates":[-121.556359,39.5137752]}
GeoJSON supports "properties" which you can define how you like:
{ "type" : "Point", "coordinates" : [ -121.556359, 39.5137752 ], "properties" : { "address" : "121 Gigawatts Ave, Springfield, OH 45501 US", "hardware" : "Cisco 2924", "elevation" : "124m" } }
Note that many formats now list Longitude first, Latitude second. http://www.macwright.org/lonlat/
I tend to try to offer/use machine-readable formats first, then human-readable, because I live for automation. GeoJSON benefits from being both.
Beckman
On Fri, 9 Dec 2016, Eric Kuhnke wrote:
Yes, that's along the lines of what I was thinking. Pre-define a certain
number of columns of data that will fit in the snmp syslocation field in most devices (some vendors have surprisingly short string length limits, grrrrrr). And use something like a pipe delimited CSV format in that field, so it has the comma separated decimal degrees lat/long in one column, and human readable street address in another.
Also worth noting that many recent SNMP-enabled, high capacity point to point microwave radios have built in GPS receivers for timing and location purposes, which gather elevation data (in meters above MSL usually). Perhaps a column for elevation in meters MSL. The sort of data that is useful for a mobile network operator with thousands of point to point RF links on rooftops and towers, for auditing and compliance purposes.
On Fri, Dec 9, 2016 at 2:09 PM, Alan Buxey <A.L.M.Buxey@lboro.ac.uk> wrote:
Yes. But don’t just put in coordinates... Put in other details and use a
standard separator 😊
alan
------------------------------------------------------------ --------------- Peter Beckman Internet Guy beckman@angryox.com http://www.angryox.com/ ------------------------------------------------------------ ---------------
On Fri, 09 Dec 2016 22:09:40 +0000, Alan Buxey said:
Yes. But donât just put in coordinates... Put in other details and use a standard separator
You want to tell that to the creator of some software I recently encountered that used a non-breaking space rather than a tab, or comma, or other sane values? :)
If you think that's bad, the public copy of the entire Industry Canada licensed frequency database (for every type of radio system, nationwide) comes in a giant space delimited text file with many database fields truncated when they export it from whatever ancient database system they're using. Nevermind that the owner/control entity fields and many other fields also contain spaces. The FCC version which is much more sane and usable is a pipe delimited CSV format file with no fields cut off. On Fri, Dec 9, 2016 at 2:40 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Fri, 09 Dec 2016 22:09:40 +0000, Alan Buxey said:
Yes. But don’t just put in coordinates... Put in other details and use a standard separator
You want to tell that to the creator of some software I recently encountered that used a non-breaking space rather than a tab, or comma, or other sane values? :)
participants (4)
-
Alan Buxey -
Eric Kuhnke -
Peter Beckman -
Valdis.Kletnieks＠vt.edu