[Tagging] Feature Proposal - Voting - Metro Mapping

Ilya Zverev ilya at zverev.info
Fri Nov 10 16:45:48 UTC 2017

marc marc wrote:
> with so many modifications, it would have been useful in my opinion to 
> call for comments a second time before the vote. I even think that a 
> 15-day vote to make the current mapping of the majority of the big 
> stations INVALID is a bit short.

I posted news about the proposal every two weeks in different channels. The discussion page being 44 kilobytes, I think, shows that many people who were actually interested in the proposal, did comment it (and helped improve it — thanks!). To suggest to continue this would mean you don't value time of others.

> For my part, I have the same criticism as at the beginning :
> - 90% of the proposal is not a proposal. it's a mix of current mapping 
> that doesn't change and extra details.

Yes, and this is clearly stated on the page, along with an explanation of what are we voting for. Your "why change" argument looks weird with this sentence, by the way.

> - On the other hand, the section "What This Affects" is incomplete.
> -- it lacks the incomprehensible prohibition to map a station a an area.

Did you read https://wiki.openstreetmap.org/wiki/Tag:station%3Dsubway ?

> -- the same for entries (you claim that this affects the routing, this 
> is not necessarily true)

I suggest people do mark subway entrances, as that helps with routing. Is that not so? As for nodes vs polygons, again, see https://wiki.openstreetmap.org/wiki/Tag:railway%3Dsubway_entrance

> -- many other details are incomprehensible as "Platform Layer should be 
> at least -3". what should be "mandatory" between layer and -3 ?

I chose -3 from the practical standpoint: -1 is usually used for highway tunnels, and -2 might be used on complex junctions, so having a layer -3 and less would be a safe option.

> -- no explanation why the new shchema is better than the current one.
> for ex why a stop_area should be duplicated stop_area containing only 
> part + a stop_area_group that groups them.

Instead of a single collection of every object on many transfer stations you get separate collections for each and a grouping that shows whether you can go from one to another. How is that worse than the current schema? Stop area groups were proposed initially in the Oxomoa schema, but were somehow lost on the way — probably because overground stations rarely need it.

> At the same time, on the mailing transport, there is already the case 
> that a contributor who "cleanup" sncf station to apply the new scheme 
> without any discussion with the local community concerned with app 
> problems that do not work anymore . The phrase "More than fifty metro 
> networks" has to be read as "no matter what your vote is, we have 
> already begun to impose it". it is obviously not very positive.

Ah. I intended to resolve this privately and to wait a couple weeks before making the issue public, but well, if you insist. Marc refers to this changeset discussion:


Turns out some agency in France misuses stop_area relations to contain _everything_ in the vicinity of a railway station. Which results in a series of gigantic relations of 500-2500 members. They have everything: shops, cafes, signposts, trashcans, benches, footways, steps, railway tracks etc. Even untagged nodes. See for yourself:


In my proposal I specifically suggest to put in stop_areas only objects that are directly related to public transport stations. Which means, no tracks, no shops, no footways. So I was tidying up french metro systems and cleaned up these stop_areas. Then I was contacted by a person from SNCF. As a temporary solution I suggested retagging the original type=public_transport to type=site while creating smaller stop_areas. Turned out, that isn't enough and they want to have a few weeks to reprogram their system.

My opinion is that is an abuse of OpenStreetMap database and a disregard for any current or potential users of map data. If Marc wishes for it to be resolved publicly, I welcome your opinions on this.


More information about the Tagging mailing list