Modify

Opened 4 years ago

Closed 8 months ago

Last modified 8 months ago

#11054 closed enhancement (wontfix)

Tag and relation transit will be broken when splitting a way

Reported by: imagic Owned by: team
Priority: normal Milestone:
Component: Core Version: tested
Keywords: Cc:

Description

If the tag transit is used on a way and the way is splitted, the tag will be added to both parts of the way, which breaks the tag.

Correct behaviour for the tag would be:

  • transit[:lanes] -> tag will be added to the "forward" part of the splitted way and removed from the "backward" part of the splitted way
  • transit[:lanes]:forward -> identical to transit[:lanes]
  • transit[:lanes]:backward -> tag will be added to the "backward" part of the splitted way and removed from the "forward" part of the splitted way

A relation type=transit has exactly two ways as members: "from" and "to". Those two ways must share a common node at one end. If any of those two ways is split, those part of the splitted way must remain member of the relation that still contains that common node. In case the two ways do not share a common node or more than one node, the relation is already invalid and both parts of the splitted way should remain members of the relation (with the same role) and preferable a warning should be displayed, e.g. "A transit relation may only contain exactly two adjacent ways. Please verify and update if possible."

I attach a test file to the ticket with correctly tagged ways/relations before and after a split.

Attachments (1)

Splitting of transit.osm (7.6 KB) - added by imagic 4 years ago.
Test file with correct tagging before and after a split

Download all attachments as: .zip

Change History (14)

Changed 4 years ago by imagic

Attachment: Splitting of transit.osm added

Test file with correct tagging before and after a split

comment:1 Changed 4 years ago by skyper

Think this is a problem of design with the transit=* on ways as the tag does not carry information belonging to the way and it will need extra handling by all editor software.

No problem with relations, though, as they seem to follow the turn-restriction syntax.

Saying that, I know we are in a pitty, as we do not want to recomand an addition relation for every lane change but I am sorry, there is no alternative solution in my mind, so far.

comment:2 Changed 4 years ago by imagic

It's a feature, not a bug! ;-) Please read the section Rationale of the proposal: https://wiki.openstreetmap.org/wiki/Proposed_features/transit

The tag carries the exact same information as the relation, but makes it a little bit easier for the mapper. This topic is already very complex, so we should make it as easy as possible for the mapper. (In case you want to know how this topic can be solved by making it really hard for the mappers, please read the previous proposal which is linked from within the section "See also")

Yes, it will need extra handling by all editors, but it should be quite easy to implement, and errors created by incorrectly splitted ways are usually easy to detect.

comment:3 Changed 4 years ago by hurdygurdyman

Just an idea :-/
Check splitted ways with transit:*=key before storing data:
Two connected ways shouldn't have identical transit:*-key/value for the same direction, if it's not a junction there with
three connected ways or more (maybe except all lanes have "continue").
This check should produce a warning before upload like
"Two connected ways have identical transit:lanes. That's usually a fault because no change exists towards the next way. Please check!"
This would prevent most of possible mistakes.

comment:4 in reply to:  3 Changed 4 years ago by imagic

Replying to hurdygurdyman:

Two connected ways shouldn't have identical transit:*-key/value for the same direction, if it's not a junction there with
three connected ways or more (maybe except all lanes have "continue").

This would be a nice, but difficult to determine error check. The implementation of the splitting-behaviour should be quite easy (transit:backward -> only backward way; others -> only forward way). As soon as we have support for the splitting we can specify some conditions, that should trigger warnings/errors. Lets give the devs a little time ;-)

comment:5 Changed 4 years ago by skyper

I am still not convinced about transit=* and placement:end=* on ways.

@imagic:
Would you please announce your proposal at tagging@ to get a wider audience and we can discuss it there.

comment:6 Changed 4 years ago by imagic

Sorry for the late response, I missed your last comment.

In my opinion this is not ready for @tagging. At the moment we are trying to get mappers from different countries to read the proposal and provide feedback. As this topic is very complex, we continuously find a lot of misunderstandings and errors in phrasing and have to fix them. Hopefully in the next two to three weeks, we will start to use the scheme and see where it breaks and where it doesn't. This testing phase will be used to identify situations where usage is problematic or not possible at all and find decent solutions. If other mappers will break the relations and tags by simply splitting ways, testing will be a lot more difficult.

