starred/netbox
1
0
Fork 0
mirror of https://github.com/netbox-community/netbox.git synced 2026-01-11 21:10:29 +01:00
Code Issues 273 Packages Projects Releases 10 Wiki Activity

Add to contacts latitude and longitude plus the map controls that exist on sites #11178

New Issue
Closed
opened 2025-12-29 21:41:24 +01:00 by adam · 5 comments
adam commented 2025-12-29 21:41:24 +01:00
Owner
Copy Link

Originally created by @sol1-matt on GitHub (May 15, 2025).

NetBox version

v4.2.8

Feature type

Change to existing functionality

Proposed functionality

Netbox Site objects contains an address field along with latitude and longitude fields. Sites that are saved with these values have a "Map" button added to the UI which is a link https://maps.google.com/?q=.

Netbox Contact objects contains an address field but there is no latitude and longitude fields or "Map" button on the address field when the Contact is saved.

The proposed functionality to add is 2 new fields on contact for latitude and longitude as well as a "Map" button on the address field and new latitude and longitude fields the same as appears on Site objects.

Note: this FR is for adding existing functionality in Sites to Contacts, contacts also have other values such as email and phone numbers that may also benefit from links.

Use case

Extends consistency in Netbox for objects that have an Address field in how they behave.

Database changes

add latitude and longitude fields to db for Contact object

External dependencies

No response

Originally created by @sol1-matt on GitHub (May 15, 2025). ### NetBox version v4.2.8 ### Feature type Change to existing functionality ### Proposed functionality Netbox Site objects contains an address field along with latitude and longitude fields. Sites that are saved with these values have a "Map" button added to the UI which is a link https://maps.google.com/?q=<field values>. Netbox Contact objects contains an address field but there is no latitude and longitude fields or "Map" button on the address field when the Contact is saved. The proposed functionality to add is 2 new fields on contact for latitude and longitude as well as a "Map" button on the address field and new latitude and longitude fields the same as appears on Site objects. _Note: this FR is for adding existing functionality in Sites to Contacts, contacts also have other values such as email and phone numbers that may also benefit from links._ ### Use case Extends consistency in Netbox for objects that have an Address field in how they behave. ### Database changes add latitude and longitude fields to db for Contact object ### External dependencies _No response_
adam added the type: featurepending closurestatus: revisions needed labels 2025-12-29 21:41:25 +01:00
adam closed this issue 2025-12-29 21:41:25 +01:00
adam commented 2025-12-29 21:41:25 +01:00
Author
Owner
Copy Link

@jeremystretch commented on GitHub (May 15, 2025):

Contacts are intended to represent humans rather than specific locations. What is your use case for tracking coordinates for a contact?

@jeremystretch commented on GitHub (May 15, 2025): Contacts are intended to represent humans rather than specific locations. What is your use case for tracking coordinates for a contact?
adam commented 2025-12-29 21:41:26 +01:00
Author
Owner
Copy Link

@sol1-matt commented on GitHub (May 16, 2025):

  • Contacts already have an address field which is a reasonable bit of information about that contact, where they are located.
  • A look up on addresses using a maps button is useful if we ever need to see where that person is located.
  • Address fields don't always map well though (depending on what is entered specifically) and so the location lookup could fail.
  • Lat/Long is a standard for mapping locations that is 100% reliable.
  • It would improve consistency of Netbox behavior for objects with address fields to have both address, latitiude and longitude with accompanying buttons.

Longer version
The use case for Lat/Long would be to allow a 100% reliable standard for mapping locations to accompany the address field. This has 2 advantages for address lookup

  • People who have no idea on how to interpret a written address for a given location and have a map lookup fail have a alternate solution that is 100% reliable in lat/long.
  • External systems, which can be are blocked by bad address information, can use (and sometimes only accept) lat/long co-ordinates.

A 3rd advantage for Netbox is it add's consistency in that address location based information can be stored as human readable/interpretable text boxes (with all the weird accompanying instructions necessary "use the green door and go up 2 flights of stair then take the red door at the end of the hall down to the first floor") and by lat/long in reliable mapping standard. This already occurs on Site objects so adding Lat/long to Contact objects improves consistency between the same functionally on separate objects..

Practical example
A practical use case for this would be technicians spread over a large geographical area. With lat/long on Contact Netbox could be used as a source of truth for

  • an external system that requires lat/long to display their locations on a map
  • and external system to cross reference with Site lat/long to find the closest Contact for a given site, tenant, device, etc..
  • by people from inside Netbox when the address information added doesn't return sane google search results to know where they are based.

A large part of my suggesting Lat/Long be added to contact is because it exists on the Site object.
Having both an address and lat/long on site has proved incredibly useful as the lat/long is a 100% reliable way to map an address where as address lookup doesn't always return a result or a sane result (hello addresses that various address lookup systems return results off the coast of Africa, aka lat/long 0,0) it can contains how to get then instructions that lat/long doesn't have.

