I’m not so sure about that. Separately mapped sidewalk ways have become significantly more popular among both mappers and software developers in the years since the approval of footway=sidewalk
, but I don’t think the approval was the decisive factor. The proposal made presets, QA tools, imports, and router optimizations more likely, but I suspect a lot of that would’ve happened anyways.
Perhaps that would be true if we simultaneously require an unprotected pedestrian lane (that is, one without bollards or other barriers) to be tagged on the roadway and never mapped as a separate way. But mapping an unprotected pedestrian lane as a separate way that violates the physical separation rule would create problems. For one thing, a router would never be able to instruct you to cross the painted white line. It’s no different than if someone decides they’d rather map car lanes as separate ways.
Assuming we aren’t pushing to relax the physical separation rule, we should avoid dissonance between the meaning of sidewalk=*
and footway=sidewalk
to the extent possible. They may be syntactically different and correspond to different highway=*
values, but there’s already enough confusion about what counts as a sidewalk without it meaning two different things depending on context.
I would quibble with the wiki’s current characterization of footway=lane
:
Most often used as a property of separately mapped highway=footway, which is problematic since one shouldn’t use separate OSM ways for lanes which are not physically separated. But there is small number of cases where footway=* is mapped as a property of the road like highway=residential - that is however also problematic, because it fails documented Key:footway requirement that it should only be used as a refinement of highway=footway.
Unless I’ve gotten my OverpassQL wrong (entirely possible), only 30% of footway:*=lane
are on highway=footway
; the rest are on other kinds of highway
, and regardless this tag is very lightly used overall. As I pointed out above, the wiki doesn’t require that footway=*
only be used for iterative refinement of highway=footway
; it just points that out as a matter of fact, because of the approved proposal for two values of that key. If individual approved values of a key automatically hold a monopoly on the key’s meaning, then that’s another reason we needn’t vote to approve historic=*
.
It sounds like you’re focusing on a router’s basic need to find a suitable route, which is understandable. But for better or worse, routers such as Valhalla also allow users to decide how much or little they want to use the street versus a sidewalk versus a dedicated path. Moreover, renderers and analysis tools such as A/B Street need to produce a realistic layout of the streetscape based on the available ways and tags. As a mapper, I’m not in a great position to decide which infrastructure the router or renderer should know about and which it should be oblivious to. Sometimes none of that infrastructure is particularly useful anyways.
The repositories of GraphHopper, OSRM, Valhalla, and the rest make pretty clear that it’s highway=footway
, not footway=*
, that makes a footway. I would be surprised to find a major editor or renderer that styles a bare footway=*
as a footway. Do you know of any? Since footway=*
without highway=footway
is so rare, we have an opportunity to define the meaning of that combination, which is otherwise nonsensical.
Like you, I often skip prerequisite tags when forming Overpass queries in hopes of a faster query. (It probably avoids unnecessary JOIN
s under the hood.) But if I want to count all the footways, regardless of type, I’m much more likely to query for highway=footway
than footway=*
. highway=footway
is what Overpass turbo’s wizard produces for "foot path"
, thanks to iD’s “Foot Path” preset.
But let’s suppose you couldn’t query for highway=footway
or exclude footway=lane
for some reason. If querying for footway=*
turns up too many false-positive non-footways, that would be an argument against this style of iterative refinement. Rather, it suggests that we should be prefixing the secondary keys, as in highway:footway=sidewalk
or footway:type=sidewalk
. But that ship sailed a long time ago.