Polyglot has commented on the following diary entries

Post When Comment
San Diego County Bus Stops and Bus Routes 1 day ago

Do you think you might be able to mobilize some people to go out and make Mapillary/OpenStreetCam pictures of the stops?

What is interesting to know is whether there is a bench/waste bin/shelter and whether there is a platform area where people wait. If the kerb is higher to make it easier for wheelchair users to alight the bus/tram, that is also interesting information. Also if there are tactile_paving tiles or a button giving audible information for blind people (not exactly sure how they are supposed to find those buttons, but OK). Anyway, those are just some attention points if you're out there to make pictures anyway.

The most important is, of course, to make sure you get the name of the stop, to compare with what's in those GTFS files (no abbreviations). If those ref numbers are on them so the public can see them, then it's really good to take note of them, as it will make it easier to know which stop belongs to which route (automatically) later on.

What I also like to do, is take note of the line numbers and store those in route_ref, separated by semicolons. When surveying, it's usually easy to add them. And when creating the route relations it's convenient to have them.

San Diego County Bus Stops and Bus Routes 1 day ago


I hope I won't discourage you. I just downloaded San Diego in JOSM using the Overpass Query you find here (This will result in a dataset that only has PT related objects):

Mapping public transport for an area like that is going to take a while. It's probably best to do it line by line. First map all the stops, then connect them using route relations.

I see you use JOSM, that's great! We created a plugin called PT_Assistant, which might be an enormous help.

If you like we can do a Hangout or Skype conversation and I can show you how it works.

I also created some screencast videos:

Sorting route relations 13 days ago

JOSM's PT_Assistant plugin now also helps with cleaning up bicycle and hiking routes. Where the ways forks and thus forward/backward roles are needed, it will colour both 'legs' in different colours. This makes adding those roles and especially knowing whether forward or backward is needed a lot easier. This is not only necessary on oneway streets. Bicycle routes will also fork when cycleways are drawn on both sides of the road and on roundabouts with split ways, where they might not use the whole roundabout.


Tram lines in Riga (Latvia) 14 days ago

It took a bit longer than I had hoped. All the tram rails now use their own OSM ways, which is a lot easier for the renderer. It's also a lot more precise, as the rails follow curves which the highways don't. There will probably be some minor errors left. Even though I tried to locate and fix as many as possible. JOSM's PT_Assistant plugin works wonders for this.

Tram lines in Riga (Latvia) 16 days ago

I'm also in the process of converting the tram rails to their own ways, left and right from the highways. It will take a bit longer before I can upload, it's not entirely trivial to accomplish and Ilike to get it as good as feasible. There might be some errors left for local mappers to fix, but that will be for later. I'll let you know when I'm ready to upload. If somebody knows about better imagery than Bing for Riga, I'm interested... Polyglot

Fresh Imagery for Ashgabat Metropolitan Area, Turkmenistan 17 days ago


I added it to the imagery resources of JOSM. I started using the imagery to find bus stops with bays. Those are easily recognizable on this imagery.


Tram lines in Riga (Latvia) 18 days ago

Hi Yevgeshik,

If you want to check that everything is alright with the tram line in Riga, you can use:

That query also works in JOSM.

Download/Download from Overpass API.

If you install the PT_Assistant plugin, you can get a more in depth analysis of the routes.


Dasar Catering 18 days ago


Get Melbourne IT Support Services 24 days ago

How should we notify OSM admins about spam on our Diary entries?

Public Transport Mapping, why do we add the stop details several times over? about 1 month ago

I'm sorry slhh. I fail to see how such 'hinting to itineraries' could be validated automatically. So I don't see that as a valid way forward. If we want to have less impact of route relations of ways, a better approach would be to make smaller segment relations and use those in the relations describing the itineraries. For the time being the 'explicit' way of describing the ways used by the buses and in which order is the most straightforward (and clear for both users and data consumers) way to go.

DatenDelphin, I would like it best if we can continue using that node next to the way, all through the lifetime of the stop. So no conversion to stop_position node or platform way.


Download along my own virtual way in Overpass API about 1 month ago

It would be stupendous if that could be integrated into JOSM.


Public Transport Mapping, why do we add the stop details several times over? about 2 months ago

That's exactly the reason why the PT_Assistant plug-in was created. It helps a lot to know where there are problems and some problems can be fixed (semi-)automatically.

I also live in hope that one day we'll be able to use route relations containing other route relations like segments, such that each way only needs to be a member of 2 route relations, one for each direction of travel.

This will make maintenance a lot easier, but it comes with the price of some added complexity. At the moment it's possible to visually check for continuity of the ways. We'll need additional editor support in the relation editor though.


Public Transport Mapping, why do we add the stop details several times over? about 2 months ago

I think that we should be able to get from the simple cases to the fully mapped ones without the need to transfer the stop's details from one object to another.

That's another reason, why I'd start with a public_transport=platform node and keep going with it. Both to represent the stop, as for adding it to the route relations.

This also helps preserve the history of that stop, but most importantly it simplifies everything, regardless of whether a stop is already mapped in all its detail or not. It also helps consistency. Both stops in the middle of nowhere and stops that are part of a complex bus stations are then mapped in the same way. On a node, next to the highway. Route relations are easy to sort. In case of ambiguity, we can add stop_area relations to show which platform node belongs to which stop_position / platform way. (This presupposes that stop_area relations contain pairs of platform node / stop_position node as a basis and not all stops that happen to have the same name, those can easily be found based on proximity)


Public Transport Mapping, why do we add the stop details several times over? about 2 months ago

For me the ideal scenario is as follows:

Concentrate all the details (name, ref, zone, route_ref, operator, network) - on a node (as it has coordinates) - next to the highway (so it is immediately apparent in what direction the bus travels)

Add additional details like bench and waste_basket as separate nodes Add additional detail like actual platform as way or area Add shelter as area, like we do for buildings

Once all the details of the logical bus stop are on a single node, use this node in the route relations. To avoid clutter in the route relations, it would be better to not add them to the route relations.

The stop_area relations can be used to group all the objects together that make up the stop. (platform node, stop_position node (if mapped), platform way (if present and mapped), shelter, waste_basket, bench (if present and mapped). Repeating name on stop_area relations will make managing them easier, but no need to repeat the names on the platform ways or the stop_position nodes.

Public Transport Mapping, why do we add the stop details several times over? about 2 months ago

Don't get me wrong, we had to get away from the principle of throwing everything in a bag and hope for the best. All v1 was good for was rendering where you might encounter a given line. There was no hope to be able to validate it automatically though. What I'm proposing is a way of mapping public transport without duplication of information. I don't mind some redundancy like mapping bin=yes/bench=yes/shelter=yes and also mapping amenity waste_basket/bench and shelter as separate ofbjects, but repeating the name,ref,operator,network,route_ref and so on will quickly get out of sync.

Of course, once all the details can be found on a node highway=bus_stop public_transport=platform

it would make no sense at all to add other objects to the route relations. Especially given that there are a lot of route relations, one for each variation of a line.


Public Transport Mapping, why do we add the stop details several times over? about 2 months ago

I'm converting those older route relations to v2. That's not the issue. What I'm concerned about is that v2 is far from perfect. It's too complex and it has duplication of information everywhere.

I don't mind redundancy, like having bench=yes on the bus stop node and an amenity=bench mapped explicitely on a node of its own. But having the details like name, ref, operator, network several times over and adding each stop to the route relations twice irks me.

To help mappers having an easier time to map public transport, or at least not break those route relations when they make changes to the ways, I'm overseeing development of PT_Assistant.

But the scheme should be as user friendly as it possibly can be.


Autobuses de transporte público en Málaga about 2 months ago

Si por acaso tienes tiempo manana en la tarde 19h CEST, me gustaria hacer un hangout contigo. Quiero mostrarte como el plugin PT_Assistant pueda ayudar a mapear el transporte público.


Breaking route relations while splitting roads 3 months ago

I'm not putting the stop_position nodes into the route relations, I hope it doesn't hiccup on that.

Breaking route relations while splitting roads 3 months ago


I don't exit the relation editor anymore, instead I use the lowest button on the middle button bar, to remove the selected members from the relation and save. Then I split the road and readd the part I wanted. Then I use the middle sort button on the left row of buttons to sort the relation members from that point on, downward.


Breaking route relations while splitting roads 3 months ago

Hi, last year we created a plugin to help with keeping route relations sane. It's called PT_Assistant. This year another student is working on it and it will be extended to bicycle and foot route relations.

What I do now, when working on a dataset for a longer time:

Update Selection If there are any conlicts, resolve them in favour of the last editor, instead of myself. Validate (either the route you want to work on, or everything, or use the upload button, but abort before actually uploading, this causes validation to be performed on everything that was changed) Use the validation warnings (and sometimes the fix button) to resolve continuity of the route relation. Put all the stops (platforms and/or stop_positions) to the beginning of the route relation Do a visual check of the continuity of the line Use the middle sort button, to sort members from the current position down (that's the reason for putting the stops first)

Select the relation and use Upload Selection before doing more work. Find all that was modified and use Upload Selection again on everything that was not a relation in case more roads were split.

Your way works too, but I can't get used to it, for some reason (perceived complexity).