Changeset: 53267689
Subway → Light Rail in Genova, made Gare de Lyon stop_area smaller
Closed by Zverik
Tags
created_by | JOSM/1.5 (13025 ru) |
---|
Discussion
-
Comment from transilien_cartocite
Hi Zverik.
We are looking after railway stations data on behalf of SNCF, the french railway company.You removed most of the members of the stop_area "Gare de Lyon". These relations are being used to extract the data so for now we need to keep the station infrastructure, equipments and services within the relation. I'll put them back if you don't mind, however I'm curious to understand why you removed them.
Regards,
Antoine. -
Comment from Zverik
Hi Antoine,
You have been using a stop_area type wrong. That type of relation was made to group elements relevant to transit data: stops, platforms, entrances, stations. Not to group everything in sight, from footways to shops and information signs.
For your use case, the type of relation is "site": https://wiki.openstreetmap.org/wiki/Relations/Proposed/Site . Using it will make it less likely to be changed because it doesn't fit some software that has certain expectations about stop_areas.
I have modified the relations, because stop_areas should not contain railway tracks. There is nothing on that on the corresponding wiki page, and having tracks in a stop_area makes it very hard to process and validate.
Is it okay if I change type=public_transport + public_transport=stop_area to just type=site for the railway stations?
Ilya
-
Comment from transilien_cartocite
The wiki also says that amenities such as "shelter, bench, bicycle_parking, taxi", are valid in the stop_area relations (https://wiki.openstreetmap.org/wiki/Tag:public_transport%3Dstop_area#Members). This suggests other facilities such as toilets, tickets offices and so on also make sense : they are useful to travelers.
I take your point that using a site relation might be more appropriate to gather all the things we have in railway stations, including footways for some of them. This Proposal (no vote on it so far is it ?) didn't exist at the time and it may well be a good option for us. We need to evaluate what this implies though, in terms of adapting our procedures to use the data.
In the meantime I suggest putting back the stuff into Gare de Lyon (except railways tracks). It is unfortunate you also changed data in Genova in the same changeset, this stops me from doing a revert : I'll put the data back if that's okay for now.
Let's keep in touch for further changes (please use transilien 'at' cartocite.fr).
Cheers,
Antoine. -
Comment from Zverik
Okay, I am reverting the four railway stations I've modified, but also changing the relations' type to "site". I believe you are relying on relation identifiers, so this should not break anything.
-
Comment from transilien_cartocite
Thanks for that. This should be okay however I'll double check. Does that mean you'll produce new stop_area relations forthose stations ?
-
Comment from Zverik
Yes, I have already done that.
-
Comment from transilien_cartocite
Hi Zverik.
I'm coming back to you as it turns out that your change broke several applications in SNCF. We are handling 385 railway stations and migrating them all to Site relations needs to be carefully thought and planned. How urgent is it for you to 'lighten' those stop_area relations ? Do you mind if we revert back your changes for a couple of weeks, which would enable us to check with the community that using Site relations is the way to go. I'm concerned that this proposal has not been voted for, and on the impact on Nominatim : there will be two stations for each station name (ie. searching for "Gare de Lyon" will produce 2 results).
Are you okay if we put back all that "stuff" in the 5 stop_area relations ?
Antoine. -
Comment from Zverik
Sorry, I don't understand your process. Nominatim does not use any relations: it returns only nodes and ways for railway stations. Regardless of relation types, you won't get neither "stop_area", nor "site" from it.
Depending on OpenStreetMap in this way, but storing hundreds of overweight relations and hoping nobody touches them, is a way to failure. If not me, then somebody else would fix these relations. I'd suggest you redo the entire process, untying your system from specific collections and using spatial relationships instead. But of course that takes a lot of time.
Proposals don't have to be voted on to take effect. Wiki in general has a little say over OSM data. Site relations has been used for more than ten years, and now there are half a million of these in the database.
How do you reference these relations from your system? If by identifiers, they have stayed the same. If you download a raw planet data and filter relations based on tags, you'll see a great change over the next few weeks.
But I assume you've been using these special tags like "line:SNCF" and that's what broke your app: I didn't remove these tags from new relations. I've just done it: please check how your applications work now.
I'm against reverting relation types, since it breaks virtually every practical application except yours. But I'm willing to find a solution that benefits both your company, my station parser and OpenStreetMap mapping in general.
Ilya
-
Comment from transilien_cartocite
Hi again.
(The point with Nominatim was not about our process but a general concern with the possible impact.)The stop_area wiki is rather blur on what fits into a stop_area : the table listing the possible members includes amenity=* and gives as examples bench, taxi, parking...
I saw your Metro mapping proposal, which proposes to only keep platform, stop et entrance members. Fair enough, however you went ahead with editing the data without waiting for the vote which is not so fair...We are extracting the data based on the stop_area relations, based on the uic_ref tag (not line:SNCF tag). You claim these relations break "virtually every practical application" expects ours. I'd say the opposite : these relations have been there for a while and broke your station parser when you started to include them. What exactly did they break ? It seems the rails were the initial issue, right ? I propose a compromise : in the short term we only remove the rails from the stop_area relations, which gives us time to work on another solution involving site relations, to extract the rest of the data. What about that ?
Cheers, Antoine. -
Comment from Zverik
Hi,
I've reverted my changes and then removed railway tracks from the five stop_area relations.
There is another issue with these stop_areas: such relation should have only one station node, while four relations have two or more. In that case the common way is to remove these station nodes from a stop_area and create separate stop_area relations, one for each station, adding there objects that are related to that station. Other object can be shared between the relations.
What I mean is, do you need all the station nodes — for subway, RER and others — to be in the same relations for railway stations, or may I remove them into their own relations?
In the meanwhile, please do come up with a solution not relying on grouping every OSM object (even untagged objects — what do you do with these?!) in a relation. An intermediate option using a site relation is okay, but in general cramming all the objects that are linked only by their geographic position is against OpenStreetMap principles: you can do spatial requests using tags and coordinates instead. It is not much harder, but a magnitude easier to maintain.
My email is ilya@zverev.info if you want any tips on working with the data.
Ilya
Relations (4)
Welcome to OpenStreetMap!
OpenStreetMap is a map of the world, created by people like you and free to use under an open license.
Hosting is supported by Fastly, OSMF corporate members, and other partners.
https://openstreetmap.org/copyright | https://openstreetmap.org |
Copyright OpenStreetMap and contributors, under an open license |