Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On 01/22/2011 10:00 PM, Vincent Privat wrote: 2011/1/22 Michał Borsuk michal.bor...@gmail.com mailto:michal.bor...@gmail.com In urban regions it is common that a bus line has different routes for the both directions (often one way). This doesn't matter as OSM itself is not routing software. The more exact the OSM map is, the more likely it is that the two directions do not share the same way for the both directions (the lines of one street are split up). Again, this is not an argument as OSM is not a routing software, but a map. And as a map, we need to make the distinction between different ways, Different directions, you mean? No, we don't. We need unique bus stops in order to know in which direction the bus goes. I agree we can remove the stop_area_group notion, but not this one, this is really a needed map feature, for a very common situation ! Could you please explain what you mean, because I'm not sure. The links provided show bus routes with nothing difficult in particular. They could be mapped as one relation each, only if bus stops are tagged correctly. Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
2011/1/23 Michał Borsuk michal.bor...@gmail.com Could you please explain what you mean, because I'm not sure. The links provided show bus routes with nothing difficult in particular. They could be mapped as one relation each, only if bus stops are tagged correctly. I just want to be sure we can draw in OSM the exact same map as I gave as examples. These examples show distincts ways taken by buses, depending on the direction. If it can be done for these simple lines just with a single relation and stops tagged correctly, it's fine for me. However, I still have doubts concerning this line, which is the most complex in my city: http://tisseo.fr/sites/default/files/Tisseo_hiv16web.pdf I don't see how we can map this without at least 2 relations, where the line splits up in the two directions Sept Deniers and Stade E. Wallon. And about the night extension to the SNCF railway station, I think we'd need a distinct relation as this line is called 16S instead of 16. ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] How routing software works (and why OSM as-is is not ready for routing)
Hello. A few words how data is stored in routing software stores data and works: both HAFAS (specs not officially published) and GOOGLE TRANSIT (http://code.google.com/transit/spec/transit_feed_specification.html) store *not* actual bus, tram, etc. lines, but each departure from the terminus (Google), or any given stop (Hafas). Read me again: actual bus lines are NOT stored in routing software! Lines are displayed to the end user, because as of 21st century, line is a marketing concept. In fact, *very often* a bus (tram, S-Bahn, etc.) line consists of many different traces, or bus lines in the traditional sense. This is presented to the user as bus line XXX, because users are used to it, and frankly it would be totally messy to present it to the final user. So what you see here http://tisseo.fr/sites/default/files/Tisseo_hiv16web.pdf is indeed stored in the database this way: * runs to Sept-Deniers and to Stade Ernest Wallon are saved as separate runs (=relations) * runs in the opposite direction are saved as yet separate runs (so by now we have 4 relations per bus line!) * any exception, such as here Excepté le mercredi and Uniquement le mercredi (Except Wed. and Only on Wed.) are mapped as yet separate relations * initial and final runs that do not start and end respectively at termini are - you guessed it - saved as separate relation. So here we have at least 6 relations, and we're on Monday to Friday schedule only! Add to it Saturdays, Sundays (very often different), all those schoolday-only runs, those Wendesday runs - and it becomes a total mess. What becomes clear here that OSM itself is unable to store such amount of information. Any proper routing software will have to use a *separate* platform, plugin, website, application layer, you name it. It simply makes no sense to attempt to store all the data in OSM framework, because in my opinion *it is not fit* for it. Yes, we could have 8 or 15 relations per line, it is possible, but not sensible. (continued in next post) LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On 01/22/2011 11:04 PM, Richard Fairhurst wrote: Dominik Mahrer (Teddy) wrote: IMHO not related to the proposal: - potlatch can not handle the proposal/nested relations correctly: The latest version of Potlatch (Potlatch 2) handles nested relations excellently. About 10 seconds' research would have told you that. It was me who said it, and I stand by the general comment. While Potlatch 2 may indeed deal with nested relations, the proposed schema is not compatible with it. LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] New proposal to store public transport data
Continuing on How routing software works (and why OSM as-is is not ready for routing): Coming back to the mapping of bus lines in OSM: you can see now that what is presented to the user, as in the example before (the PDF http://tisseo.fr/sites/default/files/Tisseo_hiv16web.pdf), is a cut-and-formed representation a level higher in the abstraction schema above the actual data. It is done for historical reasons, because printed maps did so, and users are used to it. The only reason to implement it in OSM would be historic. Why go backwards? OSM doesn't have many of the limitations of printed maps, but the way it stores data isn't suitable for storing full timetable information. So my proposal is: since we can't provide all the necessary information, why not go even higher towards simplicity at the cost of such details as bus in this street goes one way, and *just* provide the trace of the bus line, with all its variants, as one line on the map? All other info would be provided by routing software. All we need is to point the user to the place where s/he can find actual routing information. Users don't care which way a line goes in the street, but where the bus stops. A pair of unique stop_id tags is all is needed to create a route for the user. Not stop areas, and not the exact bus runs - because we can't store them exactly enough. Here's how I'd store data in OSM: (let's say Simple Public Transport Schema) Level 1: minimum requirement (for beginners, not really encouraged, but allowed). * stops are entered at their actual location (pole = highway=bus_stop, or for railborne vehicles: platforms, optionally poles) * bus lines are entered as a single relation covering all versions/variants, without any roles * relation describing the bus line contains at least the ref=tag Level 2: optimum requirement, will allow routing extension: contains the above, plus: * from= and to= tags are added to the line relation (in order for routing software to be able to match a bus stop with the direction of the bus that stops there) * if there is more than one terminus, we separate them with /, e.g. to=Saint-Denis – Université / Asnières-Gennevilliers-Les Courtilles * stops/platforms are added to the line relation. Note that for the railbolne vehicles, actual platforms must be added to the relation (see below). * stops contain a unique stop_id. All stops with the same name may contain one stop_id (because they are usually stored in routing software as one entry), but must contain backward_stop or forward_stop role on stops or platforms (in order to be able to tell whether the user is waiting at the correct stop/platform, and not its equivalent on the opposite side of the street). * forward_stop is a stop that is on the way from=terminus to to=terminus * network= tag shows which network the line belongs to. * other tags, such as color=, etc. remain unchanged Level 3: advanced features (open for discussion) * relation is part of a mother relation holding all relations within the same network (optional, but encouraged) * operator= tag shall be optional (do users care who drives the bus if the ticketing system is the same all over the network?) * Both Google Transit and HAFAS provide information on pairs of stops that are intended to be transfer points, which was expressed as stop_area in oxomoa, but in my opinion this is not necessary: OSM contains the actual distance between stops, so whether two transfer stops have the same name, or belong to the same stop_area is unimportant. * Amenity=bus_station: I would keep this tag. OSM is a map, and a large bus station differs from a mere pole in the street. Whether Amenity=bus_station contains bus stops or platforms is to be discussed. HOW THIS WOULD BE RENDERED: Same as now, except that öpnvkarte.de wouldn't be able to show one-way routes (this didn't work anyway, when two one-way routes run in opposite direction, as here: http://www.openbusmap.org/?zoom=18lat=49.26833lon=7.10952layers=BT) More on compatibility and routing based on this proposal in next post. Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Compatibility of simple public transport schema with existing practice
Compatibility of the proposal: #Relations: * with two relations per line: merging relations is necessary * with one relation per line: 100% compatibility; if the existing lines contain roles, they would be ignored #Bus stops: * with bus stops: 100% compatibility with existing bus stops which are mapped at the location of the pole; however for future routing purposes all bus stops would have to be added to line relations, and all stops must be updated with backward_stop and forward_stop tag *) * with bus stops placed at the center of the road: change of location and/or tag may be necessary (/this needs to be cleaned up anyway, in another thread it was agreed that stops should be mapped in their actual location/) # Tram/metro/light rail stops * those stops lacking platforms/poles will require updates *) *) upgrades are only necessary if routing software is to be implemented # Amenity=bus_station and stop_area: * to be discussed Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On 23.01.2011 15:01, Michał Borsuk wrote: Any updates from the wiki front? I have started something: http://wiki.openstreetmap.org/wiki/WikiProject_Cleanup/Public_transport I'll need your help with this, so feel free to edit and discuss. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
On Sat, Jan 22, 2011 at 8:32 AM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: - stop_area is not needed/too complicated: According to taginfo there are already 64'500 stop area relations in the OSM database (10'500 public transport/oxomoa, 1'500 stop place, 51'500 unified stoparea). I think you'll find that the bulk of what you ascribe to unified stoparea (which I take to mean type=site relations) are in fact the UK NaPTan import (and not due to mappers). Richard ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
Thanks Michal for your explanations, this is greatly appreciated :) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
