Micromapping cycleway/footway infrastructure

I write this as a continuation of those discussions:
Mapping the position of the cycleway and footway relative to each other
Reworking the wiki Bicycle page
But there we also more.

Latelly I have micromapped more of bike infrastructure with:

  • detailed crossings, not only though streets, but through each other as well so it is clear if pedestrians or bike got to yeld the way
  • tactile_paving primarly on kerbs, but also on ways when present, that requires to be detailed and never vague, coz people who we map it for simply can’t see for themselves
  • for the above it’s necessary to map cycleway and footway ways separatelly, but thanks to that their position is actually rendered and everyone can see if it’s on the right or left
  • smoothness and surface is also important,

Out of the 4 points, only the last point is partially wiki specified if everything is not mapped separatelly.

Example of those crossings with kerbs with tactile infomation:

Lately i have noticed that in a polish city soomeone is removing all bike infrastructure that was mapped separatelly and merges it so vaguelly, that there is nothing to gain and much to loose.
So i have micromapped it instead with all those above details, but also added
.+ missing entrances
.+ footways coming out of it
.+ unmapped crossings

You can examine it here in those removals examples:

  • crossings are gone
  • no tactile information
  • no information on position of the cycleway, but only that it’s separate
  • unpreciselly mapped surfaces and no smoothness mapping

This a regress and not only for people with impaired sight disabilities.
A lot of detailed mapping goes to waste, just because someone thinks that bike and foot infrastructure can’t be detailed and keep reverting my work.

Please advice
if OSM mapping should be so vague or it should be detailed like i aim it to be.

3 Likes

Yes, there are several concerning reductions in detail in that changeset, but it says it was done with JOSM reverter_plugin - @kubahahaha for their side of why this was reverted.

Pathway dodging an obstacle is entirely gone:

image

2 Likes

The key question I have is: are these cycle and foot paths separated by kerbs, or are they just painted lanes? If there is no physical barrier between the cycleway and the footpath, people would not normally map them as separate ways.

From what I can see at a glance, the cycle and foot paths are simply different colour paving stones or asphalt, which means they shouldn’t be drawn as separate ways.

14 Likes

I see little merit in mapping cycleways and sidewalks separately from each other and from the roadway - this road is starting to get too complicated: OpenStreetMap

In general, I would not map cycleways and sidewalks separately from the roadway unless there is specific reason to. All too often, people see a road and a sidewalks and map them separately, while neglecting to meaningfully add any tags to either or deal with junctions properly.

If a road is divided into many segments, that can create a (substantial) maintenance burden. Many segments can be caused by (a) mapping the road and cycleway/sidewalk separately and (b) having so many tags on a single way that some characteristic or other changes frequently.

Here: Way: 585021095 | OpenStreetMap the mapper has been quite conscientious and mapped much of the footway perimeter of a large block as a single way. However, at the shops at the northeast corner it becomes complicated and inconsistent, e.g. some crossings are ways, others are node, some crossings aren’t properly done. If I want to add lit=* to those roads, I have to add it to the road and the footway separately, and these are split into segments at different points. There are then many short segments dealing with junctions and crossings - but some are missing. Overall, the splitting makes adding lit=* more difficult than it should be.

Here: Way History: 585021095 | OpenStreetMap we can see the effect of the problematic way in which some of the footways are not joined up at junctions and crossings - something that wouldn’t happen if the sidewalks weren’t mapped separately.

Specific reasons to map them cycleways and sidewalks separately from the roadway:

  • The road and cycleway/sidewalk diverge from each other for a distance. Example: Way: 724624999 | OpenStreetMap
  • There is a material separation between road and cycleway/sidewalk, e.g. there is a fence or wall between them. A tree line or a grass verge would not normally be enough. Here: Way: ‪Mountainview Crescent‬ (‪233819616‬) | OpenStreetMap it seems to be a combined wall and low retaining wall.
  • The highway is heavily tagged (more than about 15 tags) and it is becoming necessary to excessively split the way into shorter and shorter segments. For example, on Old Navan Road here: OpenStreetMap - look at the Esri World Imagery. In a distance of 250 metres, the road rapidly grows from 2 (north end) to 7 (south end) lanes wide and gains a two-way cycle track on either side. This 250 metres uses 5-6 segments to get from north to south. Any additionally tagging risks have to split these segments even more.

