5 ms·

But with vector tiles you (normally) start overzooming at level 15, resulting in either much less detail or really large file sizes for a zoom 14 vector tile th

But with vector tiles you (normally) start overzooming at level 15, resulting in either much less detail or really large file sizes for a zoom 14 vector tile that would have to carry all the data to be used in overzooming. So raster tiles load much faster and OpenStreetMap retina tiles help against pixelation. And you can - though not advisable for large areas - render raster tiles at much higher zoom levels, e.g. SomeOneElse renders his raster style up to level 28 for the UK.

moffkalast 4y ago
Well that is true, the vector tiles do have the opposite problem of having too much data when zoomed out, but using raster beyond level 21 is just completely wasteful in terms of storage required. Most of the tiles will just be one colour. I'm not sure how level 28 is even possible without taking up multiple HDDs. I still think that the more proper solution would be to instead cap out the vector tiles on the other end, not going lower than say level 5.
- spiekerooger 4y ago
  Both arguments of yours are quite true, I also don't think that going beyond zoom level 20 or 21 is advisible within a raster tile stack (and I just checked that the UK map I mentioned earlier goes up to zoom 24 and not 28 as I stated, while the software stack (in this case mod_tile&renderd) is prepared for up to zoom 28). I also don't intend to argue against a vector tile stack - both vector and raster have their use cases and pro's and con's. Vector tiles bring much more flexibility but less support in some use cases, raster normally loads/displays much faster (if served pre-rendered) and has universal support on the client side.
  - moffkalast 4y ago
    Yeah I mean if you ask me what the optimal solution is it would have to be a combination of the two, more specifically vector data overlaid on top of satelite imagery. Unfortunately I'm not really aware of any FOSS dataset for that yet, but that may change in the coming decades if the price of mass to orbit goes down.
sorenjan 4y ago
Couldn't you take this into consideration in the vector renderer? A lot of roads and paths in OSM have width and surface tags, you could render that using some appropriate texture on high zoom levels instead of the usual dotted lines for paths. Forest and grass doesn't have to be solid green fields, and crosswalks and traffic lights could be rendered, contour lines can have user specified intervals, and so on. There's lot's of additional detail you can render parametrically from data.
- dabreegster 4y ago
  We're working on rendering more detail about roads for high-zoom cases: https://github.com/a-b-street/osm2streets https://github.com/a-b-street/osm2streets. Try https://a-b-street.github.io/osm2streets/?test=st_georges_cycletrack#17.33428773071983/51.49577/-0.10546 https://a-b-street.github.io/osm2streets/?test=st_georges_cy... and press "Generate details"

moffkalast 4y ago

Well that is true, the vector tiles do have the opposite problem of having too much data when zoomed out, but using raster beyond level 21 is just completely wasteful in terms of storage required. Most of the tiles will just be one colour. I'm not sure how level 28 is even possible without taking up multiple HDDs. I still think that the more proper solution would be to instead cap out the vector tiles on the other end, not going lower than say level 5.

spiekerooger 4y ago
Both arguments of yours are quite true, I also don't think that going beyond zoom level 20 or 21 is advisible within a raster tile stack (and I just checked that the UK map I mentioned earlier goes up to zoom 24 and not 28 as I stated, while the software stack (in this case mod_tile&renderd) is prepared for up to zoom 28). I also don't intend to argue against a vector tile stack - both vector and raster have their use cases and pro's and con's. Vector tiles bring much more flexibility but less support in some use cases, raster normally loads/displays much faster (if served pre-rendered) and has universal support on the client side.
- moffkalast 4y ago
  Yeah I mean if you ask me what the optimal solution is it would have to be a combination of the two, more specifically vector data overlaid on top of satelite imagery. Unfortunately I'm not really aware of any FOSS dataset for that yet, but that may change in the coming decades if the price of mass to orbit goes down.

sorenjan 4y ago

Couldn't you take this into consideration in the vector renderer? A lot of roads and paths in OSM have width and surface tags, you could render that using some appropriate texture on high zoom levels instead of the usual dotted lines for paths. Forest and grass doesn't have to be solid green fields, and crosswalks and traffic lights could be rendered, contour lines can have user specified intervals, and so on. There's lot's of additional detail you can render parametrically from data.

dabreegster 4y ago
We're working on rendering more detail about roads for high-zoom cases: https://github.com/a-b-street/osm2streets https://github.com/a-b-street/osm2streets. Try https://a-b-street.github.io/osm2streets/?test=st_georges_cycletrack#17.33428773071983/51.49577/-0.10546 https://a-b-street.github.io/osm2streets/?test=st_georges_cy... and press "Generate details"