Hi,
near me someone started to map the way through a cycle barriers exactly along the route you would take passing the barriers.
Is this the next step of micromapping or just wrong?
In my opinion this is not correct. The way, as it is visible in the aerial, is straight and so should be the osm way. The curves are implied by the cycle_barrier. If you want to know the length of specific ways in an area, this tagging falsify the result. If you add width to this way, the result doesn’t really fit.
However, I am interested in your opinions.
Why do you think it must be straight, and this cause false results? The travel path is really longer.
We have come up a set of parameters, but drawing this on imagery could be easier than measuring them. I haven’t mentioned this possibility in the proposal to keep it focused. Likely no application will be able to calculate the travel distance from the parameters for a long time. Tag:barrier=cycle_barrier - OpenStreetMap Wiki.
The main question is whether to have multiple =cycle_barrier . There’s a significant distance between the 2 sets. There’s no =quadruple defined, up to =triple only. corners=4 still leaves cycle_barrier= unhandled, and it can again be debated whether the middle section forms a corner. It can be compared to =diagonal as well.
Adding cycle_barrier= to the highway= line at the same time may be a possible solution. Same as traffic_calming= point vs line.
It is wrong if the width of the way without the barrier and the course of the way (without the barrier) does not change (example).
However, bicycle-friendly cycle barriers where the way changes its course, should be mapped like this (example).
For calculating travel time, routing engines should apply a penalty on cycle barriers. Calculating the actual length of the route cannot be done that precisely with OSM because we map roads as linear ways, not areas.
I totally agree with you on that in both cases. Here it is actually case 1.
In the end, this small dents are almost irrelevant, for measuring road length, as well as travel time computation. This would quickly become a very academic discussion.
The underlying question is:
Does the object highway=path (or highway=* in general) represent the road or the way you actually take. In my understanding it is the first. In my understanding it represents the straight road on top of which there are placed some barriers by the administration. They may be removed or changed. This does not the affect the road.
On the ground they are easily to identify as two single cycle barriers. So =double is fine.
On the left side there is a larger street and right are tram tracks. I assume they shall protect in both directions.
That all sounds reasonable, but I have a nagging doubt. If the administration placed a barrier along the middle of the road, turning it into a dual carriageway, it would likely be mapped as two parallel ways. This seems to be accepted practice. Doesn’t that suggest that to some extent the highway object represents possible travel routes?
You may use area:highway= to show the roadway itself physically. The linear highway= is for routing. As mentioned above, if there’s a raised physical separator (even if removable) down the middle, it would be acceptable to draw a pair of lines. By this logic, following the travel path inside a =cycle_barrier doesn’t have to be wrong.
I still can not say I like it that way, but I can follow your explanations.
That’s right. But I am not sure whether this defines the OSM object. As we are not a routing provider but a geodatabase I understood the line always as a representation of the road in general. Probably due to the fact that this is a very niche case, I found no clear explanation/definition in the wiki.
An other point:
If one is interested in accurate travel time calculation, this tagging needs to be enhanced. The way it is, I expect thee router to penalize the multiple 90° angles. Additionally it will give a penalty for the barrier object.
