Open source at MapMap

What we build on

The architectural third-party components in the product, their licences and how each is consumed. This is not exhaustive at the Rust-crate level: the full, machine-generated crate report is produced in CI and ships with our SBOM.

Our fork policy

Valhalla is the single bounded exception to an otherwise Rust-only codebase. Every other engine listed above, MapLibre, Planetiler, GraphHopper, VROOM, Ferrostar and Photon, is consumed unmodified: no forks, no patches, no vendored copies.

A patch against Valhalla clears the bar only with all four of: a reproduction against real data, evidence that no configuration or Rust-side preprocessing can fix it, a gurka test in the series, and a default that preserves upstream behaviour so the change is opt-in. The six patches we currently carry:

• 0001 Adds an ADR tunnel-category attribute to Valhalla's tile format, in three previously spare bits, so tile size and layout are unchanged.
• 0002 Extracts ADR tunnel categories from OSM hazmat:* tagging during tile build, with a documented precedence between explicit and inferred values.
• 0003 Adds a truck costing option, adr_tunnel_code, that blocks routes through a tunnel above the declared load's ADR category.
• 0004 Gurka test coverage: a full tunnel-category truth table, plus the extraction-tier, malformed-tag and untagged-tunnel edge cases.
• 0005 Makes the short-ferry hierarchy-pruning cutoff a config value instead of a hardcoded 2,000 m, so long routes can't silently drop a real ferry crossing.
• 0006 Extends ADR-category extraction to corridor-style tagging (per-code hazmat:B..E keys with no tunnel tag), fixing a real case where hazmat loads were wrongly detoured around a tunnel.

The series is written in upstream style, self-contained, with CHANGELOG and API doc entries and gurka coverage, ready for submission, and offered under MIT, the same licence as Valhalla itself. We prefer upstreaming: we carry a patch only while it remains unmerged, and rebase it onto new upstream tags as our distro pin moves.

Attribution is enforced, not optional

Every compiled map style carries "© OpenStreetMap contributors © OpenMapTiles", and our style validator rejects any style missing it before it can be published. The attribution UI in our SDKs is not a default a white-label configuration can switch off: it ships in every distribution, on-device and hosted alike.

ODbL compliance

OpenStreetMap data is licensed under the Open Database Licence 1.0. Our territory packages contain databases derived from OSM. Under ODbL §4.6, when we publicly use a derivative database we must offer either the derivative itself or an "algorithm and alterations" recipe sufficient to recreate it. This is that recipe, shipped with every package and kept current in the same change as any pipeline update.

What's derived from OSM

• Valhalla routing tiles
  Built by valhalla_build_tiles over an OSM PBF extract, with our own emitted config
• PMTiles render layer
  Built by Planetiler over the same PBF plus OSM-derived global sources (OSMData water polygons, OSM-derived lake centrelines)
• Geocode index
  NDJSON extraction from the same PBF, indexed with tantivy
• Admin-boundaries database
  Built by Valhalla's own admin-tagging step over administrative-boundary relations in the same OSM PBF extract, served read-only

What isn't

Proprietary POI and customer data lives in separate sidecar databases, never merged into OSM-derived tables. Under the OSMF Collective Database Guideline, a package built this way is a collective database: ODbL share-alike does not extend to the sidecar layers. The render layer's low-zoom land, ocean and lake shapes also draw on Natural Earth, which is public domain.

Recreation procedure

1. 1. Get the extract. Obtain the OSM extract for the territory at the snapshot recorded in the package manifest's data timestamp, Geofabrik publishes dated extracts.
2. 2. Get the code. Check out our repository at the tag recorded in the package manifest's version, which pins the exact build code and territory configuration.
3. 3. Rebuild. Run the build with the same inputs. The pipeline is deterministic given the extract, config and toolchain versions recorded in the manifest: the produced layers are byte-equivalent up to signing keys and timestamps.

Ported code is attributed per file

Our CarPlay and Android Auto integrations include converters derived from Ferrostar (its FerrostarCarPlayUI and android/car-app), BSD-3-Clause, © Stadia Maps, Inc. Every derived file, on both platforms, carries a header comment noting what it was ported from. No Ferrostar Swift or Kotlin package is linked into either module: both bind directly against our own generated types.