Is your feature request related to a problem? Please describe.
The map's navigation is subnet drill-down: first octet, then second, then third. That is an odd organising principle for a geographic map.
Devices in one building routinely sit in different subnets, and one subnet can span continents. The IP hierarchy is doing the job that Sites or groups should be doing, and it produces a tree whose branches have no relationship to where anything physically is.
It also drives most of the plugin's structural complexity. The traversal, gpsmap_subnet_prefixes(), the artefact naming, and the IPv4-only address filter in #104 all exist to serve this model.
Describe the solution you'd like
Navigate by Site, with subnet drill-down kept as an option for anyone relying on it.
Cacti already models Sites with addresses and coordinates, so this is not new data. #2 and #4 propose Sites integration as a setup convenience, and that framing undersells it: the stronger argument is that it fixes the navigation model rather than only prefilling coordinates.
Describe alternatives you've considered
Grouping by Device Template, or by the existing groupnum used for coverage overlays. Both are already in the data model, but neither carries a location the way a Site does.
Additional context
Sequencing matters here. If Sites become the primary navigation, the octet dependency in #104 largely disappears and IPv6 support becomes much smaller. Doing IPv6 prefix handling first, then replacing the model, would be work thrown away.
Related: #2, #4, #104.
Is your feature request related to a problem? Please describe.
The map's navigation is subnet drill-down: first octet, then second, then third. That is an odd organising principle for a geographic map.
Devices in one building routinely sit in different subnets, and one subnet can span continents. The IP hierarchy is doing the job that Sites or groups should be doing, and it produces a tree whose branches have no relationship to where anything physically is.
It also drives most of the plugin's structural complexity. The traversal,
gpsmap_subnet_prefixes(), the artefact naming, and the IPv4-only address filter in #104 all exist to serve this model.Describe the solution you'd like
Navigate by Site, with subnet drill-down kept as an option for anyone relying on it.
Cacti already models Sites with addresses and coordinates, so this is not new data. #2 and #4 propose Sites integration as a setup convenience, and that framing undersells it: the stronger argument is that it fixes the navigation model rather than only prefilling coordinates.
Describe alternatives you've considered
Grouping by Device Template, or by the existing
groupnumused for coverage overlays. Both are already in the data model, but neither carries a location the way a Site does.Additional context
Sequencing matters here. If Sites become the primary navigation, the octet dependency in #104 largely disappears and IPv6 support becomes much smaller. Doing IPv6 prefix handling first, then replacing the model, would be work thrown away.
Related: #2, #4, #104.