Anyone that has used a recent version of OpenNMS has probably noticed that the default home page view now includes an openstreetmap based view of node/device status, by geographical location. Section 18.3 here: https://docs.opennms.org/opennms/releases/latest/guide-admin/guide-admin.htm... https://wiki.opennms.org/wiki/Geographical_Maps example image here: https://www.tecmint.com/wp-content/uploads/2019/05/opennms-default-admin-das... While customizing a newly setup opennms VM for a unique purpose, I began thinking that there's two possible ways to go about accurately placing nodes on such a map, on a very large scale, with scripting/automation in the provisioning and monitoring process. *Method 1 *(as opennms does now): As defined in RFC3418, put the standard street address of the node in the SNMP sysLocation field. Typically in a human readable text format that would be understood when posted to a geolocation API SaaS. Example being: 2200 6th Avenue, Seattle WA 98121 sysLocation OBJECT-TYPE SYNTAX DisplayString (SIZE (0..255)) MAX-ACCESS read-write STATUS current DESCRIPTION "The physical location of this node (e.g., 'telephone closet, 3rd floor'). If the location is unknown, the value is the zero-length string." ::= { system 6 } The above is dependent on a few things. First, every node needs to have a standard format street address entered into its sysLocation field. But what if you have a telecom tower site on a mountain or hillside? What if it's a node in a developing nation environment where standard third-party geolocation API providers (S.18.3 of the opennms documentation) can't resolve anything? What if it's a device that moves around, like a router on an ocean going vessel or aircraft? *Method 2 *(backwards compatible, possibly an improvement): Treat the 255 character sysLocation field as a rudimentary three column CSV file with pipe delimiters. Put the standard human readable description of the node location in the first column. Populate the second column with the latitude and longitude in WGS84 decimal degree format, such as: Suite 402 2200 6th Ave, Seattle WA 98121|47.616380|-122.341673 Where both columns have six decimal places of precision Column 2 is positive integer if north of the equator Column 3 is negative integer if west of Greenwich. Optional 4th column: Elevation in metres, MSL In the method 2 example described above, opennms can be customized to retrieve the lat/long from sysLocation and place nodes on the dashboard, rendering the underlying map from a self-hosted openstreetmap intranet server without needing to call an external geolocation API. Provided that the data provisioned into the CPE/node in the first place is accurate (this is absolutely a GIGO problem), node locations for difficult-to-geocode install locations should become much more accurate. *Some issues that may be encountered:* Very old or improperly implemented snmpd on some devices does not support a 255 character field length, sometimes not even 100 characters. Varies greatly by vendor implementation. Provisioning and configuration system for nodes need an automated way to enter those lat/long coordinates into columns 2 and 3 in a scripted, automated way. In an example of small 1/10GbE capable business-class ISP CPE demarc devices, *perhaps* as the result of a provisioning system's call to a geolocation API. But with some sort of optional step for configuring a node in a location that won't geocode - such as having a provisioning tech manually scroll to and click a location on a map in a browser. For ISPs with large numbers of CPE endpoint/stub nodes that don't presently have valid sysLocation, it will be a manually laborious one-time process to hunt down all extant CPEs and verify their street address vs customer records, google maps/bing maps/openstreetmap, and manually edit the sysLocation field. Environments that would have many nodes expected to fail third-party geolocation APIs, would probably want to customize some sort of click-on-map GUI for the persons doing the provisioning and hand-off of CPEs to field installation techs. Or possibly using GPS data acquired from an installation technician's mobile phone (standard iOS and Android browser APIs for requesting GPS data), as a custom data field in a ticketing system. Data from that field in the ticketing system could then be fed to another piece of software and pushed to a script to write the sysLocation. *Possibly outside scope*: It's possible to self host your own openstreetmap tile server. The vector data for the entire world is freely available to download. The tile rendering engine and all software needed to set it up is all open source. This can be implemented for ISP management/monitoring networks (NOC map dashboard functionality, etc) that for security reasons have no connection whatsoever to the global routing table. Nodes that move around because they're mounted on some sort of vehicle may be able to update and rewrite their own SNMP sysLocation field from GPS data. Would require custom scripting or being accompanied by a very small embedded Linux system with serial interface to a low-cost GPS chipset. That's a data acquisition system that already exists for some category of equipment such as two-way satellite terminals on ocean going vessels.