Tagging/interpreting additional parameters when cycle infrastructure is only a part of a highway

General talk Tagging general discussion
, , ,
1

Hi all,

I’m one of the people working on QECIO (QECIO 2.0: Quantifying Europe’s Cycling Infrastructure using OpenStreetMap). We’re very much interested in what we can learn about quality of cycle infrastructure from OSM, and one of the stumbling blocks is the interpretation/tagging practices in cases when cycling infrastructure constitutes only a part of a highway feature. For example, when you have a painted cycle lane on a carriageway, or when cycle track and pedestrian track are next to each other and represented as the same highway. Are there some principles of “inheriting” properties from “parent” components?

Example 1. highway=tertiary + cycleway:right=track

If cycleway:right:surface=asphalt, it’s obvious that the surface of the track is asphalt. But what if there is no cycleway:right:surface set, but:

a) cycleway:surface=asphalt?

b) surface=asphalt?

Can/should I check the more general tags to take the “quality” properties, or is the intention that only the exact match (i.e. cycleway:right:surface for cycleway:right) is valid?

Does the answer change for cycleway:right=lane? It’s not very common that a cycle lane has a different surface that the rest of the carriageway, but it can happen.

Does the answer change for other parameters, such as width? oneway?

Example 2. highway=path + foot=designated + bicycle=designated + segregated=yes

During State of the Map EU someone said that in cases liked that cycleway:width and footway:width should be used to specify widths of the cycle and pedestrian part separately. Is it documented/proposed somewhere? Doesn’t seem to be used much in practice (overpass turbo)

Most often I see just width, surface, smoothness etc. And sometimes it seems to mean the total width of both pedestrian and cycling part, but sometimes only one of them. Is there some guidance how cases like this should be tagged/interpreted?

Does the interpretation change for highway=cycleway or highway=footway, if the other tags (foot=designated + bicycle=designated + segregated=yes) are still there?

2 Likes
2

Can/should I check the more general tags to take the “quality” properties

Yes. Think of the tags as meaning

  • surface=asphalt - the road is surfaced in asphalt
  • cycleway:right=lane - a part of the road (on the right) is a cycle lane

Does the answer change for cycleway:right=lane?

No.

Does the answer change for other parameters, such as width? oneway?

No, but bear in mind that if you have

  • width=6 - the road is 6m wide
  • cycleway:right=lane - a part of the road (on the right) is a cycle lane

that doesn’t mean “the road is 6m wide and the cycleway is also 6m wide”, it just means the road (including the cycle lane) is 6m wide.

During State of the Map EU someone said that in cases liked that cycleway:width and footway:width should be used to specify widths of the cycle and pedestrian part separately. Is it documented/proposed somewhere?

Prefixing a tag to mean “only applies to this bit” is very common usage. I have no idea whether it’s documented on the wiki but the wiki is about as useful as a chocolate teapot, and significantly less tasty.

2 Likes
3

For cycleway:right=lane it is safe to assume that it has the same surface of road. Different situation may happen, may be tagged specifically. Maybe untagged but this is really rare.

For cycleway:right=track you cannot reliably guess/inherit surface info of the track based on surface of carriageway.

4

This tagging thread has been moved to general:tagging.

5

Ok - makes sense, but looking at the wiki, it should be the width of the carriageway, not the road. So cycleway:right=lane should be included in the width, but cycleway:right=track - should not. Right?

Still, I’m somewhat confused when interpreting the second group of cases (pedestrian/cycling infrastructure, no carriageway per se). I suppose that for highway=path the width should represent the total width of cycling and pedestrian infrastructure together - that would be logical. But does highway=footway or highway=cycleway imply a different “default” target for additional parameters?

I think I’m not the only one confused, because you can find examples of different interpretations even within the same city. For example, here we have highway=footway, bicycle=designated, segregated=yes, and width=2 seems to apply only to the pedestrian part: Way: 654584028 | OpenStreetMap. But just a little bit further, with the same combination of tags, width seems to represent the total width of pedestrian and cycling part together: Way: 989034701 | OpenStreetMap

Which one is correct?

And the same question for highway=cycleway, foot=designated, segregated=yes:

6

Edit: It seems that parts of the documentation in the wiki changed after I read them the last time a few years ago. It seems the definition is pretty clear now: width of a highway is from kerb to kerb, i.e. including cycleways, shoulders and parking lanes.
It should be best practice to add specific tags for every part of the road that is known.

(Disclaimer: my own point of view, but I think there are not many widespread contradicting opinions here)
On a regular highway: The width is always the width of the whole object, including all lanes, cycleways, sidewalks, shoulders - whatever is tagged on the object.

To know the width of the individual parts we have shoulder:width, sidewalk:width, cycleway:width. The remainder should be the width of the “normal” traffic lanes. If there are no sidewalk tags I think it’s safe to assume that width does not include the width of a potential, untagged sidewalk.
One caveat: We don’t have an established tag for the width of the regular lanes only. There is the option to add the width of each lane using width:lanes. There are also very few cases of width:carriageway for this purpose.
Obviously every *:width tag can be supplemented with a left/right/both infix as necessary.

On a path / footway / cycleway I would also assume the width describes the width of the whole object.
The best way to describe the width of each of the segregated parts is a bit unclear to me.
Many people use footway:width and cycleway:width. On the other hand the generic *:lanes syntax is very helpful here as well - it allows to describe not only the width, but also the arrangement of the two parts.

7

Are you saying that is how you think it should be defined, or how it is mainly used in practice? I don’t think actual usage is that clear-cut.

StreetComplete, for example, explicitly asks for the width from curb to curb excluding sidewalks (at least for highway=residential). So there must be quite a few instances of that definition in the database from that app alone.

8

I think the discrepancy is that sidewalks are very commonly mapped as separate ways, in which case the roadway might have sidewalk=separate, but the roadway’s width=* wouldn’t include the width of that separate sidewalk, or the verge in between. It’s like how you wouldn’t include the width of the center median strip if the roadway is part of a dual carriageway. But if the sidewalk is only indicated by a sidewalk=both tag… :man_shrugging:

9

… or if it is not indicated by any tag at all…

(i don’t think the StreetComplete quest wording changes depending on sidewalk tags, but I’m not sure).

Link to the start a long mailing list discussion from 2020:

https://lists.openstreetmap.org/pipermail/tagging/2020-September/055362.html

10

I edited my answer from yesterday. It seems the wiki is much more clear now than I remembered.