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.
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.
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.
onlycycleway: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.
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)
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).
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.