@sol1-matt commented on GitHub (May 16, 2025): - Contacts already have an address field which is a reasonable bit of information about that contact, where they are located. - A look up on addresses using a maps button is useful if we ever need to see where that person is located. - Address fields don't always map well though (depending on what is entered specifically) and so the location lookup could fail. - Lat/Long is a standard for mapping locations that is 100% reliable. - It would improve consistency of Netbox behavior for objects with address fields to have both address, latitiude and longitude with accompanying buttons. **Longer version** The use case for Lat/Long would be to allow a 100% reliable standard for mapping locations to accompany the address field. This has 2 advantages for address lookup - People who have no idea on how to interpret a written address for a given location and have a map lookup fail have a alternate solution that is 100% reliable in lat/long. - External systems, which can be are blocked by bad address information, can use (and sometimes only accept) lat/long co-ordinates. A 3rd advantage for Netbox is it add's consistency in that address location based information can be stored as human readable/interpretable text boxes (with all the weird accompanying instructions necessary "use the green door and go up 2 flights of stair then take the red door at the end of the hall down to the first floor") and by lat/long in reliable mapping standard. This already occurs on Site objects so adding Lat/long to Contact objects improves consistency between the same functionally on separate objects.. **Practical example** A practical use case for this would be technicians spread over a large geographical area. With lat/long on Contact Netbox could be used as a source of truth for - an external system that requires lat/long to display their locations on a map - and external system to cross reference with Site lat/long to find the closest Contact for a given site, tenant, device, etc.. - by people from inside Netbox when the address information added doesn't return sane google search results to know where they are based. _A large part of my suggesting Lat/Long be added to contact is because it exists on the Site object. Having both an address and lat/long on site has proved incredibly useful as the lat/long is a 100% reliable way to map an address where as address lookup doesn't always return a result or a sane result (hello addresses that various address lookup systems return results off the coast of Africa, aka lat/long 0,0) it can contains how to get then instructions that lat/long doesn't have._
adam commented 2025-12-29 21:41:26 +01:00
Author
Owner
Copy Link

@github-actions[bot] commented on GitHub (May 23, 2025):

This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.

@github-actions[bot] commented on GitHub (May 23, 2025): This is a reminder that additional information is needed in order to further triage this issue. If the requested details are not provided, the issue will soon be closed automatically.
adam commented 2025-12-29 21:41:26 +01:00
Author
Owner
Copy Link

@arthanson commented on GitHub (May 29, 2025):

This is not really appropriate for the contact model and what it is used for. Instead you create a site to represent the site and attach contacts to them. If you do what this functionality - this would be a good idea for a plugin, we would not be looking at putting this in core.

@arthanson commented on GitHub (May 29, 2025): This is not really appropriate for the contact model and what it is used for. Instead you create a site to represent the site and attach contacts to them. If you do what this functionality - this would be a good idea for a plugin, we would not be looking at putting this in core.
adam commented 2025-12-29 21:41:26 +01:00
Author
Owner
Copy Link

@sol1-matt commented on GitHub (May 30, 2025):

This is not really appropriate for the contact model and what it is used for.

I'm unsure why you think this, the contact model is already used for storing address information, it has a existing field called address.

Instead you create a site to represent the site and attach contacts to them.

While technically possible this seems like a poor data outcome

  • adding sites that are never used on anything other than a single contact object
  • that contact objects address field duplicates the site object address field.

If you do what this functionality - this would be a good idea for a plugin

My understanding is plugin's can't alter core netbox models. A better roll your own solution would be to add custom fields to contact, though that doesn't give us the "maps" button. I'm not sure if a plugin could add a "maps" button functionality either.

we would not be looking at putting this in core

No problem, custom fields can be used to achieve something similar. This struck me as a inconsistency between site address functionality and contact address functionality.

Thank you for considering it.

@sol1-matt commented on GitHub (May 30, 2025): > This is not really appropriate for the contact model and what it is used for. I'm unsure why you think this, the contact model is already used for storing address information, it has a existing field called `address`. > Instead you create a site to represent the site and attach contacts to them. While technically possible this seems like a poor data outcome * adding sites that are never used on anything other than a single contact object * that contact objects `address` field duplicates the site object `address` field. > If you do what this functionality - this would be a good idea for a plugin My understanding is plugin's can't alter core netbox models. A better roll your own solution would be to add custom fields to contact, though that doesn't give us the "maps" button. I'm not sure if a plugin could add a "maps" button functionality either. > we would not be looking at putting this in core No problem, custom fields can be used to achieve something similar. This struck me as a inconsistency between site address functionality and contact address functionality. Thank you for considering it.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
beta
breaking change
complexity: high
complexity: low
complexity: medium
needs milestone
netbox
pending closure
plugin candidate
pull-request
Mirrored from GitHub Pull Request
 severity: high
severity: low
severity: medium
status: accepted
status: backlog
status: blocked
status: duplicate
status: needs owner
status: needs triage
status: revisions needed
status: under review
topic: GraphQL
topic: Internationalization
topic: OpenAPI
topic: UI/UX
topic: cabling
topic: event rules
topic: htmx navigation
topic: industrialization
topic: migrations
topic: plugins
topic: scripts
topic: templating
topic: testing
type: bug
type: deprecation
type: documentation
type: feature
type: housekeeping
type: translation
No Label pending closure status: revisions needed type: feature
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/netbox#11178
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?