This mailing list has been migrated to Mailman 3. This archive will no longer be updated. Messages after 1 February 2020 are missing. Please use the new archive instead.
Diese Mailingliste wurde auf Mailman 3 umgestellt. Dieses Archiv wird nicht mehr länger aktualisiert. Nachrichten nach dem 1. Februar 2020 fehlen. Bitte benutze das neue Archiv.
Hello, together with Nakaner, we discussed about vector tiles at the FOSSGIS 2017 conference in Passau, Germany. We came to the conclusion, that vector tiles have a lot of disadvantages and are far away from productive use and decided to remove them from OpenRailwayMap. One major problem is the speed. HTML5 Canvas rendering is still too slow, that is why OpenRailwayMap never used tiles rendered on client side in production. WebGL would be the better technology, but has some disadvantages: * Writing an own WebGL renderer is too much work for a small project like this * There are no WebGL-based renderers that are established, using standard formats and not from Mapbox. All available solutions are relatively new and it is not clear how their development will continue (except from Mapbox Vector Tiles). * WebGL can be either not supported or slow on older systems and mobile devices * Clientside rendering will always be slower than serverside rendering. The fast map of openstreetmap.org is a cause why some people prefer it over Google Maps. The main problem is the data of the vector tiles: Vector tiles are just fast if you filter and generalize the data, but this reduces the flexibility and decreases the quality of the data. In our case this is the main problem that makes it difficult to reduce the amount of data in the tiles. In low zoom tiles, railway tracks are split up in a lot of very short ways. Reducing the number of features is only possible by merging these ways. But merging features is just possible by ignoring tags. And the decision which tags are more important than other tags depends on the rendering style. Also there is a general difficulty with vector tiles: It is not possible to drop bitmap tile support completely without dropping the possibility of embedding OpenRailwayMap layers in OsmAnd, QGIS, etc. That is why we will always need a bitmap tile interface. The question is how we should continue now: * Clean up node-tileserver and remove the vector stuff from the code, moving to node-mapnik for tile rendering in a longer perspective * Drop node-tileserver completely and move to Mapnik, mod_tile, renderd, Tirex, ... In both cases there is the problem that Mapnik (and node-mapnik) do not support MapCSS styles. Therefore it would be necessary to develop a converter from MapCSS to Mapnik XML first. If we would choose the first way we would have to decide if we either should apply these changes to node-tileserver or create a fork? Personally I prefer own code over being dependent from other projects, but on the other hand I do not want to invest much work to reinvent the wheel. Regards Alex -------------- n�chster Teil -------------- Ein Dateianhang mit Bin�rdaten wurde abgetrennt... Dateiname : signature.asc Dateityp : application/pgp-signature Dateigr��e : 473 bytes Beschreibung: This is a digitally signed message part URL : <http://lists.openrailwaymap.org/pipermail/openrailwaymap/attachments/20170402/6894e1a2/attachment.sig>