OpenStreetMap

Polyglot has commented on the following diary entries

Post When Comment
public_transport tags don't add any information 1 day 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:

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

Jo

public_transport tags don't add any information 1 day 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.

Jo

public_transport tags don't add any information 2 days 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.

Jo

public_transport tags don't add any information 2 days 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 days 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 days 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 days 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.

Jo

I changed my vote for the PT "v2" scheme to no 12 days 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.

Polyglot

I changed my vote for the PT "v2" scheme to no 14 days 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.

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

https://www.youtube.com/watch?v=3zZ88g56o30

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 14 days 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! about 2 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?

Polyglot

PT v3 some thoughts 7 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 7 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.

Jo

OSM Provided Services Are Not a Safe Place 7 months ago

Don't Panic!

Frustration about iD editor's inability to easily draw rectangular buildings 7 months ago

Hi Andy,

Full disclosure, the HOT mailing list is one of the few that I'm absent from. I also think the iD editor is pretty good for beginner level mapping. Unfortunately one major thing it's lacking is an easy tool for adding rectangular buildings that don't end up as meaningless area=yes closedways.

My personal preference is to get people started on JOSM right away, but having tried that, I know it's not easy either and mapper retention is definitely not higher.

So I was not reacting to the whole preceding discussion on that particular mailing list and I'm definitely not trying to attack Bryan personally in any way. I think he did an amazing job developing iD further.

Frustration about iD editor's inability to easily draw rectangular buildings 7 months ago

Hi Komяpa, Bryan is already used to being upset by me. :-) I left him alone for many months now. There actually are developers, but they are spread thin, as OSM is very broad.

-karlos- I don't use iD either, but I am, occasionally, presented with the hubris in its wake.

There is indeed a function to square an area, if it's not too irregular, at least. There is also an extensive tutorial explaining what's the shortest way to developing RSI or a tennis elbow for people wanting to use it to draw more than a handful buildings. It is indeed annoying that one has to deselect and select again for 's' to work, I'd also call that a bug (but not out loud, don't want to upset Bryan TOO much either now).

Fixing that issue is not the solution to this problem though. A whole new map mode dedicated to drawing rectangular buildings is. I fail to understand why it has to take many years to actually develop this feature. I'm not much of a programmer myself though, so maybe I'm severely underestimating the required mathematics and analysis involved...

Frustration about iD editor's inability to easily draw rectangular buildings 7 months ago

What is really needed is a new button next to point, line and area that says: building. The areas it draws would be rectangular right away, and tagged building=yes.

And this is not a problem that only regards HOT mapping, so unsubscribing from that mailing list won't help much, if anything. The reason why the problem becomes apparent to HOT mappers is that there is an extra step involved in mapping for HOT projects, performed by validatorsj, a species endangered by extinction.

Time is valuable, using it to contribute for others :) 9 months ago

Hi Agatha,

You know what would be very useful too? There are projects on tasks.hotosm.org in Bangladesh too, like this one:

https://tasks.hotosm.org/project/3652

You can find them by typing a search term. The advantage you have is that you would have a very good idea what you're looking at, when on familiar terrain.

If you like, I can show you how to map more efficiently with JOSM by having a Google hangout or Skype talk.

Polygllot

GSoC 2017 PT_Assistant plugin for JOSM 9 months ago

What do you think of this list?

https://wiki.openstreetmap.org/wiki/Google_Summer_of_Code/2018/PT_Assistant_Plugin

Maybe you also want to add to it. I might try to program some of those myself, or I'll use the easier ones to test candidates for next summer's GSoC.

I think there is definitely still room for improvement. One issue is that it should be easier to verify what will be done when using the fix button. Visualisation, but that's a hard nut to crack.

GSoC Diary: Conclusion 10 months ago

For the time being you can start to learn how to create models and create some. You might also want to document your "learning path", so others can follow more easily. (Myself included, I have no idea how to get started with Blender for drawing models of buildings and structures either)

I realise it's less attractive to do so, if the models aren't readily accessible, but it's good to know that that's in the pipeline.

Cheers,

Jo