I don’t think we’ll ever have consensus on this issue. My two cents: I wouldn’t necessarily recommend others to go into this level of detail, but I can see sensible reasons to do it (e.g. so you can faithfully map the different attributes of the two crossings on the bottom right, like lowered/flush kerb, markings, tactile paving…). However, the more detail you add, the higher the risk of getting things wrong (forgetting that the cycleway is oneway, missing crossings, missing links, leaving duplicate tags on the main way, …). In such cases (which I’m assuming wasn’t your case), I don’t mind throwing out the half-finished micromapping rather than spending a lot of time to correct it. But if it’s correct, I don’t think it should be our policy to remove it as a rule.

1 Like

Thanks for the mention.

First of all, I reverted this changeset because the user started adding details after reverting my previous changeset. In my changeset, I was merging separate footway + cycleway lines into a single path line.

I did this because there is no physical separation between the pedestrian and bicycle parts at this location. Everywhere I looked, the recommended approach was to map this as a single line. Most recently, the summary of the tagging guidelines I prepared on the Polish forum did not generate any discussion nor objections.
Additionally, these shared pedestrian/cycle paths had not been mapped consistently, so I decided to standardize them using a single (recommended) tagging scheme.

They are just painted lanes.


I’m concerned that the user is trying to influence your opinions by presenting the situation in a misleading way. The entire discussion (which previously took place on the Polish part of the forum) was about reverting my changesets that merged separate lines into a single line. Only after my changeset had been reverted were some of the additional details we are discussing here added.

I have nothing against mapping tactile_paving, kerb, smoothness, or surface. Some of these tags can easily be added, for example, using StreetComplete, which correctly supports such ways.


According to Polish regulations, the crossing shown in the image on the left is not a pedestrian crossing (there are no appropriate signs). It is a suggested crossing instead. The main difference is the right of way: in such a situation, bicycles have priority, on crossings pedestrians go first.
We usually map such places as a node with highway=crossing + crossing=unmarked, but this may be misleading here, since it is clearly visible that crossing:markings=zebra.

Another issue is the double mapping of pedestrian crossings and bicycle crossings on roads for motor vehicles, especially when crossing=traffic_signals is used. Navigation software may potentially apply the penalty for passing through traffic lights twice.


If someone proposes that these locations should instead be preferentially mapped as two separate lines, then that would require a separate discussion. At the moment, based on the number of reactions to this post, I got the impression that there is a consensus in Poland to map such paths as a single line.

2 Likes

yeah, but it is not the place i make argument about.
In your example:

  • no kerbs that legally make a cycleway boundary
  • zebra marked crossing that is visible before the sign, because it’s before it, we can’t actually say that cycling and walking is segregated
  • and so if segregated=no - traffic is not legally segregated, dividing it into two separate lines, (especially that tactile_paving isn’t anyway) serves no good purpose IMO

also that watermarked screenshot is ©2026Google
so it is a very good subject case example we can talk about and which is hard to forget when mapping, but obviously i did not use google to make my mapping.

So please make your points about the area with screenshot that i made (first post) if you’d like to talk about the 4-point features mapping that i introduced.

@VictorIE
I’m happy you see merrits.
But yeah, we always gotta choose. Mapping sidewalks separatelly from a carriadgeway create some issues, but in the end there is more gain, as you can mark where are those crossings through huge intersections with traffic islands and if there are other details like tactile_paving
But yeah, things can go really complicated and require details when it’s actually a footway around a cycleway, not just a carriadgeway

  • where do the cyclists give way to each other but also to others
  • tactile_paving mapped on ways, not just kerbs

Mapping details tagged over one single carriadgeway with complex infrastructure, wouldn’t you agree?

@Ruben_Van_de_Velde
Yeah, there is a problem with consensus. There may also be a problem with mapping all the details everytime and update over time.
But does that mean we should just give up precise mapping for sight impaired people and in general to people who want to look at the map and know where are the crossings they gotta take?

