2015-07-01 7:38 GMT+02:00 Jo winfi...@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
2015-07-01 10:00 GMT+02:00 Éric Gillet gill3t.3ric+...@gmail.com:
2015-07-01 7:38 GMT+02:00 Jo winfi...@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
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
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 winfi...@gmail.com wrote:
2015-07-01 10:00 GMT+02:00 Éric Gillet
2015-07-01 10:53 GMT+02:00 Jo winfi...@gmail.com:
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,
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
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
