[Talk-transit] Public transport workshop in Germany

[Peter Miller]

On 31 May 2009, at 12:45, Sarah Hoffmann wrote:

> Hi,
>
>> Hi!
>>
>> The weekend before last we had a workshop in Karlsruhe, Germany on  
>> the
>> topic of public transport in OSM. The idea was to bring interested
>> people together to improve the modelling of public transport
>> infrastructure and networks in OSM.
>>
>> The results have now been documented. See
>> http://blog.geofabrik.de/?p=23 for details.
>
> While I like the proposal in general, I find that it makes rendering  
> of
> public transport stops a lot more difficult. Currently, the renderer  
> only
> has to put a symbol, where there are 'stop' nodes.
>
> For railway stations it can be sure that there is exactly one symbol
> on the line of the railway neatly aligned to the middle of the way.
> With the new schema a lot of preprocessing and guess work will be
> required to get the same result when stop places contain multiple
> stopping places and/or access points.
>
> The current situation with bus stops is more messy. (Just see
> Birmigham which seems to entirely consist of bus stops.) While
> stop places in the new schema allow to clean this up a bit, again,
> the renderer only has the choice to either paint two many
> symbols (all access points or all stopping points) or badly
> guess where to put the single point.

Which rendering view are you using? for the main Mapnik view on  
openstreetmap there are no bus stops until one zooms in to zoom 17 at  
which point there are certainly lots of bus stops (accesses).

Even at zoom level 17 it may be appropriate to render bus stops at the  
Stop Place level of detail  (with one blob for two Accesses/bus stops  
on either sides of the road, or one blob for three Accesses/bus stands  
in a row on one side of the road).

>
>
>
(snip)
>
> From a rendering point of view I would like to be able to paint them
> as only one point in higher zooms and as two directional points
> in lower zooms. Higher zooms are handled by stop place and stop  
> place group
> relations.

I think that it would be a good idea to adjust the amount of detail  
shown as one zooms in.

Zoomed well out one might see 'Heathrow Airport' as a single point. As  
one zooms in one might see Heathrow Terminal 1 , Terminal 2, Coach  
Station, Underground etc as separate dots. Further in still one would  
see the individual bays in the coach station and individual gates  
within the terminal. Similarly with a bus stop, initially one would  
see one dot for the Stop Place and then when zoomed in see all the  
Accesses  (individual bus stops) and possibly also all the Stopping  
Places (although Stopping Places seem less useful for public use -  
there are more an operational issue)

> Thus, if above example is modelled as two stop places with oneway=yes

> and both stop places are put into a stop place group  
> "Waffenplatzstrasse"
> (together with the two bus stops, which are incidentally directional
> as well) all necessary information for the renderer should be there.
> Is this within the intended use of stop places and stop place groups?
> The Wiki is not very clear on this point.

I agree that a direction does seem to be needed, both for the Stopping  
Places and also possibly for the Accesses. It is not clear how one  
should code the direction - A one-way tag doesn't seem to encode all  
the necessary information.

I would expect that Waffenplatzstrasse would consist of one Stop Place  
with two accesses and two Stopping Places. Is that sufficient or  
should each Access have its own Stop Place and these be grouped into a  
Stop Place Group? If one uses one Stop Place then how are the  
individual Accesses and Stopping Places associated with each other?  
The Accesses need names that indicate direction, such as 'Northbound',  
'towards city centre', 'Sto A', 'Stand A', 'Bay A', Gate 13' etc. In  
the UK this information is encoded in the 'indicator' field and the  
Name for the Access (called Common Name) tends to be shared with the  
other Accesses in the Stop Place.

Just to note at this point that I am concerned that we will run out of  
Stop Place levels as we get into this. IFOPT allows recursive Stop  
Places which is wonderfully general but possibly hard for renders and  
for our relation handling. We may want to revisit this later to allow  
multilevel Stop Places.

>
>
> (NB: For a non-native English speaker, it might be hard to remember
>     which one is the stopping place and which one is the stop place.
> 		 I'd prefer less error-prone terms. Just my two cents.)

I do agree and the terms are also confusing even when read by a native  
English speaker and not very satisfactory!

I did an edit pass on the proposal to integrate some of the IFOPT  
terms as per feedback from Nick/CEN. I am however relaxed about which  
term we choose just as long at the term is choose is not used by IFOPT/ 
Transmodel for something else.

The official IFOPT term for what we are calling stopping place is  
actually 'vehicle stopping place', which is less certainly clearer but  
which is getting rather long. We should possibly use this term of some  
other agreed shorter but clearer term.

Incidentally I didn't use the include the term 'Quay' (for what we are  
calling an 'Access') in the edit pass because it seems an odd term for  
a bus stop or railway platform in English (where it generally refers  
to a ferry access point).

It feels to me that we need a little more time discussing and  
developing this proposal before we start tagging features with it to  
give us more time to refine the ideas.



Regards,



Peter



>
>
> Sarah
>
> _______________________________________________
> Talk-transit mailing list
> Talk-transit at openstreetmap.org
> http://lists.openstreetmap.org/listinfo/talk-transit