Re: [Talk-transit] Public transport workshop in Germany
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 workshop in Germany
On Fri, May 29, 2009 at 08:54:48AM +0100, Roger Slevin wrote: What has not been mentioned specifically in this thread (although I know Peter is very much aware of it) is that there is an approved European Technical Specification (Identification of Fixed Objects in Public Transport - IFOPT) that has built on the experience of NaPTAN and other related work to date, and covers the same ground. A colleague is putting together some comments on how the German work relates to IFOPT. Early indications are that the matching of fundamentals is good (as might be expected - given that NaPTAN was a key input to IFOPT) ... but I hope something on this will be posted here in the next few days. Lets not forget that this is OSM. We do things step by step here with lots of experimentation. Its more about evolving to a good model than creating some complex top-down design. The scheme under discussion is one such step. Its not as complex as IFOPT and probably can't do all that IFOPT can do, but it is reasonably similar to the current OSM model yet more clear and powerful while still beeing understandable. A complex model created by professionals for professionals is sure to fail in OSM. In the long run we can work more and more towards this complex model when the software supporthas improved and we understand better what we want and what we need. But for now we should try to cram everything in. IFOPT seems for instance to allow full recursion on many of its objects which is really hard to handle properly and has, in my opinion, currently no place in OSM. Of course where there are good ideas we should incorporate them. Especially when naming things it makes sense to follow established practices here. Jochen -- Jochen Topf joc...@remote.org http://www.remote.org/jochen/ +49-721-388298 ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Public transport workshop in Germany
Hi Jochen. Jochen Topf wrote: 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. That is great. I did some work in this area by working out the unified_stoparea proposal some months ago. I am really happy there finally seems to be some progress in this area. :) Here are some notes I have after reading (the German version of) your wiki page. I'm writing this before I read responses to this thread, to not get confused. I hope this won't be obsoleted by what others wrote... - the usage tag (and similar tags) Here I would prefer to use hierarchical tagging, so instead of railway=rail; usage=branch I would rather write railway=rail:branch - ref/name tags If you intend this to be filled with information like ref=Line 10 or name=Main station - zoo I would rather see this information with the appropriate route-relations. Things like name=Ringleis which name the actual rail corpus and not the train traveling upon it, are fine with me. - Stadtschnellbahnen (German) It confuses me, that these only consist of subway and monorail. I think the term may cause some confusion. I do not think it is necessary to combine these two and form a group for them. -separate geometry with tram I disagree that this is a good idea. Most attributes belong to both (the road and the tracks within the road). Together they form one entity. Attributes that do not belong to both should use hierarchical tagging scheme, e.g.: railway=tram:disused railway:gauge=100 railway:operator=railcompany highway:operator=citymanagement -concerning the tagging of transport stops. Please have a look at my proposal regarding this: http://wiki.openstreetmap.org/wiki/Proposed_features/unified_stoparea it is very similar to what you propose and is already used by quite some mappers throughout Europe. Please try to build upon it, as you are basically defining something very similar with new tag names. I am not sure if it would be necessary or wise to have everything under the public_transport name space as you propose All in all, I am very happy with this scheme, foremost that someone cares about this. :) I am not sure if the scheme is not to complicated for the casual not-so-concerned mapper. That is why I was trying to change as little as possible with my proposal and allow a wide range of detail levels. The irony is, that I personally rather prefer a complex and complete model to the change-as-little-as-possible approach I finally proposed (I'm German after all ;-) I am eager to see, how your proposal is received by the crowd! Greetings, Gerrit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Public transport workshop in Germany
Jochen Topf wrote: On Fri, May 29, 2009 at 06:07:55AM +0100, Peter Miller wrote: Out of interest where does this leave the following two proposals? Unified StopArea http://wiki.openstreetmap.org/wiki/Proposed_features/unified_stoparea QROTI http://wiki.openstreetmap.org/wiki/QROTI Should we review these other proposals, integrate any appropriate ideas and then politely suggest that people refer to this new proposal for guidance rather than to the other two pages? Would anyone be offended by that? For the time beeing I have put links to those pages into the See also section. Maybe we should ask those people who have worked on those pages to comment. As I mentioned earlier, I am founder and main contributor to the unified_stoparea proposal. Well, I actually _do_ feel a little offended by two things. - First: I am confused at how little reference to my proposal I find in the new scheme. It's not that I am vain or anything, but you copied about anything from that proposal and just gave some items new names. I wonder if you read it and really copied most of it, in which case I would have expected some note about it, or if you came up with that on your own, but than this would show bad research (but still means we both came independently to the same solution(s)). - Second: I tried to rally for a coherent PT-tagging scheme for weeks without end in the beginning of the year (mainly the german list, but also here) with disappointingly little feedback. I wished you (Jochen and his group) would have participated in the process back then. It would have saved me a lot of work and a lot of people that started to use the unified_stoparea-proposal to eventually re-tag all of their work. That said: I really _am_ happy that there is some progress in this field. As you guys have a group (and the geofabrik) behind you, its much more likely to succeed and become wide spread. And I am very interested to have a unified tagging scheme, whatever name it bears. Gerrit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
