Reference
Data, attribution and limitations
Understand source dates, credits, disconnected behavior, and capabilities that are still outside the platform.
On this page
Data sources and release provenance #
The base tiles, Photon search and Valhalla routing are built from the same Philippine OSM extract. Bathymetry comes from separate GEBCO 2026, NOAA ETOPO 2022, GMRT and Natural Earth inputs. Pinned build tooling produces dated, plain-file releases. This platform serves those snapshots; it is not a live-update map feed.
Use release metadata for actual bounds, layers, files and hashes. Read the OSM downloaded date separately from the release created date. Provenance/checksums are available through retained release files; unsigned development releases may not have a signature. The platform build verifies releases and runs air-gap browser checks; an application still needs its own disconnected acceptance test.
Attribution and redistribution #
| Source / software | Attribution and handling |
|---|---|
| OpenStreetMap | © OpenStreetMap contributors; ODbL data obligations apply when redistributing relevant databases/derivatives. |
| Protomaps and Natural Earth | Keep the base map source attribution shown by the style. |
| GEBCO / NOAA ETOPO / GMRT | Retain dataset credits and the pack/style notice; confirm redistribution requirements for your use. |
| Noto fonts | Font licensing notices apply to bundled font resources. |
| MapLibre / PMTiles and other libraries | Preserve their relevant distribution license notices. |
| SW client packages | Packages are marked UNLICENSED; obtain organizational authorization before external redistribution. |
Keep source attribution visible on maps and exported map images. Retain pack attribution/notice metadata when building your app. The repository LICENSES.md is the platform’s source and software inventory; confirm terms for your deployment before external redistribution.
What works without a maps connection #
| Capability | Disconnected behavior |
|---|---|
| Downloaded base map and included bathymetry | Yes, with all local styles/fonts/sprites and a compatible renderer |
| Coordinates, MGRS, grids and sectors | Local client calculations; keep/export browser sector data |
| GPS and track | Device/receiver-dependent; GPS-capable device can work offline |
| Place-name search | Application matching against pack places.json; not full Photon search |
| Depth from local DEM | Application tile decoding; no API source-type response |
| Full search and address reverse | Requires the map services |
| Route, ETA recalculation and isochrones | Requires the map services |
| New pack builds, remote files and updates | Requires a reachable maps host |
| Portal local password/TOTP | Can work on an isolated network where the portal/database remain reachable |
| Optional Google staff sign-in | Requires access to Google |
Disconnected from the internet and disconnected from the maps server are different conditions. An internal offline network can still serve full search/routing; a field device with only a local pack cannot.
Known limits and future capabilities #
- Bathymetry is for planning/awareness only, not navigation. No tides, clearance guarantee or certified nautical charts are supplied.
- Road routing has no live traffic feed and does not plan marine routes.
- Native PMTiles support exists in compatible SDKs, but SW style compatibility and sparse-z15 fallback need target-device validation.
- Seamarks, terrain, imagery and custom PostGIS overlays are later platform work.
- Sea-first styling, sea-plus-coastal-strip packs, WebP elevation tiles and an automatic release-staleness policy are not v1 guarantees.
- places.json and disconnected GL JS pack rendering already exist; older roadmap notes listing them as future work are obsolete.