That’s a great explanation! Thank you for that tutorial.

Jo

It seems like you are using multipolygon relations. What about site relations?

Polyglot

For Russian, this is work in progress. Part of the reason why I wanted to see the video is to practice with a topic that has my interest, but if I can understand 10-15% at the moment it will be very good already.

Spasiba! Ya gatshu panimat Rusky jezik :-)

Jo

The Youtube video is set to private. Nobody can watch it.

Wonderful story indeed. I’m glad for you it all worked out!

I don’t think the number of map edits influences the decision to support mappers with scholarships. It’s really hard, I think, to review all those applications and then decide which 21 there is enough budget for.

Really glad you are part of our community!

Polyglot

In the mean time it became obvious (after about 7 or 8 long years) that public_transport=platform will never render, whether accompanied by bus=yes, or not. So highway=bus_stop IS necessary and will remain necessary. This, of course, begs the question whether public_transport tags are actually useful. Maybe we can simply drop them.

But if we do that, does it still make sense that the stops get a platform role in the route relations and the stop_area relations?

So many questions. I don’t have the answers. Back when PT v2 was “voted”, I came up with double tagging, but that was with the expectation that highway=bus_stop would one day become unnecessary. It won’t.

Polyglot

As a European it has always struck me as weird to say that the ground floor would be the first floor.

Where does 0 fit in for those who count that way?

Polyglot

Этаж comes from French étage, by the way.

Hi Warin,

Your link to OSM Inspector lands on verification of areas. I think this link works better for public transport itineraries:

Public transport issues around Melbourne

Apparently copy/pasting from the address bar doesn’t work, but there is a permalink option.

Do you mean ‘suspicious event’. A suspicious reason seems to mean something else to me. Like somebody having an ‘agenda’ of wanting to cause harm to OSM and deliberately acting on that.

But the way I understood OSMcha is that it reports events, so the result of such actions.

Jo

It’s a bit tricky (otherwise it would have been done long ago already), for the itinerary, it just might work. For the stops, not so sure. I’m afraid it would be for a next Summer of Code project, though. What I would like to see now, is that it gets expanded to foot and bicycle route relations.

Splitting the destination way (the coloured ones), is already implemented. Splitting the from way (the white one) isn’t yet. maybe it would be feasible to put it on 8. 9 backtracks, 7 skips that gap. 8 could review the white way for suitable side ways for the mode of transport and propose those in colours, then if one is chosen, split at the appropriate position.

I’ll have to discuss the feasibility with Biswesh over the weekend.

Please tell more about the rough edges. I also encounter some, but maybe you encounter different ones.

Jo

Hi Contrapunctus,

I used new functionality in PT_Assistant to conveniently add the ways that seemed to be missing for the other direction of travel of that bus.

I didn’t upload it, as I can’t be sure that the bus does the full itinerary in the opposite direction as well, but feel free to try it out for yourself!

https://www.youtube.com/watch?v=P_7D7Gffccw

Jo

Wow, that is an amazing job! I downloaded the relation, with the plan to see if anything could be improved using the PT_Assistant plugin, but the ways are fully continuous, the stops are all in the order the ways are traversed. No oneway roads traversed against the flow. Wonderful!

Hi Gileri,

I don’t oppose mapping public transport in great detail. I think the basic premise should be as simple as possible though and it should remain the same for a simple bus stop with nothing on the ground or one with all amenities and features.

That’s why I’m saying we should map them all on nodes next to the highway/railway. Add all the details once to these nodes and only use these nodes in the route relations.

Then one can start adding platform ways, shelters, benches, waste baskets, stop positions of the vehicles if you must, electronic displays, tactile paving and so on. There is no limit, but it can all be done in addition to the one node that represents the stop and there should be no need to change the route relations nor to ‘upgrade’ that node to a way/area.

I use public_transport:version=2 as a flag to say: this relation can be validated on the assumption there is a single continuous string of connected ways in it.

I use public_transport:version=1 as a flag to indicate this relation is not ready for such validation, as there is no logic in the collection of ways it contains. All we can safely say about these relations is that those ways have a higher probability of buses of that specific line passing over them. That’s not an absolute statement though, as such routes are most likely not maintained by anyone. So there might be too many ways in them, or ones that are not split where the bus turns off in reality.

Those relations are not candidates for removal though. If a dedicated mapper encounters them, it is possible to use them as a starting point for properly mapping what the vehicles do.

PT_Assistant can help with that too, but it involves a lot of manual work. I created some screencasts about the process:

