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ć <[email protected]>:

> 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 <[email protected]> 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 <[email protected]>:
>>
>>> 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 <
>>> [email protected]>:
>>>
>>>> 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 <[email protected]> wrote:
>>>>
>>>>> 2015-07-01 10:00 GMT+02:00 Éric Gillet <[email protected]>:
>>>>>
>>>>>> 2015-07-01 7:38 GMT+02:00 Jo <[email protected]>:
>>>>>>>
>>>>>>> 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
>>>>>> [email protected]
>>>>>> https://lists.openstreetmap.org/listinfo/talk-transit
>>>>>>
>>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Talk-transit mailing list
>>>>> [email protected]
>>>>> https://lists.openstreetmap.org/listinfo/talk-transit
>>>>>
>>>>>
>>>>
>>>
>> _______________________________________________
>> Talk-transit mailing list
>> [email protected]
>> https://lists.openstreetmap.org/listinfo/talk-transit
>>
>
_______________________________________________
Talk-transit mailing list
[email protected]
https://lists.openstreetmap.org/listinfo/talk-transit

Reply via email to