On Fr, Okt 30, 2015 at 10:52:40 +0100, Christoph Hormann wrote: > If you look at design problems recently discussed in the osm-carto style > development[2] you will see most of them have nothing to do with vector > tiles, they would not be made any easier to address with such an > approach. On the other hand there are a multitude of things the > current style handles fairly gracefully, especially the problem of > reducing geometric complexity, that would be much harder to deal with > in a vector tiles system[3].
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. And one more thing: I suggest we start thinking about not one set of vector tiles, but many. Each one can contain different data (from OSM or not) derived in different ways. Vector tiles from different tile sets can then be merged (either in an extra step before delivering to client, or during rendering). This will give us enormous flexiblity and decouple different parts of the tool chain to allow for easier experimentation. As an example: Somebody can have a very specialized process for generalizing, say, railway infrastructure for low zoom levels. This can then be combined with the standard tiles for rendering specialized maps without requiring the maker of the specialized map to have a full OSM tool chain working. Jochen -- Jochen Topf joc...@remote.org http://www.jochentopf.com/ +49-351-31778688 _______________________________________________ dev mailing list dev@openstreetmap.org https://lists.openstreetmap.org/listinfo/dev