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 :blush:


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.

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? :slight_smile:

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.

Since we all live on standards, I can suggest RFC7946, GeoJSON
( for all of your location specification

     "type" : "Point",
     "coordinates" : [

or one line (55 characters, no spaces, hopefully short enough):


GeoJSON supports "properties" which you can define how you like:

     "type" : "Point",
     "coordinates" : [
     "properties" : {
       "address" : "121 Gigawatts Ave, Springfield, OH 45501 US",
       "hardware" : "Cisco 2924",
       "elevation" : "124m"

Note that many formats now list Longitude first, Latitude second.

I tend to try to offer/use machine-readable formats first, then human-readable,
because I live for automation. GeoJSON benefits from being both.


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:


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.