OpenStreetMap

Hi. I’d like to ask you to the Metro Mapping proposal page, read it in full and leave your vote below. The proposal mostly summarises subway and light rail mapping practices and introduces a few useful changes, listed in “What This Affects” section.

You will find many opposing votes there. You might be tempted to read only these comments and skip studying the material. It is simpler, and some of the authors are well-known in the community: they must know what they are talking about, right? And there are 8 screens of text, who would read that?

That is what I don’t like in the current proposal system. It does not matter what the proposal actually contains, how deep an author knows the topic or if the features in questions are already mapped in a suggested way. What a great power you have when the voting starts — strike out weeks of work by writing a few words! You must be a fool not to excercise that power. And who knows what might happen if the proposal is approved? Everybody understands you cannot edit a wiki page after that. You would need to write your own proposal, and it might be rejected, so it is safer to just oppose.

For the first time in OpenStreetMap history I started actually using the data to route users through subways. And found out the tagging is insufficient: there was no sane way to map interchanges, and you could put thousands of members into some relations. For a mapper things also looked bleak: to map a subway properly, you would have to know how underground tracks go, and where underground platforms are located. No wonder that a beta version of a validator showed that the world had like three subway systems mapped good enough, out of nearly two hundred.

So I’ve put up this proposal page, that makes mapping subways simpler, and makes using the data easier. You could learn some things from it you’ve never thought about, like types of interchanges or the importance of colours. Then I wrote about the proposal to tagging@ and talk@ mailing lists, and in the course of a month got many great comments, that helped polish most sections, and rewrite some from scratch, adding more pictures and replacing blocks of texts with simple lists.

I have also finished my subway validator, that not only validates, but prepares data structures for metro routing and rendering. With it, I have been tidying up subways all over the world, finding a few flaws in the proposals, but mostly learning about regional specifics. I’ve done Moscow, London, Paris, Berlin (both U-Bahn and S-Bahn), Yokohama, Algiers, Lima, Pyongyang and dozens more cities. Their subways conform to the proposal, and I have not broken any external app that used these, or uploaded any extra tag. Well, except network:metro in Germany, since they have an interesting way of tagging networks (thanks Nakaner for the explanations).

With over 60 metro networks mapped, dozens of questions answered, most of which affected the proposal, after discussions in wiki, talk@, tagging@ and in changesets, I decided that the proposal is ready and started the voting. For a moment I thought the OSM community was reasonable. It’s like in my seven years I haven’t learned anything. Not after the turn lanes proposal, not after hate messages about the water=* proposal, five years after it’s approved, not after stalled pull requests to the OSM website.

Very few people in OSM are willing to compromise. Especially people from Western Europe, who think they own the project. Because you cannot edit a wiki page without a proposal, I assume. Because no matter how many suggestions you’ve accepted, layer=-3 instead of -2 makes the whole work moot. It would ruin the PTv2 schema. Because despite “discussions on the Talk page” policy, when the voting starts, you can write a page of opposing arguments right into the proposal page, and nobody would turn to the Talk page to read answers, not even the person who wrote the arguments. Because it is easier to oppose than to approve: all arguments are already laid out for you, and finding answers to these in a 56-kilobyte Talk page is too hard. For one person, it’s because I should have discussed the proposal in his 3-messages-a-month mailing list, not in talk@ and tagging@.

You don’t even have to understand PTv2 schema to vote for its extension. Like people who +1’d the Carto’Cité comment about stations as nodes and did not even click on the Metros link to see that OSM wiki had already told everyone to map stations just as nodes. OSM is told to be a do-ocracy, but work does not matter anywhere here. You might have studied prior art and mapped hundreds of networks, but Carto’Cité has an authority over french mappers, so you bet all of them will come and vote against your proposal, even understanding that their arguments have nothing to do with the proposal and are inspired by a potential breakage of some of their inner closed-source tools. By the way, we’ve talked that over, I’ve converted the whole Paris subway network to the new way, and nothing broke.

