Hi, I would also be OK with only the stop in the relation (with all tags possible (Way 1) or as Way 2 (see below)) and the other aspects just as additional pieces, however, a bit of redundance could be there to make the platform and relations also human-readable. I know, people dealing with anything IT despise redundancy. But in this case it does not add to confusion, but helps eleviate it. If I have a stop_position called "Hospital" and then a platform that is only referenced in the editor by it's way-number and the fact that it is a platform, then figuring out that these go together is quite tricky, even with a stop-area relation. Sure, when it is in a relation, that argument could be taken down to me being a noob there, but then at least the stop area also needs to have the name, once again adding a needed, not confusing level of redundance.
The way that relations are supposed to work is, that all tags of the relation (at least in case of stop_area and also some buildiing relations) is, that the tags should be inherited by the items contained inside of them. So if we either accept that, or do not accept that, there are two ways of doing it: ________________________________ Way 1: (ignoring the theoretical inheritance of tags): On a node on the road / tracks: * public_transport=stop_position * bus=yes / trolleybus=yes / tram=yes / train=yes * name optional tags: * network * operator (as in the company that actually maintaines the stop (stop-position+platform), which can differ from the line operators) * local_ref * alt_name * uic_name * old_name * note * description On a node, way or polygon/multipoligon on the side of the road/track (as a platform): * public_transport=platform optional/redundant/maybe even discouraged tags: * bus=yes / trolleybus=yes / tram=yes / train=yes, * name / ref * network * note * description Those two elememts (and others of the same station area/complex) then need to be put in a stop_area relation: * public_transport=stop_area * bus=yes &/ trolleybus=yes &/ tram=yes &/ train=yes * name optional tags: * network * old_name * alt_name * uic_name * note * description * wheelchair & wheelchair:description (if you can access the vehicles of the lines with one) ________________________________ Way 2: (using the concept of inheritance): On a node on the road / tracks: * public_transport=stop_position * bus=yes / trolleybus=yes / tram=yes / train=yes optional tags: * name=* (just for the sake of human readability of the raw data / in editors that won't show that inheritance concept) * note * description * wheelchair & wheelchair:description (if you can access the platform with one) On a node, way or polygon/multipoligon on the side of the road/track (as a platform): * public_transport=platform * highway=platform in case that makes sense * area=yes <if that is a polygon> (shouldn't that be implied by highway=platform on polygons anyways)? optional tags: * note * description Those two elememts (and only those two) then need to be put in a stop_area relation: * public_transport=stop_area * bus=yes / trolleybus=yes / tram=yes / train=yes * name optional tags: * network * operator (as in the company that actually maintaines the stop (stop-position+platform), which can differ from the line operators) * local_ref * alt_name * old_name * note * description then, if there are multiple stop_positions & platforms for the same stop-complex, multiple stop_area relations need to belong to a stop_area_group relation: * public_transport=stop_area_group optional tags: * name=* * alt_name * uic_name * old_name * note * description * wheelchair & wheelchair:description (if you can access the complex at all with one) possibly discouraged/redundand tags (they are conceptually reversly inherited from the relation-members): * bus=yes &/ trolleybus=yes &/ tram=yes &/ train=yes * network * operator ________________________________ Way 1 is easier as a concept, but has more redundance, Way 2 is closer to a good database, but more load on the editors. ________________________________ I think it would be time for a think-tank and following proposal of some sort to ammend the p_t:v2 to a "simpler to edit" and "to describe in the wiki", but also "as close to database-concept as possible"-scheme. Kind Regards RobinD (emergency99) PS: Signs I use in the mail: " / " = or " &/ " = and/or PPS: My firstmessage failed to send to the list. So for reference: here is my initial message that only went to Jo: Hello, I have been following the discussion about p_t:v2 and would like to also throw in my point of view. In my opinion, a few things need to change, but some should stay as they are now. 1. I would love to have the highway=bus_stop tag depricated. The whole confusion I think comes from the highway=* and railway=* tags. Those should mostly be dropped in regards to stop positions. 2. The public_transport tags should become the new main attraction. I would leave the stop_position tag. That would go as follows: On a node on the road / tracks: public_transport=stop_position bus=yes / trolleybus=yes / tram=yes / train=yes name=* optional tags: network, local_ref, alt_name, uic_name, note, description... On a node, way or polygon/multipoligon on the side of the road/track (as a platform): public_transport=platform maybe optional: bus=yes / trolleybus=yes / tram=yes / train=yes optional tags: name, network, operator (as in the company that actually maintaines the station, which can differ from the line operators), note, description ... Those two elememts could be put in a stop_area relation, and multiple stop_area relations that belong together in a stop_area_group relation, that can be tagged with: name=* optional tags: network, operator (as explained above), alt_name, uic_name, note, description... Then, the tags like railway=halt and railway=station, which in my opinion are to specific for osm could be removed, making mapping the stops of raillines much easier. (In german, that is the endless discussion whether a trainstop is a station (Bahnhof) or halt (Haltestelle). That is quite unimportant in most cases. If need be, we could map the infrastructure (landuse or building) as a public_transport=station or public_transport=halt instead)). In terms of the route relation, we then could add the stop_area relations to the route relation with a stop role. 3. One problem adressed some time earlier was the great amount of redundance that the route relations add to the database. There was a, not even that bad, though somewhat inpractible sugesstion, to sum up some roads in route part relations, and always when those routes would need to be added to a relation, we add the relation of routes instead. I had a look around vienna and found a few instances, where that would work great, and some, where that would potentially yield the same amount or more entries than in the first place. But that sugestion could also be a possibility at also allowing that, in addition to single roads in a route relation. I hope my description of my idea is understandable. Kind Regards Robin D (emergency99) PS: I mapped all bus-lines in Vienna the way that I think the p_t:v2 scheme is supposed to work (keeping to the wiki as much as it doesn't contradict itself). The problem with the highway=bus_stop tag is, that it is only allowed on nodes. So as soon as the platform becomes "micro-mapped", the bus_stop has to move from the platform to the stop_position, which to me, as a new mapper in 2014, screamed: "That node is the most important part of the whole thing". Which obvously it isn't but tell that to an over-motivated new mapper... So if we could stream-line that scheme more, and finally sunset the bus_stop tag and some of the railway-tags, then the wiki page could be written much simpler, allowing for the newest mappers to understand it. And then, we could give them Vienna, Austria as an example 😉.
_______________________________________________ Talk-transit mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-transit
