StreetComplete and redundant surface tags at segregated paths

Is this the way it should be? Is this redundancy necessary and wanted?

highway=path
foot=designated
bicycle=designated
segregated=yes

cycleway:surface=paving_stones
footway:surface=paving_stones
surface=paving_stones

surface and cycleway:surface were added by one StreetComplete 49.2 changeset.

3 Likes

Shouldn’t this be sidewalk:surface=paving_stones? The footway=* key is not intended to be used on regular highways as far as I know. (See Key:footway - OpenStreetMap Wiki)


Other than that these tags look fine to me. They may seem redundant but otherwise one could not tell if the cycleway is paved the same as the rest of the road. Although this also depends, if it is just a cycleway=lane, the same surface can be expected.

My question is related to separate paths (not cycleway=track/lane). I have formulated my request more precisely now.

footway:surface is the tag which StreetComplete is using.

Thanks for clarifying!
As these parts are segregated, different surfaces could be used. However, adding three surfaces (for a path with two parts) is very redundant. If they are the same, only tagging surface=* would be sufficient imo.

4 Likes

See related GitHub issue and PR:

3 Likes

It seems useful and wanted to me (but I’m obviously biased). While extra redundancy is not perfect, it is a very minor issue compared to much more problematic alternatives, i.e.:

  • only the surface=paving_stones is tagged: it is unknown if it applies only to footway, or only to cycleway part of the segregated path, or to both. Thus the data consumer may only assume unknown surface.
  • only cycleway:surface=paving_stones & footway:surface=paving_stones are tagged - it is clear what is meant to humans, but most data consumers would only know about surface=* and not various potential *:surface (and which of them to use anyway), so would show surface as unknown again.
5 Likes

But it would be also possible to define rules.

  • both is identical → surface
  • is different → footway:surface, cycleway:surface.

Only the data consumer knows if he is interested in cycleway or footway surface.
If they need the surface information I guess most of them will learn to evaluate cycleway and footway surface too.

(Is the same with cycleway, cycleway:both/left/right) we do not set an additional cycleway for backward compatibility)

1 Like

I get your point, but was wondering wat should then be tagged in surface=* if the two are different. Both of them? Just some generic surface=paved? The ‘most important’ one (which is that?)?

" Update surface to generic paved if footway and cycleway parts are different but paved"
This is what happens now since SC version 49 if both are different but paved-> surface=paved. I’m not sure what happend on paved/unpaved combinations.
I was able to use the redundancy a few times to track down incorrect values. With the automatic derivation of the “summarized” surface, this is no longer the case.

And often not even data consumer knows (for example, as it does not even have a concept of for whom it should render - many non-router data consumers fall into this category)

surface would get removed in such paved/unpaved combinations (but it is luckily much rarer combination than for example very popular asphalt+paving_stones)

True (and that leaving intact incorrect/obsolete surface was unfortunately what was happening with older versions of StreetComplete). Note however that there was not much you could do with certainty on finding such mismatch except removing all surface-related values and hoping someone would map it again correctly next time.

I find it preferable that SC mapper on the ground actually confirms the real situation which gets auto-fixed with correct tags. (because, if we can’t trust SC mapper on the ground to truthfully answer the questions, we have much bigger problem that summarized surface mismatching the more detailed one).

That would be also my idea: If there is a contradiction between surface and part:surface, ask the mapper again.

I don’t think it would be reasonable for a data consumer to consider the surface as unknown in this situation. If only surface=paving_stones is tagged, the data consumer should assume that the entire path has the same surface.

2 Likes