Way 0: node next to highway/railway hw=bus_stop/rw=tram_stop pt=plaform bus=yes tram=yes name ref operator network
IF there is a platform: way or area with: hw=platform and/or rw=platform optionally pt=platform optionally tactile_paving= optionally wheelchair= nothing else (details are on platform node) IF you like: node as part of highway/railway pt=stop_position bus=yes tram=yes other_modes_of_transport= nothing else (details are on platform node) At the start or end of the itinerary (route relation) split on this node and only keep the part of the way in the route relation that connects to the rest of the itinerary. Of course it's possible to add: amenity=shelter/shelter_type=public_transport bench=yes waste_basket=yes etc. as separate objects This way of mapping is highly continuous between the original way and what was proposed in 2011. If done right, everything hinges on the platform nodes, which are the main representation of the stops, both for indicating where they are on the map (rendering) as for using them in the route relations. Things I don't see as unnecessary redundancy: on these platform nodes: bin=yes shelter=yes bench=yes even when they are also mapped as separate objects and route_ref=1;2;E;128A Even if thisi can be deduced from membership of route relations. All of the last ones could be used for validation. (PT_Assistant now checks for correspondence of route_ref with ref tags in route relations and warns if they are different, only if route_ref is present, obviously) This is about as simple as it gets. Or could be. Polyglot Op do 26 jul. 2018 om 11:31 schreef DC Viennablog <[email protected]>: > 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
