@Exe19 The Rondo Niebieskich Mistrzòw has in fact physical lane separation. But it’s true, some have the turbo layout, but use only markings. The reasoning is that the physical separations are dangerous for two-wheeled vehicles. In Nederland, bicycles, mofa’s and mopeds are not allowed on these roundabouts, but in some countries they are.

Alternatives are double painted lines, very thick painted lines (e.g. 1 cm elevation), rumble strips, to implement the turbo design. I think these are true turbo roundabouts too; the designation turbo roundabout is not based on OSM-rules!

The rule that lanes are not mapped separately unless there is physical separation, is generally good, I think, but I think exceptions are possible. Time will tell if mappers see markings-only turbo roundabouts as exceptions. Each turbo lane is a separate route over the roundabout, which is most effectively mapped as a separate way.

I recently discovered there are roundabouts where some of the turbo lanes are themselves divided in two or even three ‘sublanes’. These sublanes are of course not mapped as separate ways, but as on turbo-lane with lanes=2 of lanes=3. Example: https://www.openstreetmap.org/#map=18/51.98101/4.22019

Thanks @Exe19 for your response! The physical separation of the lanes by kerbs and islands is the ground truth for using separate ways. Anyway, this is not a proposed scheme but a record of what I learned-by-doing about actual mapping practice. Most of it is standing practice, applied to improve mapping in this special situation. I agree that some parts of it could have used a proposal process, but that is an issue for the developers of the scheme.

The only really new tag is the optional roundabout=turbo, informing data users, such as navigation apps, of the type of roundabout they are dealing with.

I have added kerb=apron (earlier I used truck_apron, but this kerb type is not limited to trucks) to specify the kind of kerb used for central islands, but this is not specific for turbo roundabouts.

Peter Elderson

Thanks for your excellent points. I will comment here, and later decide how to use it in a real proposal.

embankment:crest as a synonym The :crest suggestion is meant to accommodate (please, appease) a group of mappers currently mapping dykes. they feel man_made=embankment can be used for all the edges. They maintain that specific parts of the embankment system should get their own tag, not being man_made=embankment. They do have a point, because not too long ago the wiki specified to draw a line around the whole embankment and tag it man_made=embankment. Nowadays, the bulk of mappers use it only for the crest edge. The wiki has been e I think I can get them to change their view by offering the synonym. This allows them to leave the situation as it is, until renderers support the new tag, then most of the work can be bulk edited. I can do that for them.

You are right that new mappers probably will use the new tag, which I’m sure will be rendered later. That is disappointing. However, I think it is more important to get the mapping right, without breaking existing mapping. in OSM, that is the normal situation. And they do have an alternative. This shoud be a temporary situation, of course. I plan to ask major renderers if they can commit to support embankment:crest as a synonym. If I can’t get a commitment, I will drop the synonym from the proposal. If it’s just practical Who-Will-Do-it I will try to get someone to code it and do a Pull Request.

I don’t think adding top_edge=yes to the tag already defined as indicating the top edge helps. It adds no information, and to be honest, it feels a bit silly! It has been suggested to map all parts of an embankment as man_made=embankment and add a =yes. But I have chosen the easier solution, a separate value for the most important extra part: the toe edge. I know that for data users, handling a single tag is easier than evaluating a secondary tag, so easy does it. I have asked dyke experts what parts of dykes would deserve separate mapping, that can't be handled by combinations of crest, slope and toe elements, and nobody came up with anything! Had there been five separate elements deserving mapping, I would probably not have gone for separate man_made values, but for a more systematic approach incvolving secondary tags.

The term crest For embankments, the term crest is very well known I think. Thinking about a dyke, crest means the top surface, but it is rather vague and the edge is also called crest (e.g when the crest surface widens and becomes a residential area; the area is not called crest, but the edge is.) In OSM it is not uncommon to map area features as nodes, ways, closed ways, polygons and/or MP’s. So I think I will stick with the word crest. If the word embankment can be mapped as just an edge, embankment:crest for the crest edge is already one step up!

top_edge I have thought about it, but I think it’s too general. The top of an embankment is called a crest, I think that is more important than expressing that you map only the edge. And, mind you, you can map the the complete crest with this proposal, by outlining the crest area with man_made=embankment:crest. One of the examples illustrates that (sound barrier wall example) I am not proposing a mapping for all kinds of slopes, just embankments. Other specific slopes could follow the example, but should use their own terminology.

slope or face I think slope is the common name in spoken language. Face is mostly used in schematic drawings of (large) dyke structure. I think the English discussion would have corrected me if I had it wrong. In Dutch it is called “talud”, which is always translated as “slope”.

Fr Gr Peter Elderson

About the Houston problem. MapComplete, I think, was called MapComplete with a wink to StreetComplete. This generates the confusion and keeps it alive. Would it be totally unthinkable to rename? MapYourTheme, Mapatheme, MapOnTheGo, Maps4U. MapFillary (sorry no, strike that one).

MapYourTheme could be paraphrased in specific themes: MapYourBench, MapYourShop, MapYourTap, MapYourPub.