Last WagonAll documents

openstreetmap · rev 1

OpenStreetMap / ODbL

Document ID
openstreetmap
Version
1.0.0 · Revision: 1
Provider
OpenStreetMap contributors, via the OpenStreetMap Foundation
Licence
Open Database License (ODbL) 1.0
LastWagon components
Basic routing and geocoding (via openrouteservice), Basic map tiles (via OpenFreeMap/OpenMapTiles), and a small number of coordinates in the bundled truck-stop directory
Status
Final record — counsel reviewed 2026-08-21.

Every way OpenStreetMap data enters LastWagon

Route inWhat it isObligation
openrouteservice routing and geocodingRoutes and address matches computed over OSMAttribution
OpenFreeMap tiles (OpenMapTiles schema)The Basic map itselfAttribution
Photon geocoding of directory addressesCoordinates stored in the shipped directoryAttribution — see below
Anything else—None. There is no other OSM-derived dataset in the product.

Required attribution

Attribution must be to OpenStreetMap, and must make clear the data is available under the Open Database License — either by including or linking the ODbL text, or by making "OpenStreetMap" a link to openstreetmap.org/copyright. The customary form is:

© OpenStreetMap contributors

For an interactive map the credit should appear in a corner of the map; it may be behind an info control or on a startup screen, but it must be reachable.

LastWagon implementation: the map attribution line is drawn on the Basic map surfaces themselves, not only in a settings screen. Legal & Attribution carries the full credit with a link to openstreetmap.org/copyright. Routing and geocoding credit OpenStreetMap through the openrouteservice attribution string, which names both.

The bundled directory coordinates — the ODbL question

The question. LastWagon ships a proprietary compiled truck-stop directory. Part of the coordinate gap is closed with an OpenStreetMap-derived geocoder. Does storing those coordinates make the shipped directory a Derivative Database under ODbL, triggering share-alike?

The answer, on these facts: no — but attribution is required.

The OSM Foundation's Geocoding Guideline, endorsed by the OSMF board on 24 August 2017, is the authority. It holds that individual geocoding results are insubstantial extracts of the OSM database and may be *"stored and used together with other proprietary or third party data"*. A collection of geocoding results is not a Derivative Database provided that:

  • it contains only names, addresses and/or latitude/longitude information, and
  • it is not a systematic attempt to aggregate all, or substantially all, features of a given type within a city-sized or larger area.

Share-alike is triggered only if results are aggregated into something containing the whole or a substantial part of the OSM database. Attribution is required either way: an application incorporating a geocoder must credit OpenStreetMap.

Why LastWagon's use fits. The directory is not built from OpenStreetMap. It is a pre-existing, independently compiled list of specific places, and the geocoder is used to place addresses that were *already in that list*, one at a time. LastWagon never uses OpenStreetMap to *discover* a truck stop. The geocoder is queried with an address, never a business name, and a result is kept only when it resolves to an actual building — street, city and locality centroids are rejected outright. Only a coordinate is stored; no OSM identifier, tag, name or geometry is carried across.

Where this would flip. The conclusion depends on those facts, and would need re-examining if any of them changed:

  • using a business-name or category query to *find* truck stops rather than place known ones
  • pulling every feature of a type in an area — for example, harvesting all highway=rest_area in a state
  • storing OSM identifiers, tags, names or geometry alongside the coordinates
  • the OSM-derived share growing to where the coordinate set could be read as a substantial part of the OSM address database for a region

Recorded, not assumed: the guideline's own words are that it "does not declare geocoding results to be Produced Works", which it treats as inconsistent with the ODbL text. LastWagon does not rely on the Produced Work route.

Status in the shipped app — DECIDED

**Owner decision, 2026-08-21: the beta ships Census-derived coordinates only. The 379

OpenStreetMap-derived coordinates are NOT shipped.**

The analysis above was accepted as reasoning, not as a licence to proceed. The decision is that taking on a database-licence obligation — for roughly 379 map pins, ahead of dedicated legal review — is not a trade worth making for a beta. It is explicitly revisitable, and the reasoning above is what it will be revisited against.

What that means concretely:

  • The bundled directory contains no OpenStreetMap-derived coordinates, in the 0.7.0 release line and in the beta. Its coordinates come from the owner's compiled master and, where enrichment runs, from the U.S. Census geocoder — a U.S. Government work in the public domain, which carries no licence obligation at all.
  • The POIs the OSM geocoder would have placed remain in the directory as address-only records. They are fully searchable by name, city, state and ZIP; they simply carry no map pin. That is a disclosed limitation, not a missing record — and it is the same position the directory already takes for every stop the Census geocoder cannot resolve.
  • This is enforced, not remembered. The generator ships only allowlisted match types (Census_Exact, Census_Non_Exact), withholds and reports the rest, and stamps coordinateSources into the asset header. scripts/legal-check.mjs fails the build if the shipped asset carries any OSM-derived or unclassified coordinate. Reversing the decision takes --allow-osm-coordinates plus an edit to this file — a deliberate act with a reviewable diff.
  • The enrichment file keeps every OSM row. Nothing is thrown away; the work already done stays available for the day the review happens. --census-only on the enrichment script produces a purely public-domain result set from scratch if that is preferred.

LastWagon still owes OpenStreetMap attribution, and still gives it, because OSM data reaches the app through three other doors regardless of this decision: openrouteservice routing, openrouteservice geocoding, and the OpenFreeMap tiles the Basic map is drawn from. Nothing about the attribution obligation changes; what changes is that the bundled, redistributed database does not carry ODbL material.

What would have to happen to revisit this

  1. Dedicated legal review of the Derivative-Database analysis above, by counsel, on these facts.
  2. If it clears: update this section and legal/data-sources.md before regenerating, so the documents lead the data rather than trailing it.
  3. Regenerate with --allow-osm-coordinates, and confirm the ODbL attribution obligations for a redistributed database — not just a displayed map — are satisfied.

Photon, and the courtesy owed to it

The public Photon instance at photon.komoot.io is run by komoot as an OpenStreetMap project. Its stated terms are, in full: *"You can use the API for your project, but please be fair - extensive usage will be throttled."* Availability is not guaranteed and the terms may change.

LastWagon implementation: the enrichment script runs sequentially, one request at a time, with a pause between them, offline and one-off, on a maintainer's machine — never from a driver's device and never at runtime. If the enrichment ever needs to run at a scale that is no longer "fair", the right answer is to self-host Photon, which is open source, rather than to lean harder on a free public service.

Sources