Sorting of type=route, public_transport:version=2 relations

[Weide <osm@…>]

Sorting the elements of a relation with type=route and public_transport:version=2 should put all the stop and platform members in front without changing their relative sequence.
As an alternative, sorting could be refused if stops or platforms or non-ways are involved.

Reasons:

The relative sequence carries information in this kind of relation and could only be guessed by a rather complicated geometric comparison of the way and the stops. As long as this is not done, the risk of destroying a sequence which can only be restored with much work is too big to take.

The accepted Public Transport Proposal (now called PTv2) specifies that all halt information should come before all tour way information in the member list.

[skyper]

The strict order "stops in front of route ways" somehow contradicts the working flow, where you usually first have the route but are missing at least some stops. While I am certainly for keeping both apart in blocks I would not insist on the explicit order but rather use the same algorithm as for associatedStreet.

+1 for the rest. Sorting bus relations is often a nightmare even if it is much easier with public_transport:version=2 ones.

[bastiK]

Please add link to a relation with public_transport:version=2, where the sort feature destroys the stop/platform order.

[skyper]

Replying to bastiK:

Please add link to a relation with public_transport:version=2, where the sort feature destroys the stop/platform order.

platform and stop are each sorted in groups but they belong together 1:1 or 1:X. It is not that easy as platform do not need to have a name.

If some members are incomplete only already existing blocks should be sorted and not all completly downloaded members first. Alternatively do not sort at all as long as there are incomplete members but this wouldn't make me happy with huge relations and would produce unneeded traffic.

[Weide <osm@…>]

Replying to bastiK:

Please add link to a relation with public_transport:version=2, where the sort feature destroys the stop/platform order.

​osmwww:relation/168910

[simon04]

In 8229/josm:

see #10973 - Relation sorting: group platform and stop in front of other public_transport/route members

[stoecker]

Why not closed?

[simon04]

skyper:

The strict order "stops in front of route ways" somehow contradicts the working flow …

Currently the sorting puts platform and stop in front of the rest. Unless there's need to change this, we can close the ticket.

[aceman]

Replying to simon04:

skyper:

The strict order "stops in front of route ways" somehow contradicts the working flow …

Yes, sorting "platform, stop, route segment, platform, stop, segment, .... , platform, stop" is the natural order which would be created when the user goes along the route and adds the needed objects into the relation. On the other hand, JOSM then does not draw the route segments as joined together in the relation. So you can't check if you have the whole route contiguous, without any breaks.

This could be solved if JOSM would handle node members in determination where way segments are connected. And draw the lines in the right column of relation list appropriately.

[skyper]

Personally, I have all route segments in order (first to last) up front and at the bottom each stop(s) and its/their corresponding platform from first to last.

Similar to associatedStreet it makes no sense to move the platform and stop up front if they are all at the bottom. Not sure if we really need that rule.

Please, do not sort in groups but leave/sort the associated stops and platform together.

I would prefer all route segments and then stop+platform, stop+platform but can live with some other arrangement.

[simon04]

Detecting whether platform and stop are at the beginning or at the end would require a refactoring of the currently used AdditionalSorter – so I vote for the current behaviour :)

[skyper]

It is still grouping by roles and not by pairs of stop + platform. See ​osmwww:relation/1079463 for example.

[Weide]

Replying to skyper:

... See ​osmwww:relation/1079463 for example.

The example is not PTv2. PTv2 doesn't have stop:nn and neither PTv1 nor PTv2 have platform:nn. IN PTv2 the usage sequence of stops/platforms in reality is represented only by the sequence in the relation.

[Weide]

stop_exit_only, stop_entry_only, platform_exit_only and platform_entry_only are not sorted like stop and platform in JOSM 8254. (Test relation 32059)

[simon04]

In 8258/josm:

see #10973 - Relation sorting: group platform* and stop* in front of other public_transport/route members

[simon04]

Replying to skyper:

It is still grouping by roles and not by pairs of stop + platform.

#10972 is related to this part.

[simon04]

Let's keep track of that in #11373.

The original enhancement of this ticket has been implemented. :)

[simon04]

In 8259/josm:

see #10973 - Relation sorting: group platform* and stop* in front of other public_transport/route members (2/2)

[Weide]

The original enhancement of this ticket has been implemented.

This is the original:

Sorting the elements of a relation with type=route and public_transport:version=2 should put all the stop and platform members in front without changing their relative sequence.

But the relative sequence is changed as described in comment 16.

In PTv2 "stop and platform members" are: stop, stop_entry_only, stop_exit_only, platform, platform_entry_only and platform_exit_only.

[simon04]

Please take r8259 into account.

[simon04]

In 8517/josm:

see #10973 - Relation public_transport/route sorting: sort platform directly after corresponding stop member

[Weide]

Replying to simon04:

Does that mean that "platform A followed by stop A" is changed to "stop A followed by platform A"? That would be bad as both are possible mappings and they have an entirely different meaning. Only the mapper can tell, which of the meanings is right.

[aceman]

What is the difference in meaning? We use the order of "stop A, platform A" throughout the country so I'm curious to know the documentation of the difference.

[Weide]

Replying to aceman:

What is the difference in meaning? We use the order of "stop A, platform A" throughout the country so I'm curious to know the documentation of the difference.

Everyone should use this order if both parts are mapped. It's specified in PTP.

