[Talk-transit] Documentation issues of PT tagging schemes

Jo winfixit at gmail.com
Thu Jul 26 10:41:10 UTC 2018


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 <winfixit at 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 <emergency99 at 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 😉.
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20180726/93771558/attachment-0001.html>


More information about the Talk-transit mailing list