Modify

Opened 12 years ago

Last modified 5 years ago

#8460 new enhancement

Validator checks for Public Traffic Proposal relations

Reported by: Weide Owned by: team
Priority: normal Milestone:
Component: Core validator Version:
Keywords: public_transport role check Cc: skyper, simon04, darya

Description (last modified by Klumbumbus)

1.

If a type=route relation is a member of a type=route_master relation, it should be viewed as a route according to the accepted Public Traffic Proposal
osmwiki:Proposed_features/Public_Transport and the error messages should include the following items.

(Citations from the proposal are marked with "PTP" here.)

(Recognizing a PT route relation is not easy. The existence of a route_master as said above is a sure way as route_masters were never proposed elsewhere. But the Public Traffic Proposal does allow omitting the route_master relation... But it's impossible to give error messages if there is no way to find out if something is wrong or just not made according the Proposal)

==> see #comment:41


2.

The only roles are "stop", "platform", "stop_exit_only", "stop_entry_only", "platform_exit_only", "platform_entry_only" and "".

PTP: "Each direction/variant relation contains all available «stop_positions», «platforms» and ways."

PTP: "If a stop is only for exiting or entering the vehicle (common for nightly services) the roles stop and platform should be replaced with stop_exit_only or stop_entry_only and platform_exit_only or platform_entry_only."

PTP: "After all the stops all the used ways should be inserted into the relation with an empty role."


3.

All "" entries (tour ways) refer to OSM Ways and follow as a block at the end of the relations member list.

PTP: "After all the stops all the used ways should be inserted into the relation with an empty role."


4.

If exactly two entries with the same name or belonging to the same stop_area follow each other, the entry with the role "stop" should be before the entry "platform". This should not be an error but a warning, as both may refer to two different stops of the vehicle.

PTP: "first the stop_position tagged with role stop and immediately followed by the corresponding platform tagged with role platform."


5.

The tag route does not have a value light_rail. All trains should be marked with train. The same holds for route=light_train. (The railway infrastructure may be different.)

PTP: "train / subway / monorail / tram / bus / trolleybus / aerialway / ferry"

==> invalid see #comment:34 and #comment:39


6.

The name of a route should have the form PTP: "<vehicle type> <reference number>: <initial stop> => <terminal stop>"
and the route_master name should have the form PTP: "<Vehicle type> <Reference number>"

This should be warnings only as the mappers need some more flexibility:

  1. there are vehicles (many ferries) which do not have a reference number
  2. there are Public Traffic Routes, which have several vehicle types (Swedish bus lines are often served by buses and taxis depending on the

expected customer count)

  1. Tagging different variants with the same name is not acceptable. Most mappers use additional substrings "=> xx =>" to solve the problem. They should not get an error message for that.

7.

A node with the role platform may not have any infrastructure in the Public Traffic Proposal. So shelter=yes, tactile_paving=yes or bench=yes should lead to an error message (shelter=yes only a warning as it is also used to indicate a shelter belonging to a shop at the stop)

PTP: "A public_transport=platform is used to tag a Way or Area where the passengers can wait for the vehicles. If there is no platform in the real world, one can place a Node at the pole."

The message could propose using the old style highway/railway=platform for these nodes.

==> invalid see #comment:37


8.

There is no public_transport=stop_area_group

==> we already have a warning "unknown relation type", see also comment:48

Attachments (0)

Change History (49)

comment:1 by Don-vip, 12 years ago

See also #8266 and #8422

comment:2 by skyper, 12 years ago

Cc: skyper added

comment:3 by skyper, 11 years ago

Keywords: public_transport role check added

comment:4 by Don-vip, 11 years ago

Milestone: 14.02

comment:5 by Don-vip, 11 years ago

Cc: simon04 added
Milestone: 14.0214.03

comment:6 by Don-vip, 11 years ago

Milestone: 14.03

comment:7 by simon04, 9 years ago

Description: modified (diff)
Milestone: 16.03

(Numbers for later reference added)

comment:8 by simon04, 9 years ago

In 9931/josm:

see #8460 - Improve public transport route member validation by splitting preset into bus and rail

Drop rarely used relations route=ferry, route=aerialway.

comment:9 by simon04, 9 years ago

In 9932/josm:

see #8460 - fix typo from r9931, fix matching, improve conditions, add unit test

comment:10 by simon04, 9 years ago

In 9933/josm:

see #8460 - Validate that public transport routes (version 2) do not contain a gap

comment:11 by simon04, 9 years ago

In 9937/josm:

see #8460 - Allow roundabouts in gap test

comment:12 by simon04, 9 years ago

In 9938/josm:

see #8460 - Update unit tests for r9931

comment:13 by aceman, 9 years ago

Why is shelter=yes warned about on a platform? It is clearly allowed at http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform .

comment:14 by AgusQui, 9 years ago

In the latest versions you are asking me to add bus=yes to platform, but in the wiki does not say that it should be so.

in reply to:  14 comment:15 by Klumbumbus, 9 years ago

Replying to AgusQui:

In the latest versions you are asking me to add bus=yes to platform, but in the wiki does not say that it should be so.

This was already fixed, see #12665

in reply to:  13 ; comment:16 by Klumbumbus, 9 years ago

Replying to aceman:

Why is shelter=yes warned about on a platform? It is clearly allowed at http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform .

I can't reproduce, please open a new ticket for this with josm-latest (which has enhanced bug report system).

comment:17 by Don-vip, 9 years ago

Milestone: 16.0316.04

Milestone renamed

in reply to:  16 comment:18 by aceman, 9 years ago

Replying to Klumbumbus:

Replying to aceman:

Why is shelter=yes warned about on a platform? It is clearly allowed at http://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dplatform .

I can't reproduce, please open a new ticket for this with josm-latest (which has enhanced bug report system).

I haven't seen it since, hopefully it was fixed by other changes.

comment:19 by bastiK, 9 years ago

Milestone: 16.0416.05

comment:20 by Don-vip, 9 years ago

Milestone: 16.0516.06

comment:21 by Klumbumbus, 9 years ago

Thers is now also the gsoc project, which maybe includes some of the proposed tests?
http://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2016/AcceptedProjects/PT_Assistant

comment:22 by Klumbumbus, 9 years ago

Cc: darya added

comment:23 by darya, 9 years ago

The new GSoC proposal (work in progress) includes some of this, but its emphasis is less on tag testing and more on checking the integrity of the route (e.g. whether all stops are served, whether the ways are in the right order, or how to close the gap in the route) with some user interaction.

comment:24 by Klumbumbus, 9 years ago

OK, please let us know here if/when you implemented one of the suggestions from this ticket, so it doesn't need to be done again.

comment:25 by darya, 9 years ago

Ok, I will let you know when that is the case, and when the PT_Assistant plugin is more progressed. Thank you for letting me know of this ticket.

comment:26 by aceman, 9 years ago

Yes, thanks for that plugin. I am using it and it has already found some errors ;)
Especially the gaps feature is nice. Please keep it detecting unordered ways in the raw relation (even those that would make a contiguous route IF sorted automatically). As e.g. JOSM seems to automatically sort relation members internally when deciding if boundaries are unclosed and such.

