Hi Blake, I know that the MVT spec supports different projections. But I said they are "depending on a certain projection when the tiles are created". Maybe I found the wrong words – I did not mean to say that this is a misconception of MVT, but something "that current mapping tools face in practice“.
Combining and accessing data from different projections is still a practical issue, as well as their reprojection when you need a certain accuracy. It begins with the fact just web mercator tiling is widely enough adopted. I can create my own MVT tiles with my own projection – and have to make several assumptions and code hacks get the result right. Again, I’m not saying this is a misconception with MVT but a legacy problem not solved yet. It is possible to tackle this problem with vector tiles in a different, maybe new, way. > Your comments about the entire stack of Mapbox supporting mostly mercator > could be very accurate, but this is not at all related to the Vector Tile > Specification. Once the (not so trivial) polygon reconstruction challenge is solved, it is entirely possible to define a single tiling format / scheme that fits various projections. Maybe an adaptation of a MODIS Grid with tile sizes in meters correlating with zoom levels as we know them from web mercator. It could store all data as, e.g. as longitude latitude pairs by default (and would not capped at the poles like web mercator). This storage format may then contain data of different projections. However, I believe unprojected WGS84 long / lat would be the proper default for a future map storage format, since it should be possible to do the projection in realtime (web mercator is trivial enough to do in code in realtime, for other more compute intense projections it could be done in realtime via OpenGL shaders: https://github.com/rjw57/proj4webgl). > Any issues you might have with the Mapbox Vector Tile Specification or any > ideas you might have with the format are very much welcome. I’ll try to contribute. But I have a feeling that my ideas outlined above, and what we need for our own rendering and data subsystem, would be breaking to much for you. > Finally, I would like to stress that while Mapbox Vector Tiles were designed > to be for rendering, it was well known during their design that they could be > used for other applications. Here I have to disagree. To summarize, tiled vector data (not just MVT) does a) not solve practical (legacy) issues in regards to projections and combinations of different projections. But it b) also adds new and challenging problems to deal with split polygons and degenerated geometries (in some cases). In my opinion, it shouldn’t be considered reliable, or maybe accurate, enough for general purpose GIS usage other than rendering. ~Ben Von: Blake Thompson <[email protected]<mailto:[email protected]>> Datum: Dienstag, 2. Februar 2016 um 01:03 An: Stefan Keller <[email protected]<mailto:[email protected]>> Cc: Benjamin Stadin <[email protected]<mailto:[email protected]>>, Gdal-Dev <[email protected]<mailto:[email protected]>>, Even Rouault <[email protected]<mailto:[email protected]>> Betreff: Re: [gdal-dev] Vector Tiles in OGR Benjamin Stadin, As an author of the specification, I have to disagree with you on the support for other projections. There is no limitation on vector tiles being required to being in mercator. The specification in fact mentions that other projections may be used: https://github.com/mapbox/vector-tile-spec/tree/master/2.1#3-projection-and-bounds While it is not accessible via the node-mapnik bindings, we do in fact support encoding as different projections in mapnik-vector-tile. We have implemented the decoder so that it could accept other projections, but have not added a mapnik datasource that would support them, but if there is demand for such a thing we could do it. Your comments about the entire stack of Mapbox supporting mostly mercator could be very accurate, but this is not at all related to the Vector Tile Specification. We purposefully attempt to make our tools as projection-less as possible and hope that others find awesome ways to build upon the standard. "But what data is shown at which zoom level is defined by the styling" -- This is not true because you could make your data not even provide data at certain zoom levels. At Mapbox we do this quite often, street data is never included at very low zoom levels. Therefore, the style isn't the only control here. In fact, I would encourage you to view styling and rendering of vector tiles as an entirely different topic. "There is enough interest from our side that we¹d be interested in contributing (maybe monetary or with code, or both) to define and implement a better general purpose tile format." -- Any issues you might have with the Mapbox Vector Tile Specification or any ideas you might have with the format are very much welcome. We want to make sure the spec migrates for community needs. Please see https://github.com/mapbox/vector-tile-spec/blob/master/CONTRIBUTING.md for how you might help! Finally, I would like to stress that while Mapbox Vector Tiles were designed to be for rendering, it was well known during their design that they could be used for other applications. This was especially true when I was writing 2.0 of the specification as I tried to limit what would be considered even the most common uses of vector tiles. Thanks, Blake Thompson
_______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
