On Friday 30 October 2015, Jochen Topf wrote: > > This is not a failure of the vector tile approach in general. It > might be a problem of how the vector tiles are generated today, but > not a general problem of the vector tile approach. A vector tile can > contain any data that you need for rendering any kind of style. The > question is how the data will get into that vector tile. Currently > the tool chain that does this is not mature enough, I agree. It > doesn't take into account different sources of data (needed for > special maps) and doesn't do generalization well enough. But this is > something we can and should work on.
We need to distinguish a number of different things here: 1. the idea of storing and transporting geometries in a tiled form in general 2. the concept of current vector tile stacks 3. the idea of processing geometry on a level that is not generally possible to do on the fly during rendering I was exclusively talking about 2. here, in particular because in contrast to the classical non-vector-tile stacks theys are not suited to efficiently deal with the geometric complexity issues without 3. As i have mentioned many times i think 3. is important and grossly neglected. Vector tiles might bring an additional incentive to address this of course. The one important thing speaking against tiled geometry storage and transport in general is handling of different map projections. Any such system will require you to select one projection from the very beginning and you stay bound to it or need fully separate setups for every projection you want to offer. -- Christoph Hormann http://www.imagico.de/ _______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev
