[Talk-transit] different interpretations of v2 PT scheme

[Jo]

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
>>>
>>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-transit/attachments/20150701/dab4249a/attachment-0001.html>