Validator checks for Public Traffic Proposal relations

[Weide]

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)

---

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"

---

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)

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

==> see #comment:36

---

8.

There is no public_transport=stop_area_group see #comment:35

[Don-vip]

See also #8266 and #8422

[simon04]

(Numbers for later reference added)

[simon04]

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.

[simon04]

In 9932/josm:

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

[simon04]

In 9933/josm:

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

[simon04]

In 9937/josm:

see #8460 - Allow roundabouts in gap test

[simon04]

In 9938/josm:

see #8460 - Update unit tests for r9931

[aceman]

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

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

[Klumbumbus]

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

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

[Don-vip]

Milestone renamed

[aceman]

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.

[Klumbumbus]

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

[darya]

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.

[Klumbumbus]

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.

[darya]

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.

[aceman]

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.

[darya]

Replying to aceman:
Thanks for your feedback!

[simon04]

Milestone renamed

[simon04]

@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?

[darya]

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

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

[Klumbumbus]

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