https://www.youtube.com/edit?o=U&video_id=bwXbPZr6NQc https://www.youtube.com/edit?o=U&video_id=3zZ88g56o30

Jo

If the route relation has public_transport:version=2 PT_Assistant will start from the assumption there should be a continuous string of ways in them. If there isn’t, it can report a gap, or that while following the ways in that particular order, the bus travels against oneway restrictions. The plugin can then also suggest fixes.

When the ways for both directions are in the route relations, the plugin can’t do anything useful with the route relation, except ignore it. Those are the route relations that I would either tag as public_transport:version=1. So I can disregard them at that point in time and possibly come back to them later to deduplicate and convert them.

Jo

That is just wonderful! Clean and simple. I might be tempted to create a screencast to show you how JOSM’s PT_Assistant plugin can help you to get those stops sorted automatically and check for continuity of the ways in the route relations. It would involve putting public_transport=2 on the route relations though. PT_Assistant ignores routes which don’t have that tag set, or have it set to 1.

Jo

The reason why I’m editing quite a bit, is in part because I’m beta testing the new functionality in PT_Assistant.

What I’m seeing in some parts is an overly engineered scheme and in other parts a lot of confusion and misunderstandings.

The reason for posting my concerns about the whole scheme as diary posts, is because I really want to see some discussion on the topic. Preferably including the long tail of mappers who have mostly given up on trying to map public transport. Developing PT_Assistant is an attempt to include all mappers and to make it easier to maintain continuity in those route relations, of course.

For several years I have been trying very hard to adopt those parts of the public transport scheme that made sense to me. The result is that I often get the remark, that I’m supposedly not doing it right. Well, I don’t see value in stop_position nodes on the highway for bus_stops. I don’t see why we would duplicate details like name/ref/operator/network/etc. to more than 1 object and I don’t see why some mappers insist on adding 2 objects to all the route relations.

At present we have quite an absurd situation:

• How should I map a bus stop?
• Oh, that’s easy. Add a node next to the highway where the passengers wait and tag it public_transport=platform/bus=yes.
• But the wiki says public_transport=platform shouldn’t get bus=yes.
• Oh, that’s for platform ways.
• OK
• Oh, by the way, don’t forget to tag it as highway=bus_stop as well, if you’d like to see it rendered on the map.
• Right, so why were we tagging it as public_transport=platform again? Because this one doesn’t even have a platform.
• Ah, that’s because the person who proposed this scheme hadn’t imagined there would be annoying mappers who would insist on wanting to map bus stops as nodes alongside the highways, where it’s easy to see on which side of the road they are. So when such mappers asked what to do with those nodes the answer was put public_transport=platform tags on them.
• I thought you said it was going to be easy?
• You’re right, it would be a lot easier to just tag those nodes as highway=bus_stop and be done with it.

If there are platforms, I don’t mind adding them, lately I switched to tagging them with just highway=platform/railway=platform though.

Those are not the central objects representing the stops though. And no, the stop_position nodes on the way are not suitable for representing the stops either. Just in case someone is going to propose to do that.

What I’m trying to say is, stops can be mapped in as much detail as the mapper has time for, but the basic principle of tagging stops should be to keep it as simple as possible and I think it’s important that stops tagged in the middle of nowhere without even a pole and stops in a busy metropolitan with all possible amenities like bench, shelter, electronic display, wheelchair enabled platform and tactile_paving, should be mapped in exactly the same way. i.e. on a node next to the highway and all the other amenities mapped as separate objects.

When I look around, I see there is a lot of confusion. People who use stop_position, because they understand it as the position of the stop, instead of the position where the vehicle stops. Others who map platforms as ways, even if there are no platforms in reality, just for ‘consistency’. This is just one of the misunderstandings. The conclusion is that the whole scheme is confusing. Adding 2 objects for a single stop (sometimes, not always) also makes it hard to determine how many stops there really are in the route relation that represents that variation of the itinerary.

Anyway, for a long time I’ve been trying to accomodate the public_transport tags, but lately I don’t see the point anymore. I don’t really care if we add them or not. What is needed however is a discussion on how we can map stops and bus lines in a way that makes sense and is accessible to all.

I’m in big part responsible for the growing use of said public_transport tag.

Something I want to apologise for.

Anyway, as soon as a node has the highway=bus_stop tag, it’s a bus stop for all intents and purposes.

The initial plan was to remove those highway=bus_stop tags some day in a very distant future. It’s either one or the other. But I won’t cooperate in the madness of adding tags that don’t add information anymore.

I’m all for standardising, but we’re moving in the wrong direction.