The voting closes in a week, and there are more opposing votes than approving. Of course it would not matter after I have finished my work on tidying up metro systems: the changes will just go into wiki with the “not approved, but widely used” status, like highway=milestone. To help novices understand mapping subways, some of us will direct them to this possibly failed proposal, because the wiki has — and will have — nothing better. The only outcome of failing the proposal will be my continuing frustration of interacting with the OSM community.

So please, if you care about our data not only conforming to some proposals accepted 6 years ago without practical usage, but also being relatively easy to use, please go to the Metro Mapping proposal page and leave your approval. I assure you the OSM database won’t go down in flames after that. Thanks.

Discussion

Comment from dieterdreist on 18 November 2017 at 18:29

If you see that there are more opposing votes than agreeing, it could be an idea to stop the voting and see if you can improve the proposal by integrating the comments. Some people have written a lot of things that seem to make sense. For example you say that every change is listed in the “What This Affects”-section, but there’s no hint about deprecating ways and multipolygons for stations in this section (incomplete). I also don’t see the point in making a proposal which “mostly summarises subway and light rail mapping practices”. If you made a proposal with only the things you want to introduce or deprecate or change, without those that stay as they are, your proposal would maybe be more concise.

Comment from Zverik on 18 November 2017 at 20:45

Deprecating? They have always been recommended to map stations as nodes, until your silent edit a year ago to one of the pages. Of course it’s safer to edit circumventing a proposal stage, since nobody could oppose the change. I just read the wiki and put what I found in the proposal.

Comment from dieterdreist on 18 November 2017 at 23:02

What you call a „silent edit“ and „circumventing a proposal stage“ is from my point of view updating the wiki to common practice and logics. Stations have an extension, why would you not try to map it?

Comment from dieterdreist on 19 November 2017 at 00:37

