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.47884&lon=-1.89495&zoom=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 within a Stop Place to have the same name, but to all have unique indicators. I would encourage us to adopt this approach. > > > What is the relation between accesses and stopping places? There is an > example in the proposal of a stopping place having multiple accesses. > Can one access also be used for multiple stopping places? I would suggest that where one creates an Access but no Stopping Place that the system (or some tool) guesses that a Stopping Place on the nearest highway/Railway is required and that they should be connected with a relation. Where one Stopping Place is served by two Accesses or where a single Access serves two Stopping Places or where there is ambiguity about which highway a vehicle might stop on then we will need to create the Stopping Places and relations manually. > > >> 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. > > As a programmer I love the idea of recursion, as a mapper I find it > awful. We should find something simpler. Ummm. I agree with your sentiments, but not necessarily with you optimism! We could try Heathrow Airport as a worst case mapping challenge. (one of the busiest air ports in the world). > > >> 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. > > Tagging small test patches in different countries might help uncover > weaknesses, we cannot see in a theoretical discussion. Absolutely, but lets settle the tag names issue before doing that. I would also like us to consider separating Access from Entrance and use different tag names as per CEN feedback. Does anyone object Also including an option for Access Areas and Boarding Points to complete the model mapping to CEN. There are some outstanding suggestions about the use of route (tagging ways or tagging relations) which we need to bottom. Also, I feel the Line Variant element could do with a little review which I will do unless anyone objects. Regards, Peter > > > Sarah _______________________________________________ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
