How do maps and location data fit into a business application?
Explore maps, geographic records and business workflows using Dragonfly’s documented platform, Mapbox guidance and data-quality questions.
A map is useful when location helps someone answer a question or complete a task.
That question might concern where an event occurred, which records relate to an area or what information is available about a selected location.
Define that task before choosing the map’s appearance. Then establish how geographic information connects to the application’s underlying records.
A real example: Dragonfly’s intelligence platform
Dragonfly’s documented platform connects risk ratings, geographic locations, events and research.
Its customer tools include interactive maps, category selection, legends, custom locations and structured exports. Analyst administration tools support the information behind the customer experience. Explore the Dragonfly case study.
These are documented application features. The case-study screenshots use sample data and do not provide current risk guidance.
Decide what belongs on the map
Different information calls for different geographic representations.
A site might be represented by a point, a route by a line and a service area by a boundary. Decide what each feature means and which business record it identifies.
Mapbox’s documentation explains the separation between geographic data sources and the layers used to display them. GeoJSON sources can contain points, lines and polygons. Mapbox’s sources-and-layers guidance.
The map display should retain a dependable connection to the application record, so a user can move from the geographic view to the relevant detail.
Record uncertainty and freshness
Agree how locations are obtained and checked.
An exact site coordinate, an approximate area and an unresolved address should not silently become equivalent records.
Identify the source of geographic information, the relevant update time and what should happen when a location cannot be resolved. Decide how users will recognise missing or uncertain information.
For business data layered over a map, also establish who maintains the underlying values. A current basemap does not establish that every business record displayed on it is current.
Design the task beyond the map
Decide what a user needs after selecting an area or feature.
That could include a detail panel, related research, a filtered table or an export. These are possible design choices to assess against the workflow.
Dragonfly’s published account provides a real example of combining maps with research, threat-event views, tables and charts. The map forms part of a broader working application.
Provide a suitable way to find and review records where a geographic view alone is insufficient.
Keep meaning consistent across styles
Dragonfly’s case study demonstrates native light and dark basemap styles, with risk colours and controls retaining their meaning.
Those controls demonstrate map styling. They do not establish that the entire underlying application has a complete light-and-dark theme.
For a proposed map, check labels, legends, selected features and category distinctions in each supported style. Test mobile interaction as well as desktop use.
Plan data access and infrastructure
The documented Dragonfly stack includes React and TypeScript applications, Mapbox mapping, Python services and PostgreSQL/PostGIS on Google Cloud. Its architecture also includes analyst tools and scheduled data operations. Review Dragonfly’s engineering and infrastructure.
For your application, assess record permissions, dataset size, update frequency and the geographic operations required before selecting an architecture.
Start with one question the map should help answer, a representative dataset and the action the user needs to take next.