But it's not mandatory to map both stop and platform. (It's only mandatory to put both of them into the route, if they are mapped.)

As a bus sometimes stops twice at one station, it is possible for the first one to be mapped only as a platform and the second one to be mapped only as a stop. Then we have the sequence "platform A" followed by "stop A" and it means that the bus stops twice. Changing the sequence would mean, that the bus stops only once.

Example: Route 168910 (my next bus). It stops twice three times, but the problem above is avoided. But deleting the first stop and the last platform at "Fritz-Gressard-Platz" would show the problem.

[simon04]

Replying to Weide:

Does that mean that "platform A followed by stop A" is changed to "stop A followed by platform A"?

Yes. I don't see the semantic difference, neither. Relation member sorting might always "destroy" the order in the mapper's eyes and is to be used with care.

[aceman]

Replying to Weide:

As a bus sometimes stops twice at one station, it is possible for the first one to be mapped only as a platform and the second one to be mapped only as a stop. Then we have the sequence "platform A" followed by "stop A" and it means that the bus stops twice. Changing the sequence would mean, that the bus stops only once.

How did you come to this semantics? Where is that documented?
I would map that simply as stop A, platform A, stop B, platform B, stop C, platform C, stop A, platform A, stop D, platform D without ever thinking about any ugly anomalies.

[simon04]

In r8517, we test if platform X occurs more than once. In that case, stop and platform members are not sorted. So some complex relations are ignored.

Besides that, sorting hasn't been helpful for complex relations (such as with duplicate members) before. But I see a gain for a "standard" route relation.

[Weide]

Replying to aceman:

How did you come to this semantics? Where is that documented?

The PTP requires the two possible parts of a stopping operation of the vehicle to have the sequence stop-platform. If the sequence is different, then it is the normal sequence of vehicle stops.

I would map that simply as stop A, platform A, stop B, platform B, stop C, platform C, stop A, platform A, stop D, platform D without ever thinking about any ugly anomalies.

Then no one will have problems using sort on Your data. But what about legal other data?

[Weide]

Replying to simon04:

In r8517, we test if platform X occurs more than once. In that case, stop and platform members are not sorted. So some complex relations are ignored.

Well, the sequence "platform X-stop X" means that "platform X occurs more than once". :-)

Besides that, sorting hasn't been helpful for complex relations (such as with duplicate members) before. But I see a gain for a "standard" route relation.

Yes, it surely will be better than before.

But I wouldn't like to tell mappers "You can use sort for the stations ... except if you have the following complex situation: ...". I prefer to tell them "Just use sort to collect the stations. And afterwards have a look at the stations with double data: they should have the stops first."

The worst errors are those occurring so seldom, that we forget about them.

[aceman]

Replying to Weide:

Replying to simon04:

In r8517, we test if platform X occurs more than once. In that case, stop and platform members are not sorted. So some complex relations are ignored.

Well, the sequence "platform X-stop X" means that "platform X occurs more than once". :-)

What if the bus passes the same stop 3 times? You can't model that with just 2 objects.

Please tell us the link where this is documented. I couldn't find it yet.

[Weide]

Replying to aceman:

Please tell us the link where this is documented. I couldn't find it yet.

I cant. Only if we assume PTP to be useful, we can conclude it. PTP has only a "writing rule":

Each stop is included with two elements (if available): first the stop_position tagged with 
role stop and immediately followed by the corresponding platform tagged with role platform.

A corresponding "reading rule" is not given. But the "writing rule" given above would be useless, if we don't assume:
"Every such stop-platform pair found in a route is meant as a pair"

(It's really awful, and the renderers problems are even worse than the editors problems. :-( )

What if the bus passes the same stop 3 times? You can't model that with just 2 objects.

Well, You can interpret every stop-platform-pair as one stopping operation of the vehicle and everything else as a separate item. BTW: Another problem occurs much more frequently and cannot be solved in PTP: Having a multi-part-platform (a part on a bridge, a part in a tunnel, a part having a different height, a double sided exit, ...)

[aceman]

Replying to Weide:

Replying to aceman:

Please tell us the link where this is documented. I couldn't find it yet.

I cant. Only if we assume PTP to be useful, we can conclude it. PTP has only a "writing rule":

Each stop is included with two elements (if available): first the stop_position tagged with 
role stop and immediately followed by the corresponding platform tagged with role platform.

A corresponding "reading rule" is not given. But the "writing rule" given above would be useless, if we don't assume:
"Every such stop-platform pair found in a route is meant as a pair"

Ah, so you are reading something that is not there yet.
So I still do not understand how all these quotes say anything about a platform-stop pair.

If you think the proposal/accepted wiki page is inadequate for some situations, you should propose an update. But until then, JOSM can't be tied due to yet undocumented wishes.
And I honestly do not see why a platform-stop pair (or not pair) should have any special meaning. Your use case can be solved easily with existing proposal, as in comment 28.

[anonymous]

Replying to aceman:

And I honestly do not see why a platform-stop pair (or not pair) should have any special meaning.

I am the one, who does not want a platform-stop-pair being treated as something special. I want them to be treated like any other two items. If you want to change their sequence you are assuming, that a platform-stop-pair has the very special meaning: "The mapper wanted a stop-platform-pair but didn't know that PTP requires the stop to come first"

If you think the proposal/accepted wiki page is inadequate for some situations, you should propose an update.

​http://gafte.de/