1 Like

if method that you try to use is against consensus then “but sight impaired people” is not allowing you to override it

in such case you need to convince people or invent less controversial mapping method

3 Likes

That’s a long thread, and I don’t speak Polish. Has anyone in that thread raised this specific issue with intersections? It’s one thing to say you don’t need two separate ways to map lanes of the same path (seems pretty uncontroversial to me), and quite another to say that none of the distinct features of each path in this intersection should be mapped:

You’d be losing a lot of information by merging that whole intersection into one or two nodes. I suppose if the Polish community really wants to say that mapping such details is not allowed that’s fine, but I don’t think you can argue that’s the consensus just based on the fact people agreed two simple lanes right next to each other don’t need to be separate ways.

2 Likes

That’s not what @kubahahaha has done. He has just joined sidewalk and cycleway into one path. The rest has been left the same.

noone is arguing that, noone has problems with say Key:cycleway:surface - OpenStreetMap Wiki

I’m not talking about basic attributes like cycleway:surface.

How do you map the fact that the footpath crosses the cycleway here without separate ways? Let alone all the attributes of that intersection, like who has the right of way, the roadway markings at the intersection, the presence or absence of tactile paving, the fact that the crossing only exists for pedestrian traveling east-west, etc.)

2 Likes

something like

tags indicating that cycleway is on left side of combined footway/cycleway – highway=crossing node – tags indicating it is on right side of combined footway/cycleway

2 Likes

then “quite another to say that none of the distinct features of each path in this intersection should be mapped” (emphasis mine) is not a claim that should be made, if basic distinct features are perfectly fine to be mapped

This should be a highway=cycleway foot=designated segregated=yes, not a path, right?

EDIT: segregated yes

this belongs to silly OSM discussion which main tag is preferred here, but as long as surface is tagged it does not matter much

(in Poland highway=path dominates for some cursed reason)

Okay “quite another to say that only a small fraction of the distinct features of each path in this intersection should be mapped”. Happy? Removing the obvious hyperbole does not change my point.

This is a good idea I hadn’t considered (even though I’m not sure those tags exist yet?), but still misses a ton of detail about the intersection itself (pavement markings, tactile paving, legal right of way etc.)

Perhaps you theoretically could design some sort of extremely complicated tagging scheme for fitting all that information into a single crossing node and a bunch of relations, like how highway handles turn restrictions and lane markings (it took me hours to figure out how turn:lanes and placement are supposed to interact with connectivity and restriction relations, and I think a lot of that still isn’t even supported by data consumers) but that seems completely impractical to me compared to just using the highly mature and well supported tagging scheme that already exists for mapping such intersections with separate ways.

Anyway I don’t live in Poland so I don’t really have a horse in this race, my point was just that I don’t think it’s fair to use general consensus about a couple very simple cases where there’s little to no benefit to mapping as separate ways as proof that the community thinks you should delete a bunch of information in a complicated intersection.

standard property of highway=crossing

either not derivable from either or can be derived from both

no idea, if someone cares about tagging this level of detail they can invent schema if it is not existing yet

Actually, it’s not. If you check OsmCha YogSot’s provided you can see that all tags are still there, only changed to match one-line tagging. I believe the only things it misses is the position of sidewalk and cycleway against each other. (I’m not sure if crossing;markings=zebra;dots means that zebra is on the left and dots on the rights or is it like “both are there we don’t know where”)*

*That one is kinda stupid on my part, I forgot it’s on node not line, so it can’t be left/rights.

To be clear, I’m talking about the intersection between the footway and the cycleway, not the intersection between the footway+cycleway and the road.

I’m having trouble finding the specific pictured intersection in the changeset you’re referring to, but in at least one place the intersection between the cycleway and footway (which previously was composed of multiple elements and had info on the intersection layout, markings, and curbs) was deleted and replaced with a single untagged node[1] on the combined way. (It’s still in that state as of now.)

(And as you discovered, “zebra;dots” just means both values are present, it doesn’t specify anything about which is on which side of the road or which type of path each is associated with.)

Edit: Found the intersection in question. It’s an untagged node now.


  1. node/4265396040 ↩︎