[Tagging] Crossing tagged on both way and node (was: What does bicycle=no on a node means?)

[Adam Franco]

As someone who renders a driving-focused map
<https://roadcurvature.com/map/> of [the most twisty] roadways, I
specifically have done exactly what Volker describes (looking at
highway=crossing nodes only).

To provide an example, my renderer walks down each vehicle-legal way and
demotes the curviness weighting for a distance in each direction whenever
it encounters a highway=crossing node on that way (or nodes with
highway=stop, highway=traffic_signals, barrier=traffic_calming, etc). This
particular map doesn't care about the geometry of footways, sidewalks,
paths, or buildings, so it can look at a much reduced data-set of just
vehicle-specific highways. If highway=crossing nodes aren't available and
crossings are only indicated on intersecting ways, then I'd have to add a
preprocessing step to build a list of all nodes that are members of a
highway=crossing way and then add that to the list of nodes tagged with
highway=crossing. I guess it's not an impossible task, but it is much more
simple to just look at nodes that are also members of the
vehicle-accessible highway ways.

I know OsmAnd can be configured to alert drivers of upcoming crossings (and
stop signs), but do not know if that router works only with nodes on the
ways of the current route or also does matching on crossing ways.

On Thu, Oct 15, 2020 at 1:06 PM Volker Schmidt <voschix at gmail.com> wrote:

> I don't know what the routers need, to be honest.
> I have adopted the approach happily because of the frequent two-stage
> approach. First the main road is mapped with foot/bicycle crossings as
> nodes , and at a later stage someone else may add the foot/cycleway
> details  - I did not occur to me that there may be an advantage in removing
> at that stage the already existing crossing node.
> I would also naively assume, that a car-only router does not need to
> inspect any of the foot/cycleways in the map, and can use the
> highway=crossing nodes as an indication to add small delays inthe routing.
> Anyone in the router business listening in on this conversation?
>
> On Thu, 15 Oct 2020 at 17:39, Jmapb via Tagging <tagging at openstreetmap.org>
> wrote:
>
>> On 10/13/2020 6:30 PM, Kevin Kenny wrote:
>>
>> On Tue, Oct 13, 2020, 17:41 Volker Schmidt <voschix at gmail.com> wrote:
>>
>> I changed the crossing to the way we do it in many parts of Europe, i.e.
>>> a crossing node *and* a crossing way. This was described as an option
>>> on the highway=crossing wiki page until it was changed on 07:52, 3 October
>>> 2020by user Emvee <https://wiki.openstreetmap.org/wiki/User:Emvee> by
>>> addng the diagram and its description.
>>> If you don't like it, please change it back - I used it in place of a
>>> longish explanation.
>>>
>>
>> Both of those are better, thanks! The routers that I use for testing seem
>> to be aware of crossings without crossing nodes, so I too often forget to
>> tag them.
>>
>> I've always been surprised to see a footway=crossing/cycleway=crossing
>> way with the intersection node tagged as highway=crossing. There's only a
>> single physical crossing, so this seems contra to the
>> one-feature-one-element rule.
>>
>> A highway=crossing node makes sense in an area without mapped
>> footways/cycleways. But if the crossing ways are mapped, routing software
>> will need to examine the intersection node and scan the properties of all
>> highways intersecting there. It seems to make tagging the node itself
>> redundant.
>>
>> Are there really routers that require the node be tagged as well?
>>
>> Jason
>> _______________________________________________
>> Tagging mailing list
>> Tagging at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/tagging
>>
> _______________________________________________
> Tagging mailing list
> Tagging at openstreetmap.org
> https://lists.openstreetmap.org/listinfo/tagging
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/tagging/attachments/20201017/46c38a8a/attachment-0001.htm>