If it is any consolation, a lot of time has been spent in the IFOPT group trying to make sure that the terms are clear, unique, well defined, and backwardly compatible with the approved Transmodel standard.
The problem is that there is a finite set of words in the English language that can be used - and, whilst IFOPT terminology may not be ideal in some respects for someone who is coming to this without all of the other constraints of public transport information standards, the terms used in IFOPT have had to respect the constraints. As Peter says, the key is to make sure that any terminology used in OSM is clear and does not conflict with terms already used in Transmodel or IFOPT if the meaning of the term would be different in these different contexts. Roger -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Peter Miller Sent: 01 June 2009 08:06 To: Sarah Hoffmann Cc: [email protected] Subject: Re: [Talk-transit] Public transport workshop in Germany 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 > [email protected] > http://lists.openstreetmap.org/listinfo/talk-transit _______________________________________________ Talk-transit mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-transit _______________________________________________ Talk-transit mailing list [email protected] http://lists.openstreetmap.org/listinfo/talk-transit
