I can’t speak for anyone else but certainly cycle.travel’s renderer will parse it properly. I suspect you’re being influenced by openstreetmap-carto whose access parsing is famously bad.
It’s quite normal to tag the road behind a barrier with the same access tags as the barrier, depending on whether it’s possible to get around the barrier from the other end. In part this is because it isn’t always practical to depict a bollard at every map scale. I’m not sure if the “large pile of dirt” at the northern end is just a change in surface or a more substantial mound that could be considered a physical barrier, but that would be relevant information.
If this state park is in the U.S., it’s very unlikely that the signs are the whole story anyways, because legally enforced access restrictions aren’t always signposted on the spot. That’s especially the case in places that have controlled entrances: parks, cemeteries, nature reserves, university campuses, military bases, etc. A “Park Rules” board near the park entrance or parking lot would have every bit as much legal force as an MUTCD-compliant regulatory sign closer to the path in question, because you’re standing on park property either way.
For example, this driveway cuts through a nature reserve. It was built to provide vehicular access to an aqueduct pump station, but ever since the nature reserve was built around the station, the driveway has mostly been used by pedestrians admiring the wildflowers and shrubbery along it.
You wouldn’t know it just from that Bing Streetside photo alone, but if you ride your moped down this driveway, you would be violating the park rules, which are posted at the other entrances:
If caught, you would be kicked out of the park, and fined if any wildlife is harmed. Even so, it’s still tagged as a driveway, but with requisite access tags.
To me, access restrictions are important to tag no matter what. But if the decision between highway=unclassified and highway=cycleway/track hinges on access restrictions that aren’t immediately obvious, then maybe there are multiple acceptable answers and there’s no need for strong feelings either way.
1 Like
driveway is a bit different, as it is not associated with general access and as I understand “provide vehicular access to an aqueduct pump station” remains true here.
That explains things: cycle.travel’s renderer can be expected to show status for cyclists.
For openstreetmap-carto there was never a good idea how to convey access for diverse transport modes.
As I said, it’s mainly used as a park path like any of the others in the nature reserve. The pump station doesn’t need that much maintenance, but it is a popular nature reserve. But it’s just one example out of many. My point is twofold: that common sense about real regulations can mitigate the need for airtight signposting, and that these edge cases highlight inherent fuzziness in our tagging scheme that won’t result in severe adverse effects to end users, so no need to blow them out of proportion.
it depends on the situation. In the past some people added access restrictions applying to barrier points (lift gates etc.) also to the ways behind, e.g. to cater for some routing engine settings deficiencies, but it was discussed and stated since long that this should not generally be done, and restrictions should be put where they apply (ways, nodes, etc.). E.g. you could have a fence with a no access door and still have both sides of the fence generally accessible.
On the other hand, there are inconsistent situations where one side of a way has signs that aren’t there when entering from the other. These have to be sorted out in the individual situation.
Even so, it’s still tagged as a driveway, but with requisite access tags.
+1, this seems good tagging.
1 Like
Yes, osm-carto is very car-centric. This is not really a good thing, but fixing that on osm.org really means moving to vector tiles and that’s a whole nuther topic. 
3 Likes
While we getting off-topic: yes OSM-carto is very car-centric, but its access tag rendering is wrong, including for cars. It definitely should not be relied upon for any tagging decision or the like.
2 Likes
Lots getting ticked off on my bingo card here (thanks for “vector tiles”, Richard!)
Can you given an example of a specific problem? It’s clearly not wrong for cars all the time; and without an example it’s difficult to know exactly what you’re referring to.
The only destination tag that it renders is access=destination, that applies to all kinds of traffic including pedestrians and cyclists. In real life this is extremely rare, nearly all such restrictions apply only to motor vehicles or some combinations of such. This leads to clearly wrong tagging for the renderer and it would arguably be better -not- to render this at all.
Similar arguments apply to other access values, for example it is common that private roads don’t allow vehicle access , but will allow pedestrians … and so on.
3 Likes
Just a point on the distinction between motor_vehicle and motorcar - there are a number of countries and regions where the majority of road users are on motorcycle. So a road which is unsuited for a larger motor vehicle like a car, but is suitable for motorcycle travel, could be tagged like this.
However, in countries where this is the case this tagging is not common either because a) it’s assumed that for any road, most users are not in a car anyway or b) it is hard to verify if you don’t have a car anyway, are these lanes to narrow for cars? Regulations on this might not even be present so it could just end up being a guess
1 Like