I have to admit that I do not really see a problem. The tags do not interfere with any other tags and there will be no preset or template recommending them (contrary to some other tags in the past ;-) ).

And regarding :end (and :start): these are already in use by the hungarian community, so they are not really a new invention. And they haven't been mentioned at all in this ticket, they are a completely different story.

comment:7 in reply to:  6 Changed 4 years ago by skyper

Replying to imagic:

In my opinion this is not ready for @tagging.

Then I would think it is not ready for JOSM either but if someone does the work....

At the moment we are trying to get mappers from different countries to read the proposal and provide feedback. As this topic is very complex, we continuously find a lot of misunderstandings and errors in phrasing and have to fix them. Hopefully in the next two to three weeks, we will start to use the scheme and see where it breaks and where it doesn't. This testing phase will be used to identify situations where usage is problematic or not possible at all and find decent solutions. If other mappers will break the relations and tags by simply splitting ways, testing will be a lot more difficult.

As already mention, I have no problem with the relation as it covers the node and is more or less the same as restriction-relations but the
tags on ways are a problem.
I would rather prefer some additions to placement and I also do not get why it does/should not work on some situations like direction-separated ways merging to one.

Guess I have to open the discussion on tagging@ then.

I have to admit that I do not really see a problem. The tags do not interfere with any other tags and there will be no preset or template recommending them (contrary to some other tags in the past ;-) ).

If you need extra support from each editor software, you will need good arguments.

And regarding :end (and :start): these are already in use by the hungarian community, so they are not really a new invention. And they haven't been mentioned at all in this ticket, they are a completely different story.

These tags have the same problem and would need the same treatment, though.

comment:8 Changed 11 months ago by anonymous

I wrote down simple condensed rules about what editors would need to do to prevent destroying these relations and tags:

https://pastebin.com/BGWvp6QU

There hasn't been any movement on the proposal for a few years, but given that these are the only documented tags for this purpose, they have become pretty much defacto in usage. And it would be nice if editors wouldn't so easily destroy them.

The rules are actually pretty straight forward and simple to follow.

comment:9 in reply to:  8 Changed 10 months ago by anonymous

Replying to anonymous:

they have become pretty much defacto in usage.

I just checked taginfo and there are 179 occurrences of the transit tag on ways and 146 transit relations; it might be a little premature to be calling this "defacto".

Perhaps if the proposal is "pretty straight forward and simple to follow" then it might be time to move to the RFC stage and then we can vote on it? Then we can start to worry about "fixing" JOSM.

comment:10 Changed 8 months ago by mkoniecz

See https://lists.openstreetmap.org/pipermail/tagging/2018-June/037082.html for tagging mailing list discussion started by an iD dev ("I can't support transit:lanes")

comment:11 Changed 8 months ago by mkoniecz

In https://lists.openstreetmap.org/pipermail/tagging/2018-June/037105.html this tagging scheme was described as horrible by a Vespucci developer

JOSM remains the only major editor that has not definitely refused to support that tag

comment:12 in reply to:  11 Changed 8 months ago by stoecker

Resolution: wontfix
Status: newclosed

Hello,

JOSM remains the only major editor that has not definitely refused to support that tag

Ignoring a topic for years is nearly a refusal...

To make you happy: I usually refuse to support totally new tagging concepts when a simpler method is to use an existing concept. As in this case here the simpler concept is to use the semantics of turn-relations this is a WONTFIX.

Adding tags to ways which are relative to other ways is concept which will always break, as JOSM does never operate on a full dataset and thus in many cases simply does not know the adjacent ways. That's why we have relations - to define rules how multiple objects are to be handled together. If a relation is too complex for a certain purpose, then maybe that purpose is not worth the effort at all?

comment:13 Changed 8 months ago by mkoniecz

To make you happy

Thanks!

Ignoring a topic for years is nearly a refusal...

For me there is an important difference between "WONTFIX" and "if somebody provides decent patch implementing this it may be accepted, but maintainers are doing more useful/important things".

Also, while describing situation on wiki I wanted to avoid misunderstandings and misinterpretation.

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.