[OSM-dev] OpenStreetMap Cartographic: A client-side rendered OpenStreetMap Carto
ndrw6 at redhazel.co.uk
ndrw6 at redhazel.co.uk
Mon May 25 14:45:11 UTC 2020
On 25/05/2020 01:34, Paul Norman via dev wrote:
>
> Landuse, vegetation, and other natural features are not rendered until
> zoom 7. This is the scale of OpenStreetMap Carto zoom 8, and these
> features first appear at zoom 5. There are numerous problems with
> unprocessed OpenStreetMap data at these scales. OpenStreetMap Carto gets
> a result that looks acceptable but is poor at conveying information by
> tweaking Mapnik image rasterizing options. I'm looking for better options
> here involving preprocessed data, but haven't found any.
I think we will need fairly heavy pre-processing (filtering and
simplification/generalization) of data before they hit the tile and the
client. Carto is doing some of it already, even though data stay on the
server side at all times. With the client-side rendering this is much
more important for three reason - real time rendering, network traffic,
limited resources on client side.
Some ideas:
- Tiles should contains only objects to be rendered, so all the
filtering currently done in Carto should be applied at the tile
construction time.
- Currently Carto produces a lot of data that are later filtered out in
Mapnik (via spatial occlusion) - this also should be brought back to a
tiling script.
- Tiles should be split into layers (similar to layers in Carto). Then
the user would have an option to select layers they are interested in
(think language versions, POIs). With more, smaller tiles there is also
a potential for distributing the server side load more uniformly.
- For z5-z12 we will need some kind of polygon
generalization/simplification. For example, at z7 I can see all landuses
in England, with some towns occupying only a couple of px but but still
being comprised of hundreds of landuse polygons. I'm not talking about
anything fancy, but merging anything sub-1px into "pixel rectangles"
could go a long way. (Edit: I see you are already doing it - I can see
some simplified landuse polygons when zooming in further).
> The technology choices are designed to be suitable for a replacement for
> tile.osm.org. This means minutely updates, high traffic, high
> reliability,
> and multiple servers.
Do we need minutely updates for vector tiles? Sure, that's a nice
feature to have but with client-side rendering any performance issues
will be directly exposed to the users. And performance is a big issue in
most client-side rendering solutions. If we can keep the current raster
backend with minutely updates for mapping feedback, I have no problem
with hourly or daily updates for the vector version. We would need a
raster option for browsers/devices not supporting WebGL anyway.
ndrw
More information about the dev
mailing list