about the wiki edit: railway=station on areas was documented in the wiki [also before, until 2015. it was documented for areas since 2009.

Comment from jonwit on 19 November 2017 at 15:26

I am trying to understand your proposal, i read it twice and then the comments for an opposing. You have done a fantastic job documenting a metro network. You even made a subway validator tool!!! I will be putting this on my to do list to try out. However, it seems from the comments that there are a many attributes to map a railway/metro network you forgot or at least people think you forgot. This is why I am abstaining from the vote.

Please remember that 90% of academic papers are never cited, having 2 dozen folks read and comment on your work is an achievement in itself.

Comment from Andy Allan on 20 November 2017 at 15:44

not after stalled pull requests to the OSM website

I know this is off-topic, but I’m trying to work through all the pull requests for the OpenStreetMap website code, and deal with them one way or another - and hopefully deal with them all more quickly in the future. Any help is welcome. Last week I tackled three of the oldest, but there’s still some that are 5 years old!

Comment from Zverik on 20 November 2017 at 18:09

Dieterdreist, from my point of view my proposed updates come from common practice and logics. And I’ve mapped dozens of metro networks to test it. Only in few cities some subway stations are mapped with polygons, and these are mostly a mess. Like in Brussels.

Regarding railway=station, note that I’m not against mapping overground stations with polygons. But drawing a correct polygon for an underground station is virtually impossible. Placing just a point would be more correct and easier for everyone. And, well, station=subway wiki page still has the “only nodes” template.

Andy, thanks a lot for that. I was delighted to see you join the maintainers. I follow your edits on github, and I look forward to your improvements to the website. In the post I was talking about my own pull requests, which were ready to be merged in the website, but because of politics generated a 100-comment discussions instead and resulted in nothing. OSM website needs more developers, but also it needs a better management, that would attract and lead people, create a developer community.

Comment from Nakaner on 21 November 2017 at 23:03

Hi Ilya,

it was not my intention to chase you away from public transport mapping. Public transport tagging is a difficult topic if you go beyond mapping of buses. Due to the difficulty and the nitpicking character of some self-proclaimed “experts” (like me), people are very picky and aim perfect proposals.

The main problem of you proposal was and still is that it is a mix of a useful guide and some tagging changes. Proposals which only contain the changes don’t invite the large audience to read. But proposals which contain too much context hide the changes.

Zverik wrote: > For one person, it’s because I should have discussed the proposal in his 3-messages-a-month mailing list, not in talk@ and tagging@.

That is an example of a excessive nitpicking which is not encouraging and not commendable. You posted a lot on the mailing lists about your proposal and that shows that you have good intentions. If I remember correctly, WeeklyOSM mentioned your proposal one or two times. If you miss a minor special interest mailing list, it is a minor formal defect and could be cured by posting a link to the proposal on the mailing list and extending the voting period for two weeks.

Zverik wrote: > Deprecating? They have always been recommended to map stations as nodes, until your silent edit a year ago to one of the pages. Of course it’s safer to edit circumventing a proposal stage, since nobody could oppose the change. I just read the wiki and put what I found in the proposal.

Hey, that’s not Martin’s fault, it’s me being the bad guy. I did some wiki fiddling which has been reverted later by Martin and I regret it.

Zverik wrote: > For a mapper things also looked bleak: to map a subway properly, you would have to know how underground tracks go, and where underground platforms are located.

What about introducing some kind of “trackless route relation”, i.e. relations which are build like PTv2 route relations but don’t contain all tracks because they are unknown? I think that we should not use route=* to avoid confusion and to make it possible for validators to distinguish between intended and unintended absence of the tracks. That’s why I suggest to use incomplete:route=train/subway/… + incompleteness_state:tracks=incomplete.

Best regards

Michael

Comment from Carto'Cité on 22 November 2017 at 00:02

Hi Ilya,

I came across your diary and felt sad reading it, because of your disappointment and because I feel I’m partly cause of it. I also feel sad because you seem to suggest that I influenced french mappers to vote against the proposal. By no means I would consider doing this ! I do know two persons who opposed, they did not need my influence : both have been involved in mapping subway stations before I even started doing it. The two persons that actually work with me on this project have not taken part to the vote.

I also want to clarify that we (Carto’Cité) are not actually using the data, we just look after the data on behalf of SNCF (the french railway company). And to do so we actually developed a piece of code that analyzes Overpass Augmented diffs. We called it OSMADA and published with an free software Licence : https://github.com/Cartocite/osmada.

The one thing I feel guilty about is not to have spotted your proposal early enough to discuss it prior to the vote. I can only apologize for that now. Maybe the proposal tries to tackle too many issues at once, which makes it hard to understand the full picture. There are bits I have no problem with, such as the stop_area_group relation type, others that make a lot of sense even though they impact data used by SNCF (avoiding these massive relations for Paris railway stations which I don’t personally like), and others that I feel are wrong, such as forcing to map stations as nodes. The latter would mean undoing a lot of work that has been done by mappers, and not just our work : mapping stations in the Greater Paris was started before I got involved in this project.

Now where do we get from here ? I understand you disappointment however I have faith in the OSM community to find a way to come to a compromise. I don’t think that leaving the proposal “not approved but widely used” would be satisfactory for anyone. Could there be a way to split out the proposal into more digestible bits ?

Maybe that situation we’re facing today was to be expected : the more people are making use of OSM the harder it gets to change things. But harder does not mean impossible, it just takes more explanation (and maybe the proposal mechanism needs to evolve, as your post title suggests).

Regards, Antoine.

Comment from sabas88 on 25 November 2017 at 14:10

Damn, I saw the voting only because of WeeklyOSM. I hope you won’t abandon it because although was “rejected” by the wiki users, it’s useful and used/usable by some applications. Thanks!

Comment from dieterdreist on 25 November 2017 at 16:35

Ilya, you write “Regarding railway=station, note that I’m not against mapping overground stations with polygons. But drawing a correct polygon for an underground station is virtually impossible.”

I totally agree that mapping an underground station by survey is far more complicated than doing the same overground. You would need a lot of determination (time) and some geometry skills and some tools like measuring tape or laser disto. I would not expect mappers doing it (usually). But getting the data in a legally compatible form is not completely unthinkable, rather I’d already expect it to be available as open data in some places. You might also find historic imagery from the time of construction (subways tend to be in big cities, and big cities tend to be well mapped throughout history), or the original construction plans might be out of copyright in some cases.

Comment from dieterdreist on 25 November 2017 at 16:40

and in short we’ll be automatically indoor mapping with our smartphones and 3D video-recognition ;-)

