He said that they decided to use PTv2 but w/o public_transport=* at stops/platforms and to use only hw=bus_stop next to the street (not as node on the street) and to have ways sorted before stops in the member ist.

So not really same as proposed by Zverik in his proposal - called by some people PTv3 (not by himself though).

Excluding the swapped sequence of ways and stops, I’d call the Swedish version a PTv2 with backward compatibility with well known tags (making use of hw=bus_stop)

I saw this for a single route relation only, maybe that was an exception to: stops before ways

Was that right reading somewhere in that proposal to only map the bus stops? That would be up into several people’s argument of letting navigators decide how to drive from stop 99 to stop 100 as these route relations of thousands of members seriously interfere with rendering and refreshing. Flixbus routes to name one who’s got hundreds if not thousands across Europe, and every time one does something to the tiniest street section with a Flixbus role attached and something anywhere start to finish is off, you get tagged with 99 out of 100 there being a gap somewhere in the 2000 mile route somewhere between Hannover and Brindisi.

No, PTv2 says: ways are “mandatory”, stop_positions and platforms are “recommended if available”:
2nd table in this section

So, PTv2 does for instance not cover the new “FLEX” system here, where there are 100 Stops or so. You call a mini bus which picks you up at one stop and takes you to your destination stop using the shortest path (except if others want to partly join the ride and get on or drop off in between) - the path is dynamically calculated, depending on demand - there is no fixed way. It has become very popular here and the test phase and area will definitely be extended.

Absolutely true: new gaps (caused by iD, StreetComplete, JOSM, … users and SW) pop up every day @PTNA

Not having ways in route relations will cause “no rendering on maps except the stops”. Renderers which want to show the route on a map would have to start a routing engine and the calculated route could be different from the one used in reality. On the other hand: the bus driver should know the route and the passengers do not have to care about the route (except for sight seeing and safety, …).

What would be a PT map w/o the route being shown? Equivalent to Carto?

Please, do not mix JOSM core and plugins. Yes, pt_assistant is for PTv2 but plain JOSM supports both.

You need a check-and-notify program to monitor for gaps.

At least in my area, it is not possible to calculate all routes between stops so far. We just do not have enough information to know which roads are suited for buses and in addition are allowed (not by access rules but as local agreement to e.g. lower traffic noise in residential areas).
Looking at the shapes (gpx traces) in GTFS of which some are created with OSM data, the shapes are often wrong, especially if we talk about bus lines on the country side.

If only there was, now I’m just jumping to attention when Osmose sends me the pin list with the harvest of last week, their cycle is somewhere in the 8-16 day range.

edit: " 8-16 day range"

If only that were transparent to me, I loaded the PT plugin right from the start of using JOSM some 7-8 months ago and never looked which does what.

You might want to take a look at PTNA - Results.

I see. Documentation of the plugin is quite poor, I have to admit, but the JOSM core documentation is usually up-to-date (at least for English, Dutch and French). The F1 key is a good friend. Though it is still a wiki and we happily appreciate help.

Maybe, you can spot some of the additional option from the plugin by disabling/enabling it.

EDIT: Better link target.

This applies to all long distance routes like E-Roads, Europeen cycling and hiking routes, …
One tool to work with are superroute relations to split these long routes in parts.

I don’t know one for PT routes. I do know Knooppuntnet Monitor for hiking routes.
It’s still an experimental tool, but it is functional enough.

A developer might fork this for PT routes, or you might file an issue to get support for PT-routes.

Notification is not (yet?) built into the tool. It compares the current OSM route to a reference route. The reference can be a “frozen” OSM route. It will show interruptions in the route, and it lists route differences > 10m. There is a link to load the route or a particular difference into JOSM for editing.

PTNA can be configured to perform a daily analysis for your area of interest. Not only gaps will be found, riding against oneway direction, being blocked by wrong access restrictions, missing tags, … will be reported. A diff report is available showing what has changed in the last 24 hours - for the good, for the bad.

The check-program is already there.
OSM Inspector | Geofabrik Tools

I do the check every day for the Netherlands and also fix the flixbuses wich are partly in the Netherlands.


Dat is nou één van de weinige validatiewaarschuwingen die je gewoon kunt negeren.
Net als een verdachte richting op een rotonde.

1 Like

Veronderstel dat die PTv2 waarschuwing negeren op Nederland slaat?

OT, [quote=“Leo_Slager, post:30, topic:97588”]
Net als een verdachte richting op een rotonde.

Meer dan eens deze ‘suspicious…’ waarschuwing in JOSM tijdens validatie tegengekomen. Ga dan toch maar kijken omdat ik een geval ben tegengekomen waar de rode tekenrichting pijl de ene kant op stond en de kleine zwarte 1 richting triangels de andere kant. Zou met rotondes niet moeten zijn. OSM, weet zonder 1-way tag, welke kant het op gaat in de gegeven locatie.

There is an GTFS aggregate feed for the Netherlands at

Thanks for pointing to that …

Are the open licenses of the transit-agencies compatible with OSM?