OpenStreetMap Carto (default map on OSM.org)

Two fresh articles related to osm-carto:

“Differentiated rendering of woodland in maps”

“Rendering non-default language in OSM-Carto standard map”

Thanks! I was mainly interested in the first article. I’m afraid this level of subtle differences is too much for me, some of the examples sets I saw no difference at all. I would like to see wood/forest density reflected somehow. I proposed the key:spacing mainly for tree_rows but it could have a place in forest/wood/scrub rendering, because higher spacing directly reflects lower density.

Imagico (who is one of the developers of osm-carto) is known for his care for details. I care for other things more so I just made a quick look at this blog entry.

I’m not sure how spacing could be applied to a forest tagging wise. I rarely see the trees pattern with regular spacing, and when they are like this, there is 2D pattern, so there are different distances between rows and columns.

Density is the reverse of average spacing. It’s not about regularity or a grid, no rows and columns (could be, but that just makes it easier to measure the average). In forest it shouldn’t be too hard to measure (by pacing) or estimate on the ground or from air imagery. For the purpose of rendering in a scale of say 5 density’s, you could take the avarage spacing and transform the values to the scale, like: 1-5 m very dense, 5-10 m dense, 10-20 m…, 20-50 m…, > 50 m … (don’t know the proper english words, sorry). Values to be checked with forest-wise people. Rendering could place symbols closer together, vary the color (the denser the darker), or make the ‘wrinkles’ more compact, depending on symbolic style.

Well, just a thought. I would notice that easier than some of the differences in leaf_cycle I just could not detect.

Yes, need some place to discuss interpretations of gathered data and the use of it in rendering - particularly the public facing OSM. As more and more people use OSM as their Google replacement it is important that new - perhaps surprising - changes do not destroy user confidence.
Clearly I have a case in mind - the recent OpenStreetMap Carto release v4.11.0 and the feature Hiding railway=platform with location=underground, tunnels and covered=yes. The change caused many railway platforms to disappear from the public facing map.
The Wiki says for public_transport:platform covered = ‘yes if there is a covering from rain or sun (which may just be a roof)’.
The key=covered is open to many interpretations too long to try to discuss now.
Looking up the arguments for that change the rationale appears to be to hide platforms that are at the lower level of a stack of building levels. Which is only one of the meanings of ‘covered’ - not all of them.

Some people appear to decry the wiki - however it is the nearest to a requirements document that exists - so to my mind changes to dataset/database and renderer for the public face of OSM must emanate from changes to the wiki with agreement from all the communities concerned.
I know this is an emotive area - and whilst I am new to OSM world I know that unpleasant surprises need to be avoided whilst encouraging the exciting activities of data gathering and presentation.

This is impossible to accomplish in general. A simple example: a cyclist wants to see cycle routes, a hiker wants to see walking/hiking routes. They might overlap. Which community will decide what is shown in a particular rendering ?

There is too much “overlapping” data, so one rendering will never fulfil all needs. For me, the future is not in 1 rendering displaying all features, but in a system that easily allows one to select themes to be shown. Are you interested in hiking, cycling, railway infrastructure, … select one or more themes and you see what you need (and also what you do not need is hidden and not obscuring the data you need).

I already use osm.org, historic.place and waymarktrails maps, or the lane visualizer depending on my needs at a certain moment.
They are spread over the internet, it would be neat to see them combined under 1 URL with some switches.

Personally I agree, but in general, media and providers offer a choice between fixed Google / OSM carto / [other types eg satellite/topographic], and maybe a “traffic” or “terrain” layer. I see a shift towards flexible “layers” though. People will get used to the OSM-type flexibility, and providers will accommodate that.

Still, a good all-purpose map is a must. When I’m planning a hike or a bicycle trek through not optimally charted territory, I keep switching map types like a madman to estimate whether or not some piece of forest can be crossed, or if a road continues under/over a motorway or is interrupted by it. Subtle differences in rendering can show me that, and I would expect those on the basic map, not under a switch, because it is relevant to most users.

I don’t believe there could be a place to make sure everything gets rendered the way you suppose it to be. But there are places that could be used to make it more clear:

  • rendering proposition section on wiki
  • this forum (for general or cross-style problems)
  • bug trackers for each style (for more detailed things)

When somebody comes to osm-carto tracker and proposes things we’re not sure about tagging, we send people to the Tagging list, but every tag can be debatable. If you want to talk about meaning of covered=*, I use the similarity with tunnels and examples where it makes sense:

https://github.com/gravitystorm/openstreetmap-carto/issues/3242#issuecomment-390945025

But we can discuss it on the osm-carto tracker or on the Tagging list, depending on whether you think wiki documentation is clear or not.

Rendering server vial might go out of business soon:

https://lists.openstreetmap.org/pipermail/talk/2018-May/080754.html
https://munin.openstreetmap.org/openstreetmap/vial.openstreetmap/index.html

Diary entry about abusing labels for rendering on osm-carto:

https://www.openstreetmap.org/user/imagico/diary/43957

Release v4.12.0 is out:

https://www.openstreetmap.org/user/kocio/diary/44222

however it seems that deployment on OSMF servers is not going to happen too soon:

https://github.com/openstreetmap/chef/issues/168

There are some serious performance problems with v4.12.0, so if you want to deploy it, please wait for a bugfix release (v4.12.1):

https://github.com/gravitystorm/openstreetmap-carto/issues/3280

The performance problem has been identified as something with road surface code, so for now we have released bugfix version v4.12.1 without this code:

https://lists.openstreetmap.org/pipermail/talk/2018-June/080867.html

We’re looking for more coders - not only for simple problems BTW, but that is for a start:

https://www.openstreetmap.org/user/Tomasz_W/diary/44420

The new version of OSM Carto is available for a few days already, but is still not deployed on OSM.org website due to big infrastructure changes:

https://www.openstreetmap.org/user/kocio/diary/44468

Some of my thoughts on OSM Carto development (part 1 - more to follow, I hope):

https://www.openstreetmap.org/user/kocio/diary/44769

Oh, I forgot to mention v4.14.0, which is already deployed - first version update on OSMF servers since v4.11.0:

https://www.openstreetmap.org/user/kocio/diary/44713

Embankments rendering in OSM Carto fork:

http://blog.imagico.de/rendering-implicit-embankments/

and new pattern generator version:

http://blog.imagico.de/new-pattern-generator-version/

Here is my second article about map designing principles - this time it’s about the size:

https://www.openstreetmap.org/user/kocio/diary/44852

Article about pattern changes in imagico’s OSM Carto fork:

http://blog.imagico.de/more-on-pattern-use-in-maps/