Modify

Opened 3 years ago

Closed 12 months ago

Last modified 12 months ago

#10260 closed enhancement (fixed)

warning on reversing ways with direction-dependent nodes

Reported by: anonymous Owned by: team
Priority: normal Milestone: 16.10
Component: Core Version:
Keywords: Cc: bigbug21, Nakaner, rayquaza, rurseekatze, naoliv, merten@…

Description

JOSM shall request for confirmation when one tries to reverse a way which consist of nodes with a tag contaning "forward" or "backward".

Attachments (1)

directionnodes.png (43.3 KB) - added by Klumbumbus 12 months ago.

Download all attachments as: .zip

Change History (24)

comment:1 Changed 3 years ago by Don-vip

Owner: changed from team to anonymous
Status: newneedinfo

Could you share an example? I'm not sure to see exactly what kind of ways have this type of nodes.

comment:2 Changed 3 years ago by skyper

I do not know who invented the usage on nodes but this is a complete mess. Forward/backward and left/right only work with ways.

Instead of adapting every editor to support this kind of tagging, you are perfectly set by using proper values for direction=*, e.g. cardinal directions or degrees, on nodes.

How do you handel situations where more than one way are connected to the node ?

comment:3 Changed 3 years ago by rayquaza

Here's something which depends on this: https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging
If there is more than one way they're supposed to be in the same direction.

comment:4 in reply to:  3 ; Changed 3 years ago by skyper

Replying to rayquaza:

Here's something which depends on this: https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging

This is a completely new tagging scheme and not established, yet. There is no reason to not use cardinal directions or degrees here.

If there is more than one way they're supposed to be in the same direction.

Well this might be true for railway but not for highway.

comment:5 in reply to:  4 ; Changed 3 years ago by rurseekatze

Cc: rurseekatze added

Replying to skyper:

Replying to rayquaza:

Here's something which depends on this: https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging

This is a completely new tagging scheme and not established, yet. There is no reason to not use cardinal directions or degrees here.

No. Using cardinal directions or deegrees for railway signals does not make any sense.

For mapping a railway signal, it is important to enter the direction of this signal (trains from which direction of the track have to give attention to the signal). There are the possible values forward, backward and both. This is easy to understand for mappers and easy to interpret for software such as routing applications.

If you think that there is no reason for this tagging: How would you enter the direction information with cardinal directions or degrees? And how would you interpret these values for e.g. routing purposes?

comment:6 in reply to:  5 ; Changed 3 years ago by skyper

Replying to rurseekatze:

Replying to skyper:

Replying to rayquaza:

Here's something which depends on this: https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging

This is a completely new tagging scheme and not established, yet. There is no reason to not use cardinal directions or degrees here.

No. Using cardinal directions or deegrees for railway signals does not make any sense.

For mapping a railway signal, it is important to enter the direction of this signal (trains from which direction of the track have to give attention to the signal). There are the possible values forward, backward and both. This is easy to understand for mappers and easy to interpret for software such as routing applications.

If you think that there is no reason for this tagging: How would you enter the direction information with cardinal directions or degrees? And how would you interpret these values for e.g. routing purposes?

I never said there is no reason but just that forward/backward/both on nodes does not make sense and that I do not know any editing software that checks these tags on child nodes when reverting ways.

I propose to use the approved key direction:

  • it is defined as the direction the object points/faces to

This way a signal for a way leading north would be tagged with direction=S

On major advantage of these values is that you do not depend on the direction of the way and reverting the way does not interfere.

Last edited 3 years ago by skyper (previous) (diff)

comment:7 in reply to:  6 Changed 3 years ago by rurseekatze

Replying to skyper:

Replying to rurseekatze:

Replying to skyper:

Replying to rayquaza:

Here's something which depends on this: https://wiki.openstreetmap.org/wiki/OpenRailwayMap/Tagging

This is a completely new tagging scheme and not established, yet. There is no reason to not use cardinal directions or degrees here.

No. Using cardinal directions or deegrees for railway signals does not make any sense.

For mapping a railway signal, it is important to enter the direction of this signal (trains from which direction of the track have to give attention to the signal). There are the possible values forward, backward and both. This is easy to understand for mappers and easy to interpret for software such as routing applications.

If you think that there is no reason for this tagging: How would you enter the direction information with cardinal directions or degrees? And how would you interpret these values for e.g. routing purposes?

