-
Notifications
You must be signed in to change notification settings - Fork 210
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Topology #113
Comments
I think there is definitely lots of reasons we should consider topology/graph data in VTs. However, I am not yet sold on them necessarily in VTs specifically currently, this doesn't mean it couldn't happen it just means it is unlikely. What seems like a much more likely scenario is the introduction of a complimentary format that uses VTs for feature definition and another VT like layer that provides topology information. There are lots of ways to define graphs and inherently they will be cross tiles -- something that not all features are required to be in VTs. In short, I am not sure where this belongs yet and how, but this is something we are considering deeply. |
Polygons that share borders, is another use case, the encoding could store the arc once instead of twice for each feature, in a similar way to topojson. |
There's also rendering benefits to using topology for shared borders mapbox/mapbox-gl-js#4090 (comment) you can choose a render time if you want to draw fill's or draw a single dotted or transparent border line (but only draw it once). Currently you need two layers for the same data (one being the polygons and one being the mesh linestrings). |
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:
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).
The text was updated successfully, but these errors were encountered: