automatic grouping of objects (stop positions, poles, platforms) to stops based on distances and tags,
different coloring schemes for stop properties
comments and warnings on tagging quality for each stop
The main pupose is to find tagging mistakes and inconsitencies in OSM data.
The project is freely accessible and the code is on GitHub. Also have a look at PTSA’s help page to better understand what you see and what to do with the information provided.
Feedback here in the forum or in the project’s GitHub issues. I’m especially interested in stops you think PTSA does not show correctly although tagging seems to be okay. Thank you!
Finally, some screenshots for those who do not want to click the link
Very nice tool! I’ll admit I was a bit confused by the coloring at first. I didn’t notice that you have to click the circles on the side, since the boxes were all checked. Maybe you can uncheck/gray out the boxes for unselected coloring options? But this is a minor quibble
Some feedback you were interested in: I think this stop is tagged correctly: Node: LAX/Metro Transit Center (10088767531) | OpenStreetMap. It’s an under-construction light rail stop tagged construction:public_transport=station + construction:railway=station + station=light_rail + light_rail=yes (ignore the opening date, it’s been delayed past this year). The tool flags it as ‘dubious’ with the warning “node somehow related to public transport, but how?”. Maybe explicit handling for construction:* prefixes would be useful? Or maybe this object is incorrectly tagged.
I had a quick look in my local area and it looks good, it only highlighted a small number of stops, but they were genuine mistakes that I was able to fix (e.g. a few stops tagged as subway whereas the rest of the network is tagged as light_rail).
Yes I found this too. I think the fact that the group that is “switched on” initially is not the top group also makes this harder to figure out. It’s also not obvious at first that “dubious objects” needs to be switched on separately - this turned out to be one of the most useful checks.
Even more minor: “pole” is spelled “plole” in a few places!
Maybe you can uncheck/gray out the boxes for unselected coloring options?
That’s a really good idea. Working on such projects over time you become blind for such obvious improvements. Opened an issue about this. So I don’t forget this next time I work on the code.
I think this stop is tagged correctly
I think you are right. It’s not totally clear to me how to handle stops under construction since things under construction are tagged differently by different mappers. Thus, I decided to ignore them in PTSA. But in this concrete case the light_rail=yes gives PTSA a hint, that this node is somehow related to public transport, while ignoring the construction:... tags. Opened an issue here, too, and will fix this (hopefully) soon.
Initially “on” was the default. But then the map looked quite crowded by those pink dots and I decided that “off” is a more pleasant default. Maybe I could move the dubious objects switch to the sidebar’s top. Will think about a better/more obvious solution.
That’s not a typo. I made up the word “plole” to refer to poles or platforms or both, that is, to the place where passengers are waiting. The Help page has some explanation.
Yes, the pole is too far away from the platform. PTSA allows for a distance of up to 2 meters between platform ways and poles (1 meter in case of platform areas). Both the pole and the platform mark the waiting area. Thus, the pole should be on the platform (up to some tolerance).
Checked the location on street level images: Up to now I thought that (in Germany) the H-sign has to be close to the street. But here it is quite far away from the street. Seems to mark the shelter instead of the bus’ stop position.
Allowing for larger distances between platforms and poles in PTSA results in problems with several parallel platforms/poles at bus stations, for instance. For the moment we have to live with this non-matching in PTSA. Maybe one could map the (quite large) platform as area? Then the pole will be close to or inside the area.
If there pop up more such (for me) cumbersome stops with pole far away from the street, I’ve to think about how to deal with them in PTSA…
If you find more unclear situations please let me know. That’s very helpful for further development!
node is tagged as stop position for bus, but is not on any relevant track
The same message on a pink dot helped me spot a stale highway=bus_stop that has remained after a route was changed, maybe only though, because it was also tagged pt=stop_position? PT mappers here only in PTV2. Great that your tool honours bus stops!
That’s really interesting! Looks like a situation that is handled incorrectly by PTSA. PTSA considers highway=pedestrian as a suitable track type for bus only if there’s an additional psv=yes. At your location there’s no psv=yes, but a motor_vehicle=yes @ (Mo-Fr 0:00-16:00, Sa 0:00-24:00, Su 0:00-24:00) instead. PTSA does not care about this tag at the moment. That’s definitely something I should include into the processing. Opened an issue to keep this in mind for the next dev session.
By the way, in Google Street View I cannot see any time restrictions. Looks like cars are allowed all the day (and night). But my knowledge of Austrian traffic signs is very limited.
I guess I have to revert some changes there This street in fact is a living street I have been there three months ago. The centre was retagged meanwhile. I think wrongly, the outer sections still living street. I remember having seen the sign in this place. May have to wait for re-survey though.
Anyways, adding psv=yes no big deal, after all, it is correct. The bus goes there, so much for certain.
UPDATE: Of course, reality is a bit more complicated. In summer, there is a temporal pedestrian area in the afternoon, while there is a living street all year around. There is more than that, but that is the main point.
This pole is 0.56m from the platform, but is not recognized. The pole and platform haven’t been modified recently.
Most warnings in The Netherlands are related to unrecognized poles.
Incorrect tagging might be an issue here (at least motor_vehicle should be motor_vehicle:conditional here by wiki). Either way, PTSA should pay attention to motor_vehicle key in pedestrian zones.
In PTSA each pole may belong to at most one platform object. From the details page we see that PTSA matches the pole to the long line, which is correct.
I think this platform should we reworked in several aspects:
Did some research to find more/all multi-object platforms. Turns out that they are used heavily in the Netherlands only and about 80 per cent of them have been created by a single user. Here’s an Overpass query counting all multi-object platforms in an area and the ones created by the specific user.
A few instances exist outside the Netherlands. But all I checked in detail are false positives: a bus platform above a subway platform looks like ‘platform in platform’ without considering the level key.
For the moment I consider multi-object platforms as bad tagging practice. But would be nice to read some comments on this view.
Looking a the history, the original mapper only tagged the area with public_transport=platform. The ways on the platform were tagged with highway=platform. The public_transport=platform tags on the ways were added later, triggered by a maproulette challenge.
I’ll bring this to the attention in the Dutch PT topic. The original mapper of the platforms is active there as well.
For PTSA highway=platform and public_transport=platform are more or less identical. The former is ‘old’ tagging scheme, the latter is PTv2. Removing the addition public_transport=platform wouldn’t solve the issue for PTSA if there still a ways with highway=platform on the platform.
Thanks for opening the discussion in the Dutch community! Could become very interesting.
I recently read that one limitation of PTv2 is that platforms cannot be divided, which means that partially covered platforms cannot be accurately modeled.
No clue if that still holds true as the post is 4 years old.
I think it cannot be changed as it is essential to the concept of PTv2.
Every stop of the vehicle is part of the relation with two parts: first the stop_position and immediately afterwards the platform with the same name. Only if one of them is not mapped, it may be omitted. It has to be included otherwise. If more objects with the same name occur afterwards in the route, they designate a different stop of the vehicle (which occurs rather often in bus lines). So PTv2 (and PTv1) have the property, that you can find all the lines belonging to a stop object by looking up the memberships of that object.
So one stop of the vehicle cannot have more than one stop_position and one platform in the PTv2 route and all stops and platforms must be members of their routes. This excludes the splitting of platforms.
It also excludes adding additional separate objects with PTv1 tags like a highway=bus_stop node on a highway=platform line. All the old tags are completely valid in PTv2. Every railway=platform is a PTv2 platform. Every highway=bus_stop which is not part the way of the vehicle is a PTv2 platform. Other highway=bus_stop are PTv2 stop_positions. None of them needs a public_transport=something to be a completely valid PTv2 object.
As I was not able to convince a majority of the mappers that this was written down in the PTv2 proposal, I’ve given up mapping Public Transport.
