Tag and relation transit will be broken when splitting a way

[imagic]

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.

[imagic]

Test file with correct tagging before and after a split

[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.

[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.

[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.

[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 ;-)

[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.

[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.

[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.

[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.

[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.

[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")

[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

[stoecker]

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?

[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.