Geolocation and maps
“Where is the user?” can mean several different things in a business application.
The application may use an address the user entered, browser or device coordinates, an approximate location inferred from an IP address, or coordinates already stored for a customer, asset, or site. Those sources have different accuracy and privacy implications. PHPRunner can combine stored locations, browser geolocation, maps, and application rules once the correct source has been chosen.
A user or administrator supplies a street address or location record.
The browser requests permission and can return device latitude and longitude when available.
Provides an approximate network location, useful for broad regional context rather than precise positioning.
Customers, assets, facilities, or jobs already have latitude and longitude in the database.
Quick answer: Choose the location source based on the business task. Use precise device coordinates only when the user grants access and precision is useful; use stored addresses or coordinates for known business objects; treat IP location as approximate.
Latitude and longitude are inputs, not the feature itself.
A user may deny permission or use a device that cannot provide a useful result.
Design the workflow so the application still behaves sensibly when geolocation is unavailable. An entered address, selected site, or stored customer location can provide a fallback.
Also explain why location is requested. Users are more likely to understand a request such as “use my location to show the nearest service center” than an unexplained permission prompt on login.
Repeated geocoding is unnecessary when a business location rarely changes.
If a customer's address, warehouse, asset, or service site is part of the business data, storing latitude and longitude can make map and distance operations faster and more predictable.
Update the coordinates when the address changes, and keep the human-readable address as the business record rather than replacing it with coordinates.
The goal is to keep the architecture understandable while reducing repetitive application work.
PHPRunner can collect location data, store coordinates, display maps, filter records, and integrate geocoding or mapping services through custom code and plugins.
| Need | PHPRunner approach |
|---|---|
| Location capture | Use browser-side geolocation when the workflow needs the user's current position. |
| Stored locations | Keep addresses and coordinates in normal database fields. |
| Maps | Display records on maps and use mapping-related plugins or integrations. |
| Business logic | Use distance, region, assignment, or geocoding rules in application events and queries. |
Location is most valuable when its source and purpose are explicit.
Start with the business question—nearest what, map which records, verify which visit—then choose the least intrusive location source that answers it.
That keeps geolocation useful instead of turning it into a permission request with no clear value to the user.