[Talk-transit] Public transport workshop in Germany
Peter Miller
peter.miller at itoworld.com
Mon Jun 1 08:05:30 BST 2009
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
More information about the Talk-transit
mailing list