OpenStreetMap

gileri has commented on the following diary entries

Post When Comment
public_transport tags don't add any information about 13 hours ago

To clarify, I do not bring DWG threats at all. I just state that the discussed edits can easily be considered controversials. DWG usually revert whole changesets, or whole series of changesets, even if there is "good" data mixed in between. I have been of the receiving end of the DWG revert hammer, and have witnessed reverts of other contributors which were a bit heavy-handed. I am not asking of DWG to intervene, and I think never did before.

OSM diaries are not "safe space". Publications here, especially ones who call for undifferientiated mass edits, will be challenged. And challenging ideas is precisely what Polyglot and Glenn Plas are doing when they want to "align heads in the same direction". Same direction being away from the PTv2 status-quo.

I tried to state that Polyglot is obviously a heavily implicated OSM contributor, that they bring value to OSM, just like me and a lot of contributors. But even very smart people can do dumb things (I do too regularly), and I think this blog post isn't contributive. That doesn't belittle him, or his achievements at all.

Regarding the voting system, I agree with the example you stated, and some proposals results may be bad because of such voting issues. PTv2 was not such a proposal; it was clearly almost unanimous, with 83 positive votes for a total of 92 votes.

I do not need to state what I think that PTv2 brings to OSM because it is already documented in the PTv2 proposal. I've already tried to adress my concerns in a previous diary from Polyglot, who unfortunately didn't give answers to the points I raised.

And while I didn't edit as much PT as Polyglot did, I have overhauled a big chunk of the OSM PT in the third largest city of France, and developped a PTv2 viewer (not great, but it mostly works), so I think I have enough credentials to have an opinion on the subject.

I changed my vote for the PT "v2" scheme to no about 13 hours ago

Blast! I meant to post my previous answer here

I changed my vote for the PT "v2" scheme to no about 13 hours ago

To clarify, I do not bring DWG threats at all. I just state that the discussed edits can easily be considered controversials. DWG usually revert whole changesets, or whole series of changesets, even if there is "good" data mixed in between. I have been of the receiving end of the DWG revert hammer, and have witnessed reverts of other contributors which were a bit heavy-handed. I am not asking of DWG to intervene, and I think never did before.

OSM diaries are not "safe space". Publications here, especially ones who call for undifferientiated mass edits, will be challenged. And challenging ideas is precisely what Polyglot and Glenn Plas are doing when they want to "align heads in the same direction". Same direction being away from the PTv2 status-quo.

I tried to state that Polyglot is obviously a heavily implicated OSM contributor, that they bring value to OSM, just like me and a lot of contributors. But even very smart people can do dumb things (I do too regularly), and I think this blog post isn't contributive. That doesn't belittle him, or his achievements at all.

Regarding the voting system, I agree with the example you stated, and some proposals results may be bad because of such voting issues. PTv2 was not such a proposal; it was clearly almost unanimous, with 83 positive votes for a total of 92 votes.

I do not need to state what I think that PTv2 brings to OSM because it is already documented in the PTv2 proposal. I've already tried to adress my concerns in a previous diary from Polyglot, who unfortunately didn't give answers to the points I raised.

And while I didn't edit as much PT as Polyglot did, I have overhauled a big chunk of the OSM PT in the third largest city of France, and developped a PTv2 viewer : https://gileri.github.io/OSMTransportViewer/ (not great, but it mostly works), so I'm a bit familiar with PT/PTv2.

public_transport tags don't add any information 1 day ago

Removing a wildly used and growing valid tag, which has been properly voted on, is silly. But bragging about removing it without concern is dumb, Using terms like crusade, mission, epiphany sounds burlesque and doesn't help your point of view.

I am a simple contributor, but I ask you to please stop immediately removing removing without discern 'public_transport' tags, as I and many other see value in those.

Also, please split removal of public_transport tags and data input/update into different changesets. When doing very controversial edits, mixing such edits puts "good" data at risk of removal if people (DWG or otherwise) reverts your changesets. Even if I don't agree at all with your methods and choices, it would be sad to lose the value addded in those changesets because it is hard to separate the "good" from the "bad".

I changed my vote for the PT "v2" scheme to no 11 days ago

Mapping of public transport should be within reach of all mappers.

Adding two points, linking them in a group and adding those two points to related routes doesn't sound unfathomably hard. If it's too hard, maybe entering PT data into OSM isn't for this person ? That's why we have software like StreetComplete where contributions can be made without any prior knowledge, with a limited scope to reduce chances of error.

Converting from the old style to the "v2" is not a trivial exercise.

Data upkeep will always be a more more heavy-duty that adding a single shop for example. I don't see why PT overhauling task specifically must be done by anyone.

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

I have this perception, the place where the vehicle stop on the way and the place where people wait are not the same place, and can have different attributes (light, accessibility etc.).

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.

The end goal of OSM should be to map precisely data even if it requires a bit more complexity (the world is complex really)

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.

Why should you care whether your way of mapping is "fully compatible with PTv2" ? As long as it doesn't add invalid or duplicated data or makes it hard to enter more complete data later, I don't see any problem.

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.

See my first answer

The way it's interpreted now from the wiki is too complex and hard to maintain.

That's your opinion. I find it adequate to map what is on the ground.

I changed my vote for the PT "v2" scheme to no 13 days ago

Why not just map the platform as you prefer mapping only one node and let other mappers map using the complete PTv2 scheme ?

That way you can keep adding correct and PTv2-compatible data into OSM, and everyone is happy.

Vespucci 11.0 BETA 2 months ago

Thank you for the writeup !

Buses again 3 months ago

I would first map the variant with the largest schedule, then do at most 2-3 variants per route and would not bother with little exceptions to services. Just be sure to make the website=* tag point to official and up-to-date information to guide travelers.

I too wouldn't number the variants unless it's used by the bus company or operator.

I don't know what you mean by BPH or BPD

OSMCha News - February/2018 5 months ago

Nice, thanks for the update !

SMART bus stops 5 months ago

Congrats !

Nominatim and Postcodes 6 months ago

Thank you for these insights in Nominatim !

gpxupload.py 9 months ago

Also maybe make a new blog entry for the new release, such old entries are not read by much people.

gpxupload.py 9 months ago

Nice, can't wait to see it !

loop dee loop 9 months ago

What is exactly the problem ? An error during registration on the OSM wiki ?

I don't see any edits since 2015 : https://wiki.openstreetmap.org/w/index.php?title=OpenID&action=history

What's new in OSMCha 9 months ago

Nice writeup and update ! Thanks !

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

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)

Why is the node next to the road the "primary" feature on a PT route ? Also, no it may not be immediately apparent for a lot of cases; for example when the node is between two roads, when buses are on a opposite lane.

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

I agree, but I'm not sure to find an accurate enough method of drawing such features as of now.

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.

Are you talking about "minor" features such as waste baskets and benches ?

The stop_area relations can be used to group all the objects together that make up the stop

Yes. However linking features like waste_baskets is more discutable as they are not really related to the bus stop apart from proximity.

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.

Ideally software and users would be able to parse informations from the stop_area, sadly this may not always be the case. So I usually duplicate information there, but would not document or encourage this.

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

Also no reason why the stop details should be repeated on them and no real need to add them to the route relations

Why should the platforms be part of the route and not the stops ? I don't see why one should be prioritized above the other; in I would argue that to the route the bus/train/tram takes the stopping positions are more related. So I think the best thing to do is to add them both to the relation; it's really not a big deal.

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

I don't understand what is the issue with PTv2. The previous schema was limited and imprecise.

The downside of having a more exact schema is that it's less simple. But that's the price to pay to have an accurate map. You can't always map complex things with simple schema, sometimes you need to accept a bit more complexity (let's face it, it's really not that complicated to map stops and lines).

What's even better with PTv2, is that if you don't want to map stop_positions for example, you can just map the platforms, and let someone else map the rest. Please just don't delete correct information on the map because you don't want "extra complexity".

Switch2osm "Manually building a tile server" page updated about 1 year ago

Neat, thanks !