Comment from Kwinkwin on 25 November 2017 at 19:21

Most probably, Carto’Cité didn’t actively influenced other voters (Ilya actually never said that). But he does seem to have a viewpoint shared in its community (hey that’s the point of a community). I can understand their fears and you seem to be able to reassure them, Ilya, on particular regarding polygons.

Ilya, don’t let it go : please, go forward and amend your proposal in order to tackle the issues raised by Nakaner and Carto’Cité. I’m sure you can obtain their go-ahead with clarifications and/or subtle modifications, and therefore most probably a positive vote result. These ideas are just too nice to die so soon. The public routes of the whole world definitely need to be mapped properly. And a well-thought guide with a positive vote is a good step (and a fundamental one) toward that, even if it could work/we could live without that.

Being both a Maps.me user and a small OSM contributor, I deeply hope that a consensus will be reached naturally. I am convinced that OSM can be a database representing our real world, both geographically (polygons) and organizationally (routes used by public transport). With a sound construction, every usage of this data should be fine : rendering, routing, name it… Today most within-city navigation is done with proprietary data and closed software. During the last ~5 years, it struck me almost daily (and it still does) that OSM can change that. And that we indeed can move toward freedom !

In short : applause, cheering :)

Comment from AgusQui on 25 November 2017 at 21:13

Many criticize that it is a proposal of mapping, not of the traditional ones with new tags, I see it very positive. In my personal experience it took me a lot to understand how to map public transport, the wikis of each element were not enough, I had to see their discussions, and how to map in different places, and came to a personal conclusion very similar to what Zverik proposed . More mapping guides are needed.

Comment from Zverik on 25 November 2017 at 21:35

Thanks everyone for comments. I plan to do the second take, much shorter, just for changes. After that I’ll copy this proposal to a new page for instructions.

Comment from wille on 26 November 2017 at 17:38

Sorry to not give the attention this proposal deserves, Ilya… I’ve fixed the Brasilia subway network using your validator and I’m planning to work on some other networks in Brasil.

I would suggest you to improve the first diagram, that shows how to map a station with all its elements (entrances, stop_area, platforms, rail line, etc). Maybe mapping a station on a not crowded area will make it easier to understand the proposal.

Comment from trial on 26 November 2017 at 19:02

I know Antoine from Carto’Cité, I’m a French mapper and no, never heard them asking people to vote against this proposal. A subway station is hard to map, but we may have open data available or use improved techniques. I would not prohibit mapping a subway station as a polygon. Yes, split your proposal in two parts: a proposal for the changes and a wiki page for how to map a subway.

Comment from milovanderlinden on 26 November 2017 at 19:19

I think you are doing a great job. You put in great effort and have thought it through in detail. I do not know how much my voice is valued in the Kingdom of mappers, but you have my blessing. If I come across public transport that I want to map, I will use your tools and documentation.

Respect.

Milo

Comment from Claudius Henrichs on 28 November 2017 at 15:31

I am also both an active Maps.ME user (so slightly biased to get this data consumption pipeline from OSM data to app working) and a long time public transport (PT) mapper as well. I found your proposal and the validator tool highly useful to push PT mapping in OSM forward. I used your approach to map multiple subway systems mainly across Asia and it helped a lot to identify and solve problems. Many of the tagging and mapping I found in place was quite outdated and often even inconsistent within the same city.

The one thing I didn’t understand the whole past 1st and 2nd proposal attempts was why it’s not possible to allow both areas and nodes for stations. This freedom - to start with a basic node, but replace it with more detailed mapping if there’s a way to obtain more detailed dimensions - has always been one of the pillars of scalability for Openstreetmap.

I’m glad to hear you will split the proposal part of your scheme from the instruction page and look forward to a great new go to resource being established for PT mapping in OSM.

Log in to leave a comment