Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Direction confused ~on city_limit sign~ when area is glued to way with direction-node #5634

Closed
tordans opened this issue Dec 20, 2018 · 4 comments

Comments

@tordans
Copy link
Collaborator

tordans commented Dec 20, 2018

Case: There is a road which is glued to the area next to it.

This is here: https://www.openstreetmap.org/edit?way=198948464#map=20/50.81705/6.37598

The direction indicator seems to be confused by the glued area + road.

no direction:
bildschirmfoto 2018-12-20 um 08 15 00

traffic_sign:direction=backward
bildschirmfoto 2018-12-20 um 08 14 46

traffic_sign:direction=forward
bildschirmfoto 2018-12-20 um 08 14 54

traffic_sign:direction=both
bildschirmfoto 2018-12-20 um 08 18 26

Workaround:

  • unglue the node, which duplicate the sign-tag to the area as well as the road.
  • move them around to see both
  • remove the wrong sign tag on the area
  • move the road back and find a new place for the area node
@bhousel
Copy link
Member

bhousel commented Dec 20, 2018

I think the best thing to do here is just unglue the road from the landuse

@bhousel bhousel closed this as completed Dec 20, 2018
@tordans
Copy link
Collaborator Author

tordans commented Dec 27, 2022

In the spirit of documenting edge cases:

This issues does happen as well, when using area:highway with highway=traffic_signal. Ungluing those is not a good solution.

Example: https://www.openstreetmap.org/edit?note=3490280#map=20/52.48743/13.43160


This came up in a different context as well (https://www.openstreetmap.org/note/3490280). It looks like Garmin Navis do have similar rending effects as iD. The notes talk about a Garmin navi that showed 4 traffic lights instead of one.

@tordans tordans changed the title Direction confused on city_limit sign Direction confused ~on city_limit sign~ when area is glued to way with direction-node Dec 27, 2022
@SupaplexOSM
Copy link

fyi: I just started a thread in the forum on this phenomenon.

@1ec5
Copy link
Collaborator

1ec5 commented Dec 27, 2022

#9013 tracks another case of this issue involving stop signs and non-roadway lines.

tyrasd added a commit that referenced this issue Dec 4, 2024
for certain vertex features, only look at matching parent ways when determining where to draw direction cones:

* highway related points (e.g. highway=stop/yield/etc., traffic calming, cycleway=asl, traffic signs, barriers): only look at parent ways with highway=*
* railway related points (e.g. railway=milestone): only look at parent ways with railway=*
* waterway related points (e.g. waterway=milestone): only look at parent ways with waterway=*

see also #5634
tyrasd added a commit that referenced this issue Dec 11, 2024
for certain vertex features, only look at matching parent ways when determining where to draw direction cones:

* highway related points (e.g. highway=stop/yield/etc., traffic calming, cycleway=asl, traffic signs, barriers): only look at parent ways with highway=*
* railway related points (e.g. railway=milestone): only look at parent ways with railway=*
* waterway related points (e.g. waterway=milestone): only look at parent ways with waterway=*

see also #5634
tyrasd added a commit that referenced this issue Dec 11, 2024
for certain vertex features, only look at matching parent ways when determining where to draw direction cones:

* highway related points (e.g. highway=stop/yield/etc., traffic calming, cycleway=asl, traffic signs, barriers): only look at parent ways with highway=*
* railway related points (e.g. railway=milestone): only look at parent ways with railway=*
* waterway related points (e.g. waterway=milestone): only look at parent ways with waterway=*

see also #5634
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants