“By definition, a sidewalk or sidepath follows a street or road. This key is one of several competing methods for indicating the street’s name when the sidewalk or sidepath is mapped as a separate way due to physical separation. Besides sidewalks, this tagging is also used on other street-related features to indicate which street they belong to. This includes, in particular, separately mapped street parking areas.”
does “other street-releated features to indicate which street they belong to” also include highway=service roads and foodways to buildings with adress-nodes?
This is a reference to micromapping street parking as amenity=parking areas and reassociating them with the street using street:name=*. It used to be the predominant use of the key, though it has since been eclipsed by usage on footway=sidewalk.
I would say usually not, but if the ways are considered part of the street then maybe.
In most places I’m familiar with, highway=service ways largely represent driveways and other minor service roads that are separate from the street they connect to rather than part of it. Adding street:name=Spruce Street to a driveway connecting to Spruce Street would not be appropriate since the driveway is not part of the street. The same logic would apply to footways leading from Spruce Street to the front door of a building once you’ve turned off the sidewalk onto the front walkway, you’ve left Spruce Street.
That said, there are some cases where highway=service is used for a parallel carriageway that is considered part of a street. For example here. This is usually a small physically separated part of the street for accessing parking and or connection to a cross street without disrupting the main traffic flow. Currently these are usually tagged with name=* the same as the main carriageway of the street, but I’m open to the idea that they could be tagged with street:name=* instead for the same reason we are using that tag on sidewalk ways. They are both ways that represent a part of the street rather than the main ways that represent the whole street.
To be clear: we’re talking about paths that do NOT run along a street nor are parts of it, but are separate entities (and are even separated from the street by a house).
Nevertheless, he wants to give them the street’s name because of some navigation issues.
Previously, attempts were made to resolve the navigation issues by tagging access information to highway nodes and later as tourist signposts (which doesn’t exist OTG).
No, as you know very well, the footway/path doesn’t have a name OTG, and isn’t even directly connected to the street you want to name it after. Take a look at your own link.
And at some point, please accept the majority opinion on this topic, both on the German forum and here.
More specifically, we’d need a car ↔ foot multimodal router. The multimodal routers I’m aware of only include foot, bicycle, and public transport. While the latter has its own problems, at least you don’t have to worry about parking. I think that’s among the biggest issues limiting the usefulness.
And with bikes, you can always just dismount and use the foot paths, so it’s almost trivial to get that part.
I’m not aware of any actual car and foot multimodal router. You can always simulate that by driving to the destination, searching for a parking spot (which noone can really help you with anyway), and then using a foot router from your parking position to the entrance.
Alternatively, a geocoder could infer a routable point from a site relation’s parking member or from a heuristic, such as the largest amenity=parking area on a named landuse=residential area that contains the building containing the address. The user would confirm the routable point, then the router would navigate directly there via car, ending with a “Find parking” instruction. (Apple Maps has essentially this functionality.)
