pnorman / openstreetmap-cartographic Goto Github PK

Many areas of landcover such as landuse=meadow and landuse=farmland are mapped in small parcels, especially in places like the Netherlands (where this data has been imported), but also in places where the traditional landscape consists of many small areas of different agricultural use (like in the Azores).

I expect that generalization might be necessary, since the rendering speed of this style at ~z7/z8 is already quite poor even with the current filtering

Another option would be to render the water and landcover as raster image for lower zoom levels, as done by the fr.openstreetmap.org style currently.

Netherlands rendering in this style:

Compared with current Openstreetmap Carto rendering:
<img width="617" alt="Screen Shot 2020-11-08 at 09 58 28" src="https://user-images.githubusercontent.com/42757252/98473805-04959180-21aa-11eb-9db2-3986c871ee9d.png”>

Azores current rendering:

Compared with OpenStreetMap Carto:

We need to be able to include symbols on the map. To do this, we need to compile images into spritesheets and serve them locally.

ref mapbox/mapbox-gl-js#4086 (comment)

At z7 and z8 in areas with lots of landcover and roads, the rendering bogs down when scrolling around and zooming in well-mapped areas, for example France or the Netherlands. This was mentioned on the mailing list back in May but the current implementation at https://pnorman.dev.openstreetmap.org/cartographic/ still has this problem

https://pnorman.dev.openstreetmap.org/cartographic/mapbox-gl.html#7/49.518/3.728
and
https://pnorman.dev.openstreetmap.org/cartographic/mapbox-gl.html#8/52.023/5.778

I’m viewing this on Safari and Chrome on a 2015 Macbook Pro with 16 GB RAM, 2.2 GHz Intel Core i7 processor.

Safari warns me that “this web page is using significant memory. Closing it may improve the performance of your Mac”. Usually the warning apppears after about a minute of scrolling / zooming.

On Chrome it looks to be using about 3 GB of RAM, if I’m looking at the processes correctly in the Activity Monitor app (Google Chrome Helper GPU = 1.6 GB, Google Chrome Helper Renderer = 1.5 GB and these drop off when the window is closed). CPU usage can be >300%

Vector tiles usually preserve the "good old" OSM zoom level.
Can't you preserve it? IMHO it would make (our ;-)) live easier.

Chrome console reports

ajax.js:148 A preload for 'https://took.paulnorman.ca/build/openstreetmap-cartographic.json' is found, but is not used because the request headers do not match.
l @ ajax.js:148
ajax.js:148 A preload for 'https://fonts.openmaptiles.org/Klokantech%20Noto%20Sans%20Regular/0-255.pbf' is found, but is not used because the request credentials mode does not match. Consider taking a look at crossorigin attribute.
l @ ajax.js:148
ajax.js:148 A preload for 'https://fonts.openmaptiles.org/Klokantech%20Noto%20Sans%20Italic/0-255.pbf' is found, but is not used because the request credentials mode does not match. Consider taking a look at crossorigin attribute.```

Not an easy topic. The answer may be won't do ;-). It may depends on PostGIS.
https://www.openstreetmap.org/#map=18/47.79839/-3.47620&layers=N

https://pnorman.dev.openstreetmap.org/cartographic/mapbox-gl.html#16/47.797919/-3.476055

Overzooming for clarification

Show the OpenStreetMap community what data you are using. Add your project to the list of Taginfo Projects.

With Mapbox GL JS being un-open sourced, I need to figure out what rendering engine this project will continue with.

It could build off of

• https://github.com/mapbox/mapbox-gl-js/tree/3136a53235cf17b732e84c9945c4e85ba3369a93, the last Mapbox GL JS version under an open-source license;
• another rendering engine that uses Mapbox GL styles; or
• something new.

Both explicitly mapped natural=glacier and Antarctic ice sheet.

Generating z12 spends a lot of time on the protected-area-names and admin-names layers.
These are selecting ST_PointOnSurface(way) with a name IS NOT NULL condition, and, depending on layer, either way_area > 957254.744709896 or way_area > 239313.686177474.

An index on ST_PointOnSurface where name is not null would help with these queries by returning fewer rows, and meaning that an expensive ST_PointOnSurface would not need to be computed for all tiles intersecting large admin or protected area polygons

This might require stage 2 flex processing

Most features from the transportation layer aren't dashed, but rails at higher zooms and non-motorized paths have a dasharray.

The problem with this is line-dasharray doesn't support data driven styling.

I'm not sure what the solution is here. I could add more layers, but I'd at most want to add one style layer per layer=* value.

This could be a PostGIS bug in ST_AsMVTGeom, but needs reducing into a test case.

Tile in question is 8/134/87