No route, tile or time matrix goes out to a third party. So nobody bills you for them.
A CMMS that consumes paid map services has a cost that grows with your usage, and every query tells that provider where your staff are. Here PostGIS, Valhalla, VROOM, Planetiler and the tile server run inside the installation, deployed with Docker Compose. It is not a technical preference: it changes the cost structure and who sees your team's positions.
No per-call cost, no provider fee.
With a paid map service, the variable cost grows with usage. Every time matrix, every geocode and every tile is billed, and the more your team uses the system, the more you pay.
With the engines inside the installation, calculating the proximity matrix for the whole workforce every time the assignment panel opens costs nothing. That is why proximity is calculated every time, not only when someone remembers to ask for it.
And the consequence that is not about money: staff positions and routes never leave the installation, because there is no third party to query.
What runs, and what for.
| Component | Technology | Function |
|---|---|---|
| API | FastAPI (Python) | All business logic, on /api/v1, plus the public API in its own namespace. |
| Database | PostgreSQL + PostGIS | Data and geometry. With pg_cron and pg_partman. |
| Web frontend | PHP + MapLibre GL | Management application and customer portal. |
| Tile server | Dedicated Nginx | Serves MVT tiles cached on disk without going through the API. |
| Routing | Valhalla on OSM | Routes, origin-destination matrices, map matching and isochrones. |
| Optimisation | VROOM | Route solver with time windows and capacities. |
| Base map | Planetiler | Generates OpenStreetMap PMTiles for any region. |
| Deployment | Docker Compose | Two networks, one internal and one for the proxy, with automatic TLS. |
Why the map does not choke on the whole network.
If the inventory is drawn with browser markers, the map chokes when it shows a whole network: the DOM cannot handle a hundred thousand elements, so you have to page or filter, which is exactly what makes the map useless.
Here the inventory is served as MVT vector tiles generated from PostGIS, cached on disk in a shared volume and served by a dedicated Nginx that does not go through the API. The cache carries per-layer versioning and selective purging: when a style or a value changes, only what is affected is invalidated, not everything.
Your own base map and offline packages.
- Own OSM base map Generated with Planetiler for whatever region you need, with a dynamic region catalogue. No third-party API key.
- Asset PMTiles The inventory tiles, packaged for offline use on the device.
- Orthophoto MBTiles PNOA orthophoto (Spain's national aerial imagery programme) downloaded from the IGN (National Geographic Institute) and clipped to the work area.
- External WMS layers From third parties, with automatic discovery via GetCapabilities.
- Full MapLibre styles Fill, stroke, pattern, symbol, label and zoom filter, with thematic styling by property and a derived legend.
Four worth knowing before you evaluate.
- Geometries in EPSG:3857 Internally, consistent with web tiling, with transformation to 4326 at the system boundaries.
- Circuit breakers In front of Valhalla and VROOM, with their state visible in the health check. If the routing engine goes down, the application degrades instead of locking up.
- Monthly telemetry partitioning With automatic partition management and retention: 60 days for staff positions, 90 for vehicles.
- Shared logic in PL/pgSQL Eligibility, availability, effective working hours and geofence detection live in the database, so web, mobile and automated processes give the same result.
Frequently asked questions
Can it be deployed on our own infrastructure?
What happens if Valhalla or VROOM stop responding?
How many schema migrations has the product been through?
Last updated: