[Talk-transit] different interpretations of v2 PT scheme

Jo winfixit at gmail.com
Thu Jul 2 14:14:13 UTC 2015


Scenario:

I have data from 'upstream'.
This data relates to public_transport=platform nodes next to the way

What I need now, is to figure out which nearby way 'belongs' to this
'platform'.

If there is a stop_area relation, this is easy (as long as there is a
stop_area relation which contains a platform and a stop_position pair).

(Note that there are also stops where several buses can stop one after
another, so it's not impossible to have more than 1 stop_position for a
single platform)

The opposite is also possible, but less likely to be needed.

It is true that there are many cases where the relation between platform
and stop_area can be made unambiguously based on proximity. Note that I'm
doing this in JOSM not in a geographically enabled database.

There are also times that a stop_position is not needed to get from a
platform to the "candidate" way that needs to be added to the route
relation.

Anyway, I wouldn't try to abolish stop_area relations, but rather make sure
that SA relations can be grouped together into stop_area_group relations.
This makes sense for bus stations where the separate stop_area relations
will have names with numbers or letters after them.

Jo

2015-07-02 15:52 GMT+02:00 Janko Mihelić <janjko at gmail.com>:

> If you are adding stop_areas, then there certainly have to be two of them,
> one on each side. One of them is put in the route that goes one way, the
> other one is put in the other way. I'm also pretty sure that the
> stop_area_group is not needed. If they are near each other, then it's a
> group. But to someone "near each other" means within 400m, to someone in a
> wheelchair it means ramps, to a blind person it means traffic lights with
> sound. What else can a group achieve that spatial placement can't? Maybe if
> a group has a ref.
>
> After all this, I'm not sure that stop_area is absolutely necessary.
> Stop_position and platform are nearby, so there is really not that much
> chance an algorithm is going to connect the wrong ones. If it was me, I
> would just add all the refs to the platform, like you did, and ignore all
> the refs on the stop_position. Job done, no relations needed.
>
> čet, 2. srp 2015. u 00:54 Jo <winfixit at gmail.com> napisao je:
>
>> I tend to add the waste_basket that clearly 'belongs' to the bus stop,
>> the bench, the shelter, the ticker/departures screen in as well. Most of
>> the time they have a style you don't see elsewhere. Never occurred to me to
>> add toilets or flowers or pubs though.
>>
>> But do we agree a stop_area relation is needed for each side of a street?
>> and a stop_area_group to show that they belong together?
>>
>> Jo
>>
>>
>>
>> 2015-07-02 0:31 GMT+02:00 Janko Mihelić <janjko at gmail.com>:
>>
>>> To me it's logical to put all those ref, network and operator tags in
>>> the stop_area relation, not on the nodes or ways. The relation is the only
>>> element that describes the bus stop completely. If you only put the ref and
>>> operator on the platform, the stop position is missing.
>>>
>>> But if mappers in a city agree that they don't need stop_area relations,
>>> they can put ref and operator tags on platforms, or stop_areas. I think
>>> this can be reasonably flexible, but only between networks, or countries.
>>>
>>> Also, putting waste_baskets, benches, flowers, toilets, cafes and other
>>> things in the stop area relation is unnecessary. Who decides if a cafe is
>>> near enough to be in a stop_area? What do they have to do with public
>>> transport? Only the stop_position and platform are needed. But I'm not
>>> going to remove those from a stop_area relation, they don't hurt.
>>>
>>> sri, 1. srp 2015. u 13:55 Jo <winfixit at gmail.com> napisao je:
>>>
>>>> What I'm doing comes down to mapping the poles. stop_positions could be
>>>> shared for stops that are exactly across one another.
>>>>
>>>> I guess there is no choice but to rewrite the script(s) in order to
>>>> cope with all variations of possible ways to map. Or else simply give up on
>>>> it and move on. Not sure which I will choose.
>>>>
>>>> It would be nicer if we were able to come up with a totally consistent
>>>> version 3 of mapping PT, but what I see, is we're moving in different
>>>> directions. What is logical to me, apparently isn't for the rest of the
>>>> world. What I do know is that I'm not going to be spending the next 2 years
>>>> to make sure all the stop_positions (50000 for a small country) are
>>>> present. They're simply not important enough for that. I add them here and
>>>> there and consistently for the terminal stops.
>>>>
>>>> What I want to focus on at the moment is to get all the itineraries in
>>>> , the routes and their variations. To me that seems like a better use of my
>>>> time.
>>>>
>>>> Polyglot
>>>>
>>>> 2015-07-01 11:59 GMT+02:00 Jo <winfixit at gmail.com>:
>>>>
>>>>> I am the mapper. I use the processing to assist me, like a tool. I
>>>>> also try to map them all in the same way for consistency. The problem is
>>>>> that apparently there was still room for interpretation in the 'version 2'
>>>>> of the public transport scheme.
>>>>>
>>>>> What I see happening in Germany is that information is duplicated
>>>>> needlessly. Moving it to the stop_area relation would be a logical step,
>>>>> but information doesn't cascade through like that in OSM. In Belgium every
>>>>> stop has its own ref, and of course if you calculate a route_ref from the
>>>>> schedules this will not always yield the same result for both sides of a
>>>>> street.
>>>>>
>>>>> Jo
>>>>>
>>>>>
>>>>>
>>>>> 2015-07-01 11:43 GMT+02:00 Richard Mann <
>>>>> richard.mann.westoxford at gmail.com>:
>>>>>
>>>>>> Your processing needs to be able to cope with these situations, using
>>>>>> the latlon of the features, if the relationships aren't explicit. Get the
>>>>>> computer to do the work, not the mappers.
>>>>>>
>>>>>> Richard
>>>>>>
>>>>>> On Wed, Jul 1, 2015 at 9:53 AM, Jo <winfixit at gmail.com> wrote:
>>>>>>
>>>>>>> 2015-07-01 10:00 GMT+02:00 Éric Gillet <gill3t.3ric+osm at gmail.com>:
>>>>>>>
>>>>>>>> 2015-07-01 7:38 GMT+02:00 Jo <winfixit at gmail.com>:
>>>>>>>>>
>>>>>>>>> In retrospect public_transport=platform was a misnomer. Maybe we
>>>>>>>>> should have used public_transport=pole.
>>>>>>>>>
>>>>>>>> A platform can be a pole, or a shelter, or a dock, or a boarding
>>>>>>>> "platform" for a train... It is meant to abstract differences between
>>>>>>>> different means of transport.
>>>>>>>>
>>>>>>>
>>>>>>> That's why I tought I was doing all right putting the details of the
>>>>>>> stop on those public_transport=platform mapped as nodes. When there is an
>>>>>>> actual platform, I map it separately as a way or an area, which goes into
>>>>>>> the stop_area relation.
>>>>>>>
>>>>>>>>
>>>>>>>> Anyway, the attempt to clear up the distinction between mapping
>>>>>>>>> stops next to the road and as a node on the road has failed utterly, now
>>>>>>>>> all seems to be done twice, which is a total waste of time.
>>>>>>>>>
>>>>>>>> The stop_position is where the bus, train, etc. stop on their way,
>>>>>>>> while the platform is where passengers will be waiting to board. Both
>>>>>>>> features are distinct and serve different purposes in real life, so why not
>>>>>>>> store both in OSM ?
>>>>>>>>
>>>>>>>
>>>>>>> I don't mind having both. I do mind putting extra tags like name,
>>>>>>> ref, operator, network, route_ref, zone on the stop_position nodes. It's
>>>>>>> enough to have that information once.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> My problem is that when I'm adding stops as nodes in Germany and
>>>>>>>>> put the details on there, those nodes get cleared/removed. I can reinstate
>>>>>>>>> them, but it won't stick, so it's futile to do so.
>>>>>>>>>
>>>>>>>> It seems to be more a problem with toxic mappers more than the PT
>>>>>>>> scheme
>>>>>>>>
>>>>>>>
>>>>>>> They moved the details to the stop_position, which I don't consider
>>>>>>> for processing.
>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>>> At some point I thought that starting to include the platform ways
>>>>>>>>> to the background database would help, but that's not the case if the
>>>>>>>>> details are mapped on the stop_position nodes.
>>>>>>>>>
>>>>>>>> In theory, "redundant" details on the same stop should be put in
>>>>>>>> the stop_area relation in order to reduce redundancy.
>>>>>>>>
>>>>>>>
>>>>>>> That only works if there is one stop_area relation per direction of
>>>>>>> travel. At the moment the wiki states to use a stop_area relation for all
>>>>>>> PT related stuff that is near to each other. I need to relate the platform
>>>>>>> nodes to the nearby way, sometimes by means of a stop_position node,
>>>>>>> sometimes with help of a stop_area relation.
>>>>>>>
>>>>>>>>
>>>>>>>> The stop_area relations combine both directions, That's useless. I
>>>>>>>>> don't know who abolished stop_area_group, But what good are these stop_area
>>>>>>>>> relations if they don't help to relate an individual platform with a
>>>>>>>>> stop_position?
>>>>>>>>>
>>>>>>>> See above.
>>>>>>>>
>>>>>>>> Éric
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Talk-transit mailing list
>>>>>>>> Talk-transit at openstreetmap.org
>>>>>>>> https://lists.openstreetmap.org/listinfo/talk-transit
>>>>>>>>
>>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Talk-transit mailing list
>>>>>>> Talk-transit at openstreetmap.org
>>>>>>> https://lists.openstreetmap.org/listinfo/talk-transit
>>>>>>>
>>>>>>>
>>>>>>
>>>>>
>>>> _______________________________________________
>>>> Talk-transit mailing list
>>>> Talk-transit at openstreetmap.org
>>>> https://lists.openstreetmap.org/listinfo/talk-transit
>>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20150702/c5974074/attachment-0001.html>


More information about the Talk-transit mailing list