in reply to:  26 comment:27 by darya, 9 years ago

Replying to aceman:
Thanks for your feedback!

comment:28 by Don-vip, 9 years ago

Milestone: 16.0616.07

comment:29 by Don-vip, 8 years ago

Milestone: 16.0716.08

comment:30 by Don-vip, 8 years ago

Milestone: 16.0816.09

comment:31 by Don-vip, 8 years ago

Milestone: 16.0916.10

comment:32 by simon04, 8 years ago

Milestone: 16.1016.11

Milestone renamed

in reply to:  description comment:33 by simon04, 8 years ago

@darya, can you please comment on which checks from the ticket description are included in the pt_assistant plugin, i.e., what is left to be done?

comment:34 by darya, 8 years ago

I will use the terms "PTStops" and "PTWays" to refer to the members of a route relation independently of their OsmPrimitiveType (e.g. a PTStop can be a Node or a Way, and a PTWay can be a Way or a Relation)

General note: pt_assistant only generates warnings, not errors.

"yes"="pt_assistant does check"; "no"="pt_assistant does not check"

#1 no (whether a relation should be validated by pt_assistant is determined based on tags, not on the route_master membership)
#2 yes (but the roles are not strictly enforced for PTWays)
#3 yes (but the roles are not strictly enforced for PTWays)
#4 pt_assistant allows Relations to be PTWays as well.
#5 no (light_rail is allowed, I thought light_rail is more like subway than like train)
#6 no
#7 no (pt_assistant allows anything to map a stop: a platform only, a stop_position only, or a platform + a stop_position)
#8 no

comment:35 by Klumbumbus, 8 years ago

Description: modified (diff)

There is no public_transport=stop_area_group

It is documented in the wiki at https://wiki.openstreetmap.org/wiki/Relation:public_transport Situation must be discussed and clarified first before adding a specific JOSM warning.

comment:36 by Klumbumbus, 8 years ago

Description: modified (diff)

comment:37 by Klumbumbus, 8 years ago

Description: modified (diff)

#7 is invalid
There is no reason to forbid shelter=yes, tactile_paving=yes or bench=yes on platforms mapped as node. You can map a platform as node, linear way or as area. But this has no effect on the additional tags.

comment:38 by Klumbumbus, 8 years ago

Description: modified (diff)

comment:39 by Klumbumbus, 8 years ago

Description: modified (diff)

#5 is invalid

route=light_rail is OK. route=light_train is not in use

comment:40 by Klumbumbus, 8 years ago

Description: modified (diff)

comment:41 by Klumbumbus, 8 years ago

Description: modified (diff)

#1

intention of this point is unclear to me. Whats ment with "should be viewed as a route"?

comment:42 by Don-vip, 8 years ago

Milestone: 16.1116.12

Milestone renamed

comment:43 by Don-vip, 8 years ago

Milestone: 16.1217.01

comment:44 by Don-vip, 8 years ago

Milestone: 17.0117.02

comment:45 by Don-vip, 8 years ago

Milestone: 17.0217.03

comment:46 by Don-vip, 8 years ago

Milestone: 17.03

in reply to:  35 ; comment:47 by anonymous, 5 years ago

Replying to Klumbumbus:

There is no public_transport=stop_area_group

It is documented in the wiki at https://wiki.openstreetmap.org/wiki/Relation:public_transport Situation must be discussed and clarified first before adding a specific JOSM warning.

JOSM still warns about the stop_area_group tag
https://wiki.openstreetmap.org/wiki/Relation:public_transport#public_transport.3Dstop_area_group

Is it possible to fix?

in reply to:  47 comment:48 by Klumbumbus, 5 years ago

Replying to anonym:

Replying to Klumbumbus:

There is no public_transport=stop_area_group

It is documented in the wiki at https://wiki.openstreetmap.org/wiki/Relation:public_transport Situation must be discussed and clarified first before adding a specific JOSM warning.

JOSM still warns about the stop_area_group tag
https://wiki.openstreetmap.org/wiki/Relation:public_transport#public_transport.3Dstop_area_group

Which is fine as the definition of stop_area_group relations is unclear. I added a warning to the wiki page.

comment:49 by Klumbumbus, 5 years ago

Description: modified (diff)

Modify Ticket

Change Properties
Set your email in Preferences
Action
as new The owner will remain team.
as The resolution will be set. Next status will be 'closed'.
to The owner will be changed from team to the specified user.
Next status will be 'needinfo'. The owner will be changed from team to Weide.
as duplicate The resolution will be set to duplicate. Next status will be 'closed'. The specified ticket will be cross-referenced with this ticket.
The owner will be changed from team to anonymous. Next status will be 'assigned'.

Add Comment


E-mail address and name can be saved in the Preferences .
 
Note: See TracTickets for help on using tickets.