date:20090602

Re: [Talk-transit] Public transport workshop in Germany

2009-06-02 Thread Peter Miller


On 1 Jun 2009, at 23:09, Sarah Hoffmann wrote:

 On Mon, Jun 01, 2009 at 08:05:30AM +0100, Peter Miller wrote:
 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).

 Yes, I had Mapnik in mind although the problem is a more general one.
 There are no bus stops for lower zoom level because they would
 completely clutter any map.

 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).

 Rendering the Stop Place is only useful, if there is additional  
 information
 available, e.g. the name. But how this can be displayed without
 overwhelming the user is an unsolved problem indeed. However, I was
 hoping of resolving the rendering of the lower zooms first.

A Stop Place should have a name - I believe that is part of the  
definition of a Stop Place that it does have a recognised name.  
However it may sometimes just be appropriate to to put a single dot on  
the map for a Stop Place without a name and will be less cluttered  
that every Access.



 Actually, looking at Birmingham in the ÖPNVKarte

 http://www.öpnvkarte.de/?lat=52.47884lon=-1.89495zoom=17

 I see that all bus stops in the inner city belong to the same
 stop place, namely city center. I know that this is very common in
 the UK (and very frustrating for the visitor, but that's another  
 story).
 How would you fit that into the proposed model? A stopping place and
 access point for each bus_stop and then all of them into one stop  
 place
 relation? Subdivide them by street? How do the regular users see them,
 as single bus stops or as quais of one and the same stop?

To be clear. Birmingham City Centre is too big to be a Stop Place  
(where all points should be within a few minutes walk from each  
other). 'Birmingham City Centre' is actually a locality name in  
NaPTAN. Localities are used for named settlements or suburbs. Some  
authorities create a locality for the centre of large places.


 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.

 This would be more a directional information that encodes in which
 direction the vehicle will continue its journey from the stopping
 point. This would indeed suffice. Unfortunately, it brings us back to
 the still unresolved question of forward/backward tagging, which
 seems to go nowhere.

In NaPTAN the Accesses (bus stops) have a bearing N, NE, E etc, in  
which the vehicle leaves the stop. Slightly tricky to interpret with  
the mapping data, but the NaPTAN dataset if road dataset neutral so  
can't reference any particular road data set (OS, OSM, Navteq).


 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.

 Do you mean stopping place here? I'd expect this indicator to be  
 unique
 for all accesses in a stop place.

It is good practice (that is not always followed or appropriate) for  
all Acesses

Re: [Talk-transit] Public transport schema

2009-06-02 Thread Peter Miller

On 2 Jun 2009, at 18:18, Thomas Wood wrote:

2009/6/2 Sebastian Schwarz y...@kahlfrost.de:
Hi!

Well, I have been en-route the last days and thus did not have time
to
respond to any of the numerous mails covering almost all aspects of
the new proposal relating to public transport. But I see the
discussion sort of loosing sight of the mappers. From my point of
view, we should find a good compromise which primarily serves the
mappers and not the CEN. So, the schema should not be as compliant as
possible to the standards but as good as possible for the mappers -
provided with a reasonable part of standard compliance, of course. We
do not want to model Heathrow Airport (apart from that, airports have
never been part of the proposal!) but we want to start with the bus
station around the corner!

But by it's nature as the foundation of how transportation stop areas
are represented in OSM, then airports are important as a higher tier
of transportation. By their nature, they'll often have several other
modes of transport related to them, metro, mainline rail, bus and
coach services, and they should still be seen by routing software as
an interchange that could be possibly used.

In time, we will want to map them in excessive detail, whilst we have
the opportunity, this scheme should allow the scope for further
expansion of other transportation types.

Firstly, can I say again how much your proposal is appreciated. We
have needed to do a thorough review of PT related tagging for
consistency for some time and your work is a great starting point.

Secondly, can I apologise for tearing into you document and I hope we
haven't ruined you thesis but from a Wikipedia perspective this is how
good articles get written. People build something, others build on it,
some changes stick, some get challenged and removed, but the general
direction is positive. Your work certainly isn't going to gather dust
on some shelf but will be used with a vengeance very soon - I just
want to make sure that we do the design work at this stage to ensure
that it is robust before it gets extensively used.

With reference to mappers, I really don't think we are making things
much harder for the average mapper are we? Once we agree on terms and
definitions that is. We have rationalised platforms and bus stops and
ferry quays into Accesses. We have renamed Stop Areas as Stop Places.
We have added Stopping Places and Stop Place Groups. We are proposing
a new relation binding from Accesses to Stopping Places. I am
proposing that we added Entrances and Boarding Points, but all these
are optional extras to the modelling and not something that the
average mapper needs to touch to start with.

Regarding Heathrow Airport. The coach/bus station within the airport
is the busiest in the UK
(http://www.milesfaster.co.uk/information/heathrow-airport/heathrow-central-bus-coach-station.htm

) and we will of course map transport interchanges in absurd detail
when we run out of other things to do!

CEN: My experience is that one has to be careful when one doesn't
follow standards or ignores them; the old rule, 'if you can't be good
be careful' comes to mind. For sure, there is some nonsense in
standards for geopolitical reasons, but transmodel is pretty clean and
so is IFOPT. If you cut corners in relation to a CEN standard you can
expect to come unstuck in some situation that you hadn't considered
and then you will have to bodge it. For example by assuming that each
stopping place has only one Access and one Access is only associated
with one Stopping Place. I know that because I have been there and
done it!

What we have already is very good - we are not slavishly following
CEN, but as far as I am concerned we follow it where appropriate and
are now aware of the places where we are not following it and we are
confident that we are doing it for a good reason and that it will
work. The only section that has not been reviewed in relation to CEN
is the section about Railway Routes, Railway Lines and Line Variants
which again is close but we can still learn from CEN and clarify the
language.

Ok... Um Well... So I have now just looked at the current
version of the document and noticed that you have reverted just about
all my changes over the past few days. I find that rather unnecessary
and I would like to have some clarification about why that was
necessary or useful to do that without consultation. For sure some
changes could be challenged, but all of them? No one else had
challenged them on the list on the wiki since Saturday. Fyi, Here is
the difference between the version just before I made my first changes
and the current version (they are basically the same).
http://wiki.openstreetmap.org/index.php?title=User:Oxomoa/Public_transport_schemadiff=280182oldid=278379

1 2 >

1 - 100 of 155 matches

Mail list logo