Thanks @JPinAR for your views and comments! My focus currently is to clean up the mess that persisting historic mapping and tagging schemes and tools have left us with. E.g. many mappers still think that zebra crossings are to be tagged with crossing=marked + crossing:markings=yes, expecting others to interpret this tag combination as a zebra. So we (the Dutch) are nowhere near agreement on the optimal way to tag crossings. Maybe in the future all will agree that ways are the way to go, but currently mapping crossings as nodes is overwhelmingly more popular, and way-fans are simply outnumbered. The best I can try to achieve now is consistency within an acceptable bandwidth, so that a later move to mapping crossings as ways would be easier to accomplish (read: automated or semi-automated).

That’s one of the reasons I like the concept of mapping both the crossing way and the crossing node, tagging details either on the way or on the node, but not both. This way mappers can use their personal preferences, without creating another mess. In the end, to switch to tagging crossings as ways, you’ll just combine the tags on the preferred object, whatever that is.

About directionality: a crossing in OSM is seen as a path, footway or cycleway crossing over a higher order way. So details on the crossing node such as crossing markings, signal control, tactile paving, designation/access, kerbs, and for cycleway crossings, oneway, always apply to the crossing way (lower order), not to the crossed way (higher order). The cyclist has to ride the crossing way (as allowed) and pass the node that’s part of it, so I think all the information is there. The exact geometric position of kerbs, islands, etc is not available, and if an application needs that, it has a big problem… solvable, of course, theoretically, but that requires a lot of change management. Which I don’t see happening in Nederland for the next few wee/^H^H^Hyears.

About bicycle=yes and bicycle=designated. My preference, in this stage, is to simply go with the access and designation of the crossing way, and add only the rare exceptions on the crossing node. If bicycles are not the intended crossers but allowed e.g. on the pedestrian crossing, then the crossing footway is tagged bicycle=yes. The access/designation of the crossing is to be taken (by data users) from, or defaults to, the crossing way. (I know there are edge cases where it is not so simple, but solutions can be found, I am sure).

I will read the draft cycling page tomorrow, thanx for the link. I think I need a clear head for that!

Thanks @SiennaShade for your thoughts. You may have noticed I don’t use the crossing key at all for crossings; only crossing=no for non-crossings. I did notice that other mappers tend to get very touchy about crossing=*, so in my efforts to improve the mapping and tagging of crossings, I left the crossing key alone, mostly, unless it was clearly wrong. My preferential mapping does not require a crossing tag.

Mappers in Nederland definitely did not deprecate crossing=zebra. I think they have a point when they say that zebra is the only value of crossing that describes a generally known type of crossing, so that’s what they use for starters, and the rest is up to mappers who want to add more detail. As far as I am concerned, that’s fine because I don’t rely on the crossing tag at all. I think the international overall picture is just as mixed and chaotic as the Dutch situation.

I don’t agree with your assessment that crossing=zebra is confusing, though. I think it is the one value that is not confusing at all! It says exactly the same as crossing:markings=zebra. In a few countries crossing=zebra has been used for crosswalks of any kind; I think that is wrong, and probably confuses mappers in those countries, but that is not due to the value but to the wrong usage in those countries.

In Nederland, I have reviewed nearly all the zebra crossings, and added crossing:markings=zebra to all crossing=zebra nodes and ways and crossing_ref=zebra nodes and ways. As far as I am concerned, crossing=zebra and crossing_ref=zebra could be (and should be) safey removed without losing any information, but many mappers are very attached to their historic styles of crossing mapping (and the different presets of various tools), so I am not touching that wasps nest!

I did do a cleanup of crossing=informal (1 remaining in Nederland!) and crossing=no. Many of those were mistagged because of unclear wordings in the options of a StreetComplete question (now improved . The mappers did not even know what they had mapped.

@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: osm.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.