I never said there is no reason but just that forward/backward/both on nodes does not make sense and that I do not know any editing software that checks these tags on child nodes when reverting ways.

The missing check of these tags is why somebody created this ticket...

I propose to use the approved key direction:

  • it is defined as the direction the object points/faces to

This way a signal for a way leading north would be tagged with direction=S

If you read this wiki page, then you will notice that direction=forward/backward is already mentioned for nodes on ways such as traffic signs. And retagging of already more than 14.000 nodes with railway:signal:direction=* is not possible.

On major advantage of these values is that you do not depend on the direction of the way and reverting the way does not interfere.

This is not the right place for discussions about advantages and disadvantages of tagging schemes. This ticket was created as a request for an improved data check, not for tag discussions. Any more tag discussion here is just a waste of time...

Will you or any other of the JOSM developers implement this feature?

comment:8 Changed 3 years ago by rurseekatze

comment:9 Changed 2 years ago by stoecker

Ticket #10727 has been marked as a duplicate of this ticket.

comment:10 Changed 2 years ago by simon04

Owner: changed from anonymous to team
Status: needinfonew

A specific example ("reversing way XYZ should show a warning") is still outstanding, but the context is clearer …

comment:11 Changed 19 months ago by Klumbumbus

Ticket #12537 has been marked as a duplicate of this ticket.

comment:12 Changed 19 months ago by naoliv

Cc: naoliv added

comment:13 Changed 12 months ago by Klumbumbus

Ticket #13711 has been marked as a duplicate of this ticket.

comment:14 Changed 12 months ago by Klumbumbus

Cc: merten@… added

Changed 12 months ago by Klumbumbus

Attachment: directionnodes.png added

comment:16 Changed 12 months ago by openstreetmap.org-user-d1g

I personally use traffic_signals:direction tag as described here: http://wiki.openstreetmap.org/wiki/Tag:highway%3Dtraffic_signals#Traffic_signals_for_cars

Value forward/backward of traffic_signals:direction should be flipped by JOSM, but we shouldn't support this for direction because this tag is messy (read wiki).

IMO similar thing should be done for traffic signs. traffic_sign=RU:3.28 + traffic_sign:direction=forward/backward or similar.

We should definitely use http://wiki.openstreetmap.org/wiki/Key:traffic_sign instead of highway=stop/highway=give_way. Later tags are only use because we developed software to support them, count me as for their re-tagging per each country (i.e. using real local codes).

direction tag should be left for 360 degree values: http://wiki.openstreetmap.org/wiki/Key:direction#Angles_and_cardinal_directions, other uses of this tag should be retagged to better scheme http://wiki.openstreetmap.org/wiki/Key:direction#Forward_and_backward

comment:17 Changed 12 months ago by openstreetmap.org-user-d1g

OR instead of automatic flipping we should ask user what to do:

  1. rotate road and switch tag
  2. drop outdated tag
  3. mark it as fixme=road was reversed without inspecting sign

comment:18 Changed 12 months ago by simon04

Resolution: fixed
Status: newclosed

In 11061/josm:

fix #10260 - Warning on reversing ways with direction-dependent nodes

comment:19 Changed 12 months ago by simon04

Milestone: 16.09

comment:20 Changed 12 months ago by Klumbumbus

Resolution: fixed
Status: closedreopened

I think that cardinal directions (e.g. NW) and numbers (e.g. 120) should not be changed since they are absolute values and not relative to the parent way.

comment:21 in reply to:  20 Changed 12 months ago by openstreetmap.org-user-d1g

Replying to Klumbumbus:

should not be changed since

I would keep code, but disable/enable it by default depending on users feedback

But we are not limited to have rotated objects only outside ways, so it might make sense but not so intuitive.

they are absolute values and not relative to the parent way.

In changeset/11061 we change them as absolute values. I haven't thought about it, not sure how many users would use this.

Last edited 12 months ago by openstreetmap.org-user-d1g (previous) (diff)

comment:22 Changed 12 months ago by simon04

Resolution: fixed
Status: reopenedclosed

In 11069/josm:

fix #10260 - Do not switch (absolute) cardinal directions / degrees

comment:23 Changed 12 months ago by simon04

Milestone: 16.0916.10

Milestone renamed

Modify Ticket

Change Properties
Set your email in Preferences
Action
as closed The owner will remain team.
as The resolution will be set.
The resolution will be deleted.

Add Comment


E-mail address and name can be saved in the Preferences.

 
Note: See TracTickets for help on using tickets.