Modify

Opened 4 years ago

Closed 4 years ago

Last modified 4 years ago

#10973 closed enhancement (fixed)

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

Reported by: Weide <osm@…> Owned by: team
Priority: normal Milestone: 15.04
Component: Core Version:
Keywords: Cc:

Description

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.

Attachments (0)

Change History (35)

comment:1 Changed 4 years ago by Don-vip

Component: unspecifiedCore

comment:2 Changed 4 years ago by 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.

comment:3 Changed 4 years ago by bastiK

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

comment:4 in reply to:  3 Changed 4 years ago by 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.

comment:5 in reply to:  3 Changed 4 years ago by 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

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

comment:6 Changed 4 years ago by simon04

In 8229/josm:

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

comment:7 Changed 4 years ago by simon04

Milestone: 15.04

comment:8 Changed 4 years ago by stoecker

Why not closed?

comment:9 in reply to:  2 ; Changed 4 years ago by 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.

comment:10 in reply to:  9 Changed 4 years ago by 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.

comment:11 Changed 4 years ago by 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.

comment:12 Changed 4 years ago by 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 :)

comment:13 Changed 4 years ago by simon04

Resolution: fixed
Status: newclosed

comment:14 Changed 4 years ago by skyper

Resolution: fixed
Status: closedreopened

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

comment:15 in reply to:  14 Changed 4 years ago by 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.

comment:16 Changed 4 years ago by 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)

comment:17 Changed 4 years ago by simon04

In 8258/josm:

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

comment:18 in reply to:  14 Changed 4 years ago by simon04

Replying to skyper:

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

#10972 is related to this part.

comment:19 Changed 4 years ago by simon04

Resolution: fixed
Status: reopenedclosed

Let's keep track of that in #11373.

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

comment:20 Changed 4 years ago by simon04

In 8259/josm:

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

comment:21 in reply to:  description Changed 4 years ago by 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.

comment:22 Changed 4 years ago by simon04

Please take r8259 into account.

comment:23 Changed 4 years ago by simon04

In 8517/josm:

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

comment:24 in reply to:  23 ; Changed 4 years ago by 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.

comment:25 Changed 4 years ago by 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.

comment:26 in reply to:  25 ; Changed 4 years ago by 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.

comment:27 in reply to:  24 Changed 4 years ago by 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.

comment:28 in reply to:  26 ; Changed 4 years ago by 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.

comment:29 Changed 4 years ago by 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.

comment:30 in reply to:  28 Changed 4 years ago by 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?

comment:31 in reply to:  29 ; Changed 4 years ago by 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.

comment:32 in reply to:  31 ; Changed 4 years ago by 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.

comment:33 in reply to:  32 ; Changed 4 years ago by 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, ...)

comment:34 in reply to:  33 ; Changed 4 years ago by 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.

comment:35 in reply to:  34 Changed 4 years ago by 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/

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.