Polyglot has commented on the following diary entries

Post When Comment
Public Transport V2 - many routes are invalid... 15 days ago

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.

Posting suspicious features into OSMCha about 2 months ago

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.


Delhi's longest bus route, Himachal Pradesh, counting POIs, and whom does OSM help? 2 months ago

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.


Delhi's longest bus route, Himachal Pradesh, counting POIs, and whom does OSM help? 2 months ago

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!


Delhi's longest bus route, Himachal Pradesh, counting POIs, and whom does OSM help? 2 months ago

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!

I changed my vote for the PT "v2" scheme to no 3 months ago

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.

public_transport tags don't add any information 3 months ago

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:


public_transport tags don't add any information 3 months ago

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.


public_transport tags don't add any information 3 months ago

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.


public_transport tags don't add any information 3 months ago

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.
public_transport tags don't add any information 3 months ago

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.

public_transport tags don't add any information 3 months ago

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.

public_transport tags don't add any information 3 months ago

Believe me, I have been thinking this over for several months, even years by now. It's only recently that I start speaking out about it. If mass edits take months to complete, they are actually regular mapping. Most of those bus stops have been added by yours truly, by the way. Like a fool I have been adding public_transport=platform/bus=yes, in addition to highway=bus_stop to them.

Hopefully it can serve as a wake up call that there is something fundamentally wrong with the public transport scheme as it is described at present on the wiki.


I changed my vote for the PT "v2" scheme to no 3 months ago

I don't mind adding the detail. We describe the world in ever more detail and precision, that is just fine. When adding detail starts to mean that complexity increases, that's where I disagree.

When each and every stop is represented as a node, we can add shelters as an area, platforms as ways or areas. stop_position nodes if you must. waste_baskets, benches, all you want.

But the basic premise should be and remain: map the stop on a node next to the highway/railway. That node contains details like name, ref, operator, network, route_ref, etc. And that node is added once to the route relations (or several times if the vehicle serves it more than once on the variation represented by that route relation).

This works perfectly fine, without creating the need to add more than one object to the route relations. AND without the need for duplicating details across several objects.


I changed my vote for the PT "v2" scheme to no 3 months ago

Mapping of public transport should be within reach of all mappers. At the moment most say: it's too complicated, leave it to the experts. Of course the 'experts" don't have enough time to mend millions of route relations around the world.

Converting from the old style to the "v2" is not a trivial exercise. Some mappers tag them as public_transport:version=2 just to make the validator shut up about them. They must not have the PT_Assistant plugin installed, as that one would make a lot of noise about them. The right thing to do is to put public_transport:version=1 on them. Or convert them, of course.

I'll do one just to show what is involved (and how PT_Assistant can help with the task, even if it can't do it all automatically, as those v1 relations are mostly useless except for giving a rough indication of which streets the buses use.

I created 2 screencasts with a demo of how PT_Assistant can be useful for such conversions.

Those Blacktown routes should be verified further though, that relation I started with was 'almost' v2. Usually a v1 has stops for both directions, this one didn't.

I changed my vote for the PT "v2" scheme to no 3 months ago

Because there is this perception of some that mapping the stop on a node, with the details on that node exactly once, and having just these nodes in the route relations is somehow incomplete or even incorrect.

At present the wiki is interpreted as if the end goal is to have a platform way next to the road (for some regardless of the actual presence of such platform) and stop_position node on the highway as the only solution that is PT v2 compatible.

I can't follow every edit happening on the wiki, but I did make sure that is still says that having a single public_transport=platform/highway=bus_stop node next to the highway and having just this node in the route relations IS fully PT v2 compliant. There is no need for futher "improvement", when mapped that way.

Now, if there are actual platforms, it's perfectly fine to map them as ways or areas, but they don't need details like name, ref, etc. (Those are already present on the nodes that represent the stop). This doesn't limit the ability to map stops in ever more detail, but doing so wouldn't affect the route relations.

And I would like to see that we move to a solution where the end goal is to have a single object that represents a stop for each stop. Call it PT v3, if you like. The way it's interpreted now from the wiki is too complex and hard to maintain.

There should be no need to 'convert' from that basic node that can be used for a simple bus stop to a way/area at any point in the lifetime of the bus stop. No need to update the route relations, or 'augment' them by adding stop_position nodes as well.

A single object for each and every bus or tram stop on a node next to the highway/railway. That's what I'm saying.

Over 75, 000 schools imported in Peru! 5 months ago

Wonderful! I think I'd consider validating that data and add it to Wikidata while doing so. Would that be alright?

¡Genial! Estoy considerando de hacer el paso de la validación y al mismo tiempo agregar los datos a Wikidata. ¿Eso les parece buena idea?


PT v3 some thoughts 10 months ago

User Weide is proposing something along those lines. For buses just the stops is still ambiguous though, so he wants to add nodes at crossings along the way, to give an indication of the route the bus follows. I don't like that too much, because it moves the burden of calculating and recalculating the which ways belong to the routes to the renderers over and over again. This means it won't be possible to fetch itineraries in a convenient way.

It may be a bit more practical for mappers, but it's a lot less useful for renderers.

PT v3 some thoughts 10 months ago

Hi Mr_Brown,

There hasn't. It would be very hard to accomplish technically and most mappers' opinion is that timetables don't belong in OpenStreetMap. Even if we would come up with a scheme, it would be really hard for contributors to keep those timetables up to date in OSM.

Ilya privyet,

The version number isn't all that important. I'm indeed trying to get everybody to map the same way, but I'd like to see it done in a scalable mapping scheme that is simple enough for anybody to understand, but expressive enough to go very deep in detail where needed/wanted.


OSM Provided Services Are Not a Safe Place 10 months ago

Don't Panic!