If highway=driveway_crossing
is a good idea for these connections, should iD automatically add it when the user resolves the validator warning about a footway crossing over a driveway? It would replace the option to connect the ways without any tags, above the option to connect them with highway=crossing
.
At one point, iD started tagging railway=tram_crossing
and railway=tram_level_crossing
every time a user connected a tram line to streets and sidewalks. The idea was to avoid diluting the meaning of railway=crossing
and railway=level_crossing
, respectively, while still emphasizing the heightened risk of conflict between trams and pedestrians or vehicles. This generated even more controversy than when iD was adding highway=crossing
tags at driveway–sidewalk connections.
The different solution I have in mind is that you can consider every driveway–sidewalk connection to be a driveway–sidewalk connection. For analysis use cases, the Overpass and QLever queries earlier in this thread show how to do that pretty straightforwardly.
If you really want your pedestrian routing profile to prefer stress-free stretches over stretches with many conflict points, then it can slightly penalize a route for every navigable way it passes, but not by as much as the penalty for crossing at a highway=crossing
node. These penalties would add up along any driveway-lined street. I’d imagine the penalty would be on the same order of magnitude as the one for service=parking_aisle
in a driving profile, which accounts for having to pause for the occasional car backing up, in contrast to a parking lot perimeter road that would have fewer such obstructions. Perhaps the new penalty could be higher at the time of morning when commuters tend to pull out of their suburban driveways.
This is simply a matter of setting a penalty for every transition from one edge to another in the routing graph. In an OSRM profile’s process_turn
function, you’d add to result.weight
. In a Valhalla dynamic costing model, you’d implement TransitionCost()
. I see you’ve contributed to BRouter’s trekking profile, which seems designed to prefer this sort of stress-free route. I’m not as familiar with BRouter, but maybe it has analogous facilities for penalizing edge transitions.
Notice how this heuristic doesn’t consider highway classification at all. During graph traversal, OSRM and Valhalla can consider whether the user is currently on a sidewalk, but the routing engine doesn’t know enough about the cross street at that stage to distinguish a driveway from a trunk road. In other words, if we start using highway=crossing
indiscriminately, it becomes algorithmically impractical to distinguish the crossings that need a major penalty from the ones that only need a minuscule penalty.

also around here it is usually not the case. The sidewalk gets interrupted for almost any driveway, and you can feel lucky if the kerbs are lowered where you cross, which is now usually done, but only since a few years in my area, so that most places have 2 raised kerbs for every driveway-crossing.
I’ve seen this fairly frequently in older neighborhoods where there isn’t a verge between the sidewalk and the street. The sidewalk gets interrupted by every driveway apron with a raised curb around it. One common solution is to double the width of the sidewalk, making the newer part of the sidewalk more level. That apparently happened on one street near me, but the city made sure to put tactile paving on either side of some parking lot entrances just in case. The tactile paving interrupts the sidewalk, so in my view, there’s a highway=crossing
even without curb cuts.

File:Tactile paving on sidewalk at parking lot entrance along Taylor Street, San Jose, California.jpg
Anyways, by itself, the presence or absence of highway=crossing
doesn’t guarantee a certain level of safety or risk. It’s a heuristic – an assumption – that probably works better in some places than others, for some user demographics better than for others.