<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=Windows-1252">
</head>
<body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; color: rgb(0, 0, 0); font-size: 14px; font-family: Calibri, sans-serif;">
<div>
<div>Hi Blake,</div>
<span id="OLK_SRC_BODY_SECTION">
<div><br>
</div>
I know that the MVT spec supports different projections. But I said they are "<span style="font-family: -webkit-standard;">depending on a </span>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 "<span style="font-family: -webkit-standard; font-size: medium;">that current mapping tools face in practice</span>“.
<div><br>
</div>
<div>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. </div>
<div><br>
</div>
<div>> 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. </div>
<div><br>
</div>
<div>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). </div>
<div><br>
</div>
<div>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: <a href="https://github.com/rjw57/proj4webgl">https://github.com/rjw57/proj4webgl</a>).</div>
<div><br>
</div>
<div>> <span style="font-size: 13px;">Any issues you might have with the Mapbox Vector Tile Specification or any ideas you might have with the format are very much welcome.</span><span style="font-size: 13px;"> </span></div>
<div><span style="font-size: 13px;"><br>
</span></div>
<div><font face="Calibri,sans-serif"><span style="font-size: 13px;">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. </span></font></div>
<div><span style="font-size: 13px;"><br>
</span></div>
<div>> <span style="font-size: 13px;">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.</span><span style="font-size: 13px;"> </span></div>
<div><span style="font-size: 13px;"><br>
</span></div>
<div><font face="Calibri,sans-serif"><span style="font-size: 13px;">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). </span></font></div>
<div><font face="Calibri,sans-serif"><span style="font-size: 13px;"><br>
</span></font></div>
<div><font face="Calibri,sans-serif"><span style="font-size: 13px;">In my opinion, it shouldn’t be considered reliable, or maybe accurate, enough for general purpose GIS usage other than rendering. </span></font></div>
<div><font face="Calibri,sans-serif"><span style="font-size: 13px;"><br>
</span></font></div>
<div><font face="Calibri,sans-serif"><span style="font-size: 13px;">~Ben</span></font></div>
<div><br>
</div>
<span id="OLK_SRC_BODY_SECTION">
<div style="font-family: Calibri; font-size: 11pt; border-width: 1pt medium medium; border-style: solid none none; padding: 3pt 0in 0in; border-top-color: rgb(181, 196, 223);">
<span style="font-weight: bold;">Von: </span>Blake Thompson <<a href="mailto:flippmoke@gmail.com">flippmoke@gmail.com</a>><br>
<span style="font-weight: bold;">Datum: </span>Dienstag, 2. Februar 2016 um 01:03<br>
<span style="font-weight: bold;">An: </span>Stefan Keller <<a href="mailto:sfkeller@gmail.com">sfkeller@gmail.com</a>><br>
<span style="font-weight: bold;">Cc: </span>Benjamin Stadin <<a href="mailto:benjamin.stadin@heidelberg-mobil.com">benjamin.stadin@heidelberg-mobil.com</a>>, Gdal-Dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>>, Even Rouault <<a href="mailto:even.rouault@mines-paris.org">even.rouault@mines-paris.org</a>><br>
<span style="font-weight: bold;">Betreff: </span>Re: [gdal-dev] Vector Tiles in OGR<br>
</div>
<div><br>
</div>
<div>
<div dir="ltr">Benjamin Stadin,<br>
<br>
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: <br>
<br>
<a href="https://github.com/mapbox/vector-tile-spec/tree/master/2.1#3-projection-and-bounds">https://github.com/mapbox/vector-tile-spec/tree/master/2.1#3-projection-and-bounds</a><br>
<br>
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.<br>
<br>
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.<br>
<br>
"<span style="font-size: 12.8px;">But what data is </span><span style="font-size: 12.8px;">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. <br>
</span><br>
"<span style="font-size: 12.8px;">There is enough interest from our side that we¹d be interested in </span><span style="font-size: 12.8px;">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 <a href="https://github.com/mapbox/vector-tile-spec/blob/master/CONTRIBUTING.md">https://github.com/mapbox/vector-tile-spec/blob/master/CONTRIBUTING.md</a> for
how you might help!</span><br>
<br>
<span style="font-size: 12.8px;">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.<br>
<br>
Thanks,<br>
<br>
Blake Thompson </span></div>
</div>
<div><span style="font-size: 12.8px;"><br>
</span></div>
</span></span></div>
</body>
</html>