oh, in case stop_area relations are added, it makes sense to duplicate the name of the stop on them.
Op do 26 jul. 2018 om 12:38 schreef Jo <winfi...@gmail.com>: > 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 <emergenc...@outlook.com > >: > >> 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 Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit