Topology

Nobody has claimed this yet.

At present, MVTs are usable for map display and (limited) analysis.

Topology is not encoded and therefore there is no possibility of using MVTs for routing. An app which wants to perform on-device routing needs to store two datasets, one for display, one for routing. This means that geometries and street names are stored twice - an inefficient use of storage on a space-constrained mobile device.

Typical use cases might be:

* Live rerouting without an internet connection, especially to return to a preplanned route from which the user has deviated
* Short-distance pedestrian routing, e.g. for delivery drivers who are delivering to a cluster of nearby points, or to a destination away from their location on the road network
* On-device routing on a fairly sparse dataset such as railways, waterways, or a single town/neighbourhood

The vector storage formats used by other mass-market apps do support routing/topology - for example, Garmin devices (.img), maps.me (.mwm), OsmAnd (.obf).

Challenges would include cross-tile connections (see #108). Topology could be moderately expensive to store and thus it should be optional overall, and additionally optional per-layer (a roads layer might benefit from it, a buildings layer wouldn't).

No files, tests, or entry points are named. Start by reviewing the vector tile specification and the cross-tile connection concern in #108. Done would require a defined optional topology encoding, including how connections cross tiles and how topology is enabled per layer.

Written by the indexing model from the issue text.