Re: [Talk-transit] Summary of Public Transport Proposal Criticism - a real example from Zürich
Am 10.02.2011 19:50, schrieb Michael von Glasow: What I am certain of is that OSM can represent public transport routes, possibly with some concessions on precision (such as not handling some route variants). Yes and no. That is, to some extent: in cities perhaps all the main lines, but not all. Not even 90% with difficult concessions. The present trend (at least in the places in Europe I've analyzed) is that line is a collection of runs, not a single path from a to b. The line itself is more and more often obscured from the user, because modern routing software (namely HAFAS in Germany) allows such management. You will not find a list of routes on the website of my transport company. All that is available is a map, but with very simplified route display. Granted, I don't live in a typical city, it's an urban nightmare, neither dense city, nor a village, rather a spread suburb, but it's not unique in Europe, and very usual in North America. Bottom line: the concept of line as known is disappearing in many places. Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On 02/02/2011 02:42 PM, Jo wrote: Is it possible to add a way to a relation twice with Potlatch? Out of 80 lines I manage, I have such a situation once (not a way, but a bus stop, actually). Is it an issue in your area? 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 - a real example from Zürich
On 01/27/2011 07:20 AM, Dominik Mahrer (Teddy) wrote: On 01/26/2011 08:40 PM, Michał Borsuk wrote: The bus service number 10 in Wintherthur is the most simple case you can have. Absolutely no exceptions. See timetables of the two terminal stations: So there is yet another line 10 mixed at the same index. Interesting approach taken at HaCon, indeed. Line 10 Zürich: line# relation# # of runs 10 120 56 10 121 12 10 122 12 10 123 1 10 124 50 10 125 6 10 126 1 Interesting! Indeed. How do you imagine to build routing using present, or proposed, data structures? And where do they start and end? That's beyond my point, which was to show that complication of data structures in OSM is unnecessary, because even at the level you are proposing, adding routing information won't be possible. And again: Why can't you accept, that others want to map something more in detail then you do? I don't ever remember expressing how I would like to map, because I am not speaking about my personal preferences (unlike many people here), but about what in my opinion is good for the OSM and its future. I do not understand why so many people want to turn OSM into their personal playground, and do not think about new users, for whom learning curve is important. Let's just get down to differences, I say your proposal is too difficult. I've already spoken well about its data integrity, but new users don't care about it. We need something that is as good as yours in data integrity, and as easy to grasp as my proposals. Teddych 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 - a real example from Zürich
On 01/27/2011 06:56 PM, ant wrote: Hi, On 27.01.2011 10:49, Richard Mann wrote: Thanks, Richard. I think we've got three broad decisions: 1) Whether the use of stop area / group relations should be a) widespread b) exceptional b b, ideally with a definition to what cases those exceptions are. 2) Whether route relations should a) contain all the variants in one relation, with no attempt at ordering, just stops identified as forward/backward b) try to match all the individual stop-sets that you might find in a timetable c) contain an ordered set of ways/stops, in whatever fashion the mapper feels appropriate b (by the way: how would (a) work in the case of a ring line?) a or b For ring or spoon-shaped lines, select an arbitrary terminus/termini. IMHO It's easier to do an exception for the occasional ring line, than enforce more difficult data structures on mappers (although I personally dislike roles, and would love to see them improved). 3) Whether there should be a new public_transport key, to try to clarify the bus_stop/tram_stop distinction a) aim to move tram_stops to alongside the track, and put something else (tram_stop_group / tram_station?) on the track b) aim to move bus_stops onto the road, and put something else (platform?) alongside c) encourage the use of platforms on tram systems, and use those in the relation instead of tram_stop d) add a new public_transport key, so that public_transport=platform can be used for everything c and d (we shouldn't redefine tags that are in million-times use!) c. with pole *or* platform. Ideally there would be some degree of compatibility between tram stops and bus stops, i.e. a pair of tags on each side that are at least compatible to a degree. cheers ant Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On 01/28/2011 02:45 PM, Jo wrote: Yes that's one option. I'm a bit reluctant to put in separate relations for each direction unless someone actually gives me a compelling reason to do so. I already have some ways with more than 20 relations, and I don't really want to double that number without good reason. http://www.openstreetmap.org/?lat=50.85106lon=4.75651zoom=17layers=M http://www.openstreetmap.org/?lat=50.85106lon=4.75651zoom=17layers=M Lijn 7 uses Krijkelberg twice. Bus stop Sint-Kamillus is served by both directions. This can be mapped without ambiguity if there is one relation for each direction. Do we need such level of details if we can't present it to the user at present? http://www.openstreetmap.org/?lat=50.881607lon=4.715zoom=18layers=M http://www.openstreetmap.org/?lat=50.881607lon=4.715zoom=18layers=M Bus station in Leuven. It's perfectly clear where the buses will travel. Not so if both directions are in only one relation. Is the improvement worth the extra time? Sure it would be possible to program something to process a 1 route relation, but it would not be straightforward. Such situations are quite exceptional. I would know, because I've mapped a mixed urban-suburban area, where some lines are the perfect A-to-B straight lines, and some are pretty crazy (spoon shape is the least strange of all). So: how about two relations per line are to be optional in cases where one relation does not successfully explain the route? Most importantly though, with one route relation per direction, it's a whole lot easier for the mappers to check that the relation is continuous. At the cost of extra time to enter and maintain, and confusion (it's not how it is on printed maps!). I've managed to check continuity with one route, and if you're worried about continuity in the aspect of future routing, then it's irrelevant - routing software does not follow the route itself, but its bus stops. I am a die-hard opponent of relation-per-direction, but please convince me that it is really worth it. As far as routes go that have a shorter itinerary during the week, I wouldn't make an extra sets of relations for those. Simply put the longest road traveled in both relations. Sure, that's the way to go, but what is your proposal for routes with different paths? I have at least 2 such routes, each has 4 variants. I have so far mapped them as one relation, but this is suboptimal. Four relations are not much better, and if I were to apply one relation per direction, I'd have eight. That's an overkill. Jo 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 - a real example from Zürich
Am 25.01.2011 13:52, schrieb Dominik Mahrer (Teddy): On 01/25/2011 12:01 AM, Michał Borsuk wrote: So far, so good. Let's then take a tram line, I selected a *random* stop in the centre of Zürich, and *randomly* took tram line 10. Here's the list of routes and their conditions: ... This single line contains *23* different routes! Twenty-three routes are hidden under one tram line. Now even if we ignore the routes on which the tram runs 1, 2 or 3 times a day, then we still have *nine* routes (nbr_or_runs: 56,50,12,12,5×6). I don't know where you got these 23 routes. Here's an excerpt from the ZVV timetable for Bus 210, uptown Zürich The name ZVV doesn't ring a bell? It's Zürcher Verkehrsverbund. And the data come from this: http://www.zvv.ch/en/timetables/online-timetable.html 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
Am 24.01.2011 10:00, schrieb Dominik Mahrer (Teddy): 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. Thanks for clarification of facts. But then I do not understand what part of the proposal is not compatible with potlatch... I'll do that 10 second research. Will be back with the info. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Summary of Public Transport Proposal Criticism
Am 24.01.2011 10:39, schrieb Dominik Mahrer (Teddy): On 01/24/2011 10:10 AM, Michał Borsuk wrote: As far as I understand the issue, stop areas are used to tie different stops into one transferring area. No, you did not understand correct. stop_area_group is (was?) for that. Then what is the exact difference between public_transport=stop_area and amenity=bus_station (or equivalent for other vehicle types)? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ 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/24/2011 12:40 PM, Christian wrote: On 23.01.2011 13:18, Michał Borsuk wrote: No, this can't be done in such detail, but it's not necessary as of 2011. All you need to know is where is the bus stop for the direction you're interested in, or whether the bus stop you found serves you correctly. All the rest is done by the routing software. [...] I'm sorry, but saying it is not necessary seems very arrogant to me. Maybe it is not necessary for what you want to use OSM for, but that doesn't mean that we can't use it for something else. Last time I checked, OSM was open and everybody was able to map whatever they wanted. Not at all. Nowhere it is written that anarchy is encouraged. If it were, I would have already applied what *I* think is proper, instead of finding a common solution. If disagree then please attack my arguments with counter-arguments. I stand by what I wrote. Thinking about the 100+ messages about this topic, this might actually be the reason for the problems in finding a good proposal. You have an idea of what you want to do with the data and you think that everybody else wants to do the same stuff. That's not the case! I am aware of this. Sometimes the minority is correct. People will want to use the data in different ways and that is fine, so what we need is a public transport proposal that allows everybody to map whatever they want to map. That includes people like you who only want the bus stops, but it also includes people like Vincent or me who would like to map also physical path a bus takes on the street. My proposal does cover that. A simple bus line will be mapped as it was before, with the minor exception that the route will not contain the direction (you don't need that as a user) - but the stops will. 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/24/2011 02:09 PM, Richard Mann wrote: On Mon, Jan 24, 2011 at 11:40 AM, Christianchrist...@balticfinance.com wrote: but it also includes people ... who would like to map also physical path a bus takes on the street. I think there's a logic in encouraging the use of ordered relations to show the paths of bus/etc routes - because this makes the data more browsable/maintainable. Nobody denies that. The problem since the beginning is the cost, i.e. the amount of time needed to implement and maintain this solution. LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] New proposal to store public transport data
On 01/24/2011 03:04 PM, Oleksandr Vlasov wrote: Michał Borsukmichal.borsukat gmail.com writes: Just a small set of questions: 1. As I can see, currently stop-on-a-way is the preferred approach for mapping tram stops. Do you propose to map tram stops like bus ones, i.e. beside the way? I'd propose a platform, or a pole, or another object, on each side. There have been calls that it is useful for the visually impaired, and I'd add to it total strangers. One name for a bus stop/tram stop is not unique, and if you're in a totally unknown place, you don't know on which platform to wait. That makes sense, but will probably require massive change in currently mapped objects. Everything slowly. The proposal does not break compatibility. Lack of platforms/poles merely means lack of future routing capabilities. 2. Withdrawing stop_areas and stop_area_groups is OK if the routing software can route walking person from one stop to another. I'm not sure this is the case now -- there's no established approach to the footways/sidewalks mapping (please correct me if I'm wrong). Still, it's possible to rely on stations' proximity Exactly. Stop_area_groups come from Knoten in the German HAFAS, or transfer points in Google Transit, a very old concept in computer age, when programs didn't have the exact location of bus stops. 3. bus_stop already defines `ref' tag, will proposed `stop_id' be something different? ref= on a bus stop? That's news to me (sadly). I used stop_id=, but the mess probably comes from the fact that there's mess in the documentation. Hopefully that can be changed easily in JOSM. Anyway, unique ID is necessary for good routing schema, i.e. such that points the user to the exact pole/platform. I hate to see the tram leave the opposite platform. Regards, Also, 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 - a real example from Zürich
On 01/24/2011 10:16 AM, Dominik Mahrer (Teddy) wrote: On 01/22/2011 08:38 PM, Michał Borsuk wrote: On 01/22/2011 09:32 AM, Dominik Mahrer (Teddy) wrote: 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. Exactly, OSM is a map. And on a map I want to be able to read the route of a public transport service. We've exchanged arguments in this field before, let me present an actual example from your area that shows the level of complication of modern-day timetables (and Zürich actually is still quite traditional in that matter): Here's an excerpt from the ZVV timetable for Bus 210, uptown Zürich: line_nbr,route 201,557 201,558 Bus 210 consists of two routes, 557 and 558. Sounds easy, doesn't it? Route 557 would be mapped in OSM as route in one direction, and route 558 as the opposite. Indeed, it is so: route,stop_name 557,Uitikon, Wängi 557,Uitikon, Gläseren 557,Uitikon, Roracher 557,Uitikon, Dorf 557,Uitikon, Halde 557,Uitikon Waldegg, Post 557,Uitikon Waldegg, Neuhaus 557,Ringlikon, Langwis 557,Ringlikon, Dorf 557,Ringlikon, Sonnhalde 557,Uitikon Waldegg, Bahnhof ...and... 558,Uitikon Waldegg, Bahnhof 558,Uitikon Waldegg, Neuhaus 558,Uitikon Waldegg, Post 558,Uitikon, Halde 558,Uitikon, Dorf 558,Uitikon, Roracher 558,Uitikon, Gläseren 558,Uitikon, Wängi So far, so good. Let's then take a tram line, I selected a *random* stop in the centre of Zürich, and *randomly* took tram line 10. Here's the list of routes and their conditions: line_nbr,route,nbr_or_runs 10,120,56 10,124,50 10,121,12 10,122,12 10,125,6 10,407,6 10,410,6 10,413,6 10,417,6 10,411,3 10,412,3 10,414,3 10,415,3 10,418,3 10,420,3 10,702,2 10,703,2 10,123,1 10,126,1 10,408,1 10,409,1 10,416,1 10,419,1 This single line contains *23* different routes! Twenty-three routes are hidden under one tram line. Now even if we ignore the routes on which the tram runs 1, 2 or 3 times a day, then we still have *nine* routes (nbr_or_runs: 56,50,12,12,5×6). Surely not all of them have different paths, but I guess some do. And that's just for a random line in a big city. Now take a small city: 300 thousand people spread over big area. Bus lines around me that normally consist of several relations. Most of those can be ignored, they are very early morning routes, or they follow the same path, but many do not, they are simply very different variations, 4 different paths per direction is nothing unusual over here, detours for school runs are neither (more paths!). My intention is to show to you all that times of tram/bus lines where the vehicle started at point A, drove to point B, and so throughout the day are slowly over. You won't be able to map your favourite line on OSM, unless it's as simple as the bus 201 shown above. And then what do we do with the more complicated lines? We're supposed to make a standard that would accommodate many different PT systems. So again, my suggestion is to map all variants in both direction as one relation, because we can't show the desired level of details anyway, and leave the rest to the routing layer/software/website, whatever. It is perfectly possible to combine then real timetable data with OSM, to create a multicolour maps and other eye candy. 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
On 01/25/2011 12:19 AM, Michał Borsuk wrote: On 01/24/2011 11:38 PM, Christian Krützfeldt wrote: If disagree then please attack my arguments with counter-arguments. I stand by what I wrote. Well, I could agree with you that your proposal is fine for most usage cases. But below you say it yourself, the direction is lost, so for all those usage cases where people would like the direction your proposal isn't working. Graphically lost, so no arrows (that didn't work anyway, because there are streets in which bus A runs one-way north, bus B runs one-way south, and openbusmap.org could not render this). This is what I mean http://www.openbusmap.org/?lat=49.26791lon=7.10739zoom=16layers=BT http://www.openbusmap.org/?lat=49.24427lon=7.14187zoom=17layers=BT Buses 521, 522, and 525,526 respectively, each run in one direction, but the opposite one, and openbusmap.org is lost. 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
On 01/24/2011 11:22 AM, Dominik Mahrer (Teddy) wrote: By the way, I have removed stop_area_group from the proposal. In essence this is good. I tried to implement this concept in OSM, but could not find (come up with) a sensible standard. Then what is the exact difference between public_transport=stop_area and amenity=bus_station (or equivalent for other vehicle types)? public_transport=station is an area usually dedicated to public transport [...] public_transport=stop_area contains all the attributes that are shared by all the primitives (reference, operator, network, ...). I do see this advantage here, but again, this is something demanding for humans that is not required by routing software. And frankly I do not see such an improvement in data consistency over amenity=bus_station (or equivalents for other vehicles). Rather I'd see questions to which is which. Smaller stop areas could be left as poles/platforms, larger ones naturally constitute a type structure. Perhaps the name bus station does not have to be applied to 4 platforms on the side of a Stadtbahn stop, but that's intuitive to users (if not, we can hint them). 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
On 01/24/2011 11:06 AM, Frankie Roberto wrote: [...] I don't think you'd consider Embankment and Charing Cross stations to be part of the same stop area, even though they're very close to each other? On the other hand, some stop areas (Waterloo perhaps) may be huge, even though it may take you more ten minutes to get from one stop to another (even from one tube platform to another). I don't exactly remember Charing Cross area, but I know where you're going with it. I actually see an advantage of OSM over traditional routing software. I have been sent by HAFAS (THE German routing application) from one bus stop to another very close one, but across a stream. The app simply calculates distances in a straight line. OSM, on the other hand, does have all the information: foot passages, bridges, etc. Again, let's leave to the software what is relatively easily calculated. And if a connection is too difficult (Charing Cross-Embankment above), it can be added to the connections cache. Such caches (static tables) are present in all major routing apps, so again, nothing new here. And much less work. I don't know whether this is intended from the current proposal or not, but I think you could construct a definition of stop areas along the lines of: a collection of public transport stops, often of differing modes, which are often physically connected by short walkways, often sharing the same name, are advertised as being an interchange on public transport maps and diagrams, and may be treated as a valid interchange by fare structures. I must disagree, see above. 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
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
[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] Summary of Public Transport Proposal Criticism
On 01/22/2011 09:32 AM, Dominik Mahrer (Teddy) wrote: I try to seperate the criticism from the spam around my proposal: - stop_area is not needed/too complicated: [...]And it does not seam to be too complicated, We have so many advanced issues in comparison to the total number of PT objects because we have a pitiful total number of PT objects on the map. If we keep, or even increase, the level of complication, then the map will not gain new mappers. And as for not needed: can we have a *separate discussion* on how routing works? There had already been voices that stop_area isn't really necessary, and while I don't claim to be pro in routing software, I am pretty sure we don't need them. I could elaborate, but not in this thread. The problem is our admin is overwhelmed, and seemingly doesn't past new threads. So why keep something that is essentially neither part of the map (map shows location of objects, not their relation), nor part of the routing algorithm? - route directions/variants is not needed: 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. While coming up with an alternative I actually realized that roles are only needed on bus stops (in HAFAS system, and not at all in most North American systems), in order to make two bus stops with the same stop_id unique. 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. - route directions/variants is too complicated: My opinion is: The roles forward/backward in the current tagging schema is complicated and very, very error-prone. Then let's drop them altogether. One relation for one timetable route, no matter how complicated it is. The rest will be (and can be) dealt with by the middle layer of software that will hopefully eventually deal with routing. Each of the three editors have their advantages and disadvantages. None of the editor is the reference implementation. The reference is the API. The real reference is the use of editors. You can't simply produce something, and then count/expect that it will be implemented. That way you will create a beautiful piece of law, with horrible usability. If potlatch should be an editor for everything,the authors of potlatch should see it as an obligation to implement support for nested relations What authors of Potlatch should see is immaterial here. We are their slaves, because Potlatch is used by entry-level users, who hopefully would do a large part of the work that is now done by pros, leaving the pros to do things that beginners cannot, or should not do. Surely we do not have to shape the proposal towards 100% Potlatch compatibility, but let's finally talk about what is entry-level stuff, and what is not. I propose that the creation of bus, tram, trolleybus and S-Bahn/stadtbahn lines be considered entry-level, and so be the creation of bus stops. LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Public transport proposal
On 01/17/2011 01:36 PM, Oleksandr Vlasov wrote: Michał Borsukmichal.borsukat gmail.com writes: This were true if we had 30 editors, but we have three. We have to bend over to those who maintain them. I do value the time and efforts editors' authors invested, and I believe everyone does. Did you misunderstand me? I had said that since we have three editors, not thirty, then we have to more or less do what the maintainers (coders) of those editors want. We can't come up with just anything, because it may not be implemented. Part of the mess is exactly the lack of a sensible and well documented (wiki page!) standard. My aim is to allow semi-beginners to be able to map at least the simplest things. I agree. Will currently discussed proposal be approved or disapproved, wiki should be cleaned up. Obvoiusly, before cleanup the preferred tagging way should be defined. This is, apparently, already on the way. This may be surprising, but in many areas the map is pretty full. In my area almost everything is mapped. If somebody likes editing OSM, they might just as well turn to mapping bus lines, with some help from us. Happy you. I agree that the proposed scheme isn't very easy to map without designated tools; nor established scheme is. But it's much easier. You will probably agree that the biggest mess is having to go though several pages and examples before one has an idea how to map. If you have another proposal, please come up. I personally do not have any sentimental feelings for the proposed scheme, I just believe it's better than the current situation. Well, not just anything is better than the current mess. I have an idea, that is simply to properly describe what exists*), and I believe ant started cleaning up the wikipages. *) I mean the version with two poles on each side. Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Public transport proposal
On 01/14/2011 08:37 AM, André Joost wrote: Am 13.01.11 21:57, schrieb Michał Borsuk: If this is your project, please stop at once, and wait until after the vote. Otherwise you will piss off many valuable mappers. I think you never used josm so far. You're tryng to derail the conversation. This is about ignoring everybody who doesn't agree with the proposal, not about which is my favourite mapper. As a simple mapper, you have the ability to build yourself a preset and use it on your own, and maybe share it with other users. And I would *never* listen to someone who tells me what I should do in the tone you are using currently. This is a very smart argument ad personam to remain arrogant. I demand your response to the arguments I have presented. The tone is, I believe, justified. Again: the actions of the person who is develipong the plugin for a PROPOSAL is nothing but telling all those who disagree we will push the proposal anyway. That is more than arrogant. LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
Am 14.01.2011 12:46, schrieb ant: Hi, On 14.01.2011 09:58, Michał Borsuk wrote: How about you, and the few of us who understand why the proposal is a mere nonsense, develop a better proposal? We seem to share the understanding of the flaws; a new proposal may lead to a secession, which is the ugliest thing possible, but I am not sure we can continue to improve the current proposal. Finally, that sounds much more like positive criticism :) So late because I tried to get others, who are valuable mappers for sure, to see that the proposal is going the wrong way. By the way, thanks Michał, for pointing out details of the routing techniques that I obviously got wrong. Now let's see how we can tackle the issues we have. You're welcome. Main Problem with the existing Schema (these are copied from the proposal) * Inconsistent handling of railway=tram_stop / railway=halt (node on the way) and highway=bus_stop (node beside the way). But is it really? I am stuck with the mapping of buses, so frankly I don't have the overview of how trams are mapped, but many issues raised here are really important. But if this IS really an issue, how about treating tram where it doesn't have a right of was as a bus, and where it operates on separate track, as a train? This will be confusing to new users IF they don't read the manual (they will see two seemingly different systems for one tram line), but this has a valuable advantage: it fits the German Stadtbahn - Karlsruhe mode anybody? Where a vehicle (not a train, not a tram) enters both the street network, and regular railway network? (this is not limited to Karlsruhe, this is indeed a big thing in Germany, the tram networks of many cities are connected by sections of old railways converted into this half-train-, half-tram). This would possibly also keep some sort of compatibility. Disadvantage: messy to implement two standards on one line. One suggestion here is to focus on the platform/pole and to scrape the on-way nodes completely (e.g. Richard's last post). I've implemented it before I knew of the entire mess with two competing standards. It wasn't my decision, somebody told me that we map bus stops where they are physically. I also thought along these lines: OSM has a higher resolution than the existing maps, so a stop position in the centre of the street isn't representative enough. * highway=bus_stop beside the way causes extra preprocessing for routing software. True, but something the data collectors don't have to deal with? True but unimportant. And besides, isn't it already a standard to add bus stops to the bus route? I've been doing so. * Insufficient possibility for line variants for bus lines. Mapping variants of PT lines is indeed close to impossible if people still enforce the one relation for one line mantra. Again, how about roles? Why don't we try to use them? it seems that they have been largely abandoned. But from the point of view of a non-geek roles are easier to grasp than separate routes. Again, how do you copy a route in Potlatch? Sorry to repeat myself, but how is it that Potlatch is universally ignored, whereas it's the entry-level tool that almost everybody uses? Even invariant lines become challenging for beginners, because the concept of forward and backward roles is really difficult to grasp. I may have got it wrong, but on a simple line from A to B, with bus_stops serviced in both directions (a good majority of lines), I don't see any use of the roles. I have the information that here, at this bus stops you have bus 105, and that's all I need now. I've used roles on lines that have different paths, and with the scarse information out there, I managed to understand it, so again, we need Actually, you made me just realize that by doing that (not adding forward and backard to stops) I ignored the direction iformation, which would be useful to the disabled, but indeed that's a lot of work. What's wrong with multiple, non-nested relations? - I'm not saying we need a route master. 1. weak point in case of rerouting: a beginner may move only one route; more work 2. lack of the option to duplicate a route in the entry-level software 3. lack of the need in the majority of cases (other cases: roles should be enough*) 4. incompatibility with present mapping standards, I mean printed maps - two routes per line may seem strange to beginners As for roles vs. two relations (3.), I mean to introduce arbitrary roles for legs of strange bus/tram lines. Let the user call the leg where a bus calls on Sunday mornings Sunday morning service only. This is pefectly enough for the rendering software, and as for routing software, I've expressed my doubts (but it should be also enough - those roles can be indexed). HTH. Greetings, -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk
Re: [Talk-transit] Public transport proposal
Am 14.01.2011 12:29, schrieb Oleksandr Vlasov: Michał Borsukmichal.borsukat gmail.com writes: Au contraire. Whatever is used, is the law, or is going to become the law. There is no divine being telling us what to do, so your promise of not being obliged to do whatever is worth nothing. because by using something you put the obligation on the community. Nope. If the author doesn't want to implement some feature, he might avoid its implementation. Surely that means his editor won't be used for working with this feature, but that not a problem: still, it can be used for working with all other features. This were true if we had 30 editors, but we have three. We have to bend over to those who maintain them. Again, on the contrary. We are introducing laws aimed at attracting beginners. Clearly, the choice of beginners is going to be Potlatch. Hence we are limited by what is available at the moment. And let's not forget the popularity contest. Last time I checked, each of the three editors had an equal share. I agree. However, mapping public transport now is complicated as well, so I personally do not expect beginner to start from public transport. Part of the mess is exactly the lack of a sensible and well documented (wiki page!) standard. My aim is to allow semi-beginners to be able to map at least the simplest things. Instead, s/he might (and probably will) start from POIs, since they're very visible and extreme easy to map, or Bing-drawing. This may be surprising, but in many areas the map is pretty full. In my area almost everything is mapped. If somebody likes editing OSM, they might just as well turn to mapping bus lines, with some help from us. Greetings, -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NEW Proposed Feature
On 14 January 2011 18:56, ant antof...@gmail.com wrote: On 14.01.2011 14:29, Richard Mann wrote: If I were ever to map it, I'd put it in as a separate relation and put days of operation in the two variants (do we have a tag for that?). I I've seen people use opening_hours on route relations. Wrong, due to different opening hours at different bus stops. I will elaborate on the complexity of timetable datasets, with actual examples, if time permits. One question here, are you developing this software as an academic assignment? If so, in which journal would you like to publish? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Public transport proposal
On 01/13/2011 01:27 PM, Richard Fairhurst wrote: Hello all, I note with some alarm the very complex, relation-heavy proposal for mapping simple public transport objects. Suddenly I am not all alone? Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 12.01.2011 07:50, schrieb André Joost: Am 11.01.11 17:01, schrieb Michał Borsuk: You do get that information when you are at the spot. It is written on the timetable. If you are able to see, yes. But disabled (that is everyone who has to use public transport because he/she is not able to drive a car) not. A lot of the disabled are perfectly able to drive cars (which have been adjusted for that purpose). My father was severely disabled after an accident, and he did so. And on the time-table you wont find a hint *where* the right platform is. It is clearly printed at each bus stop, at least in Europe. In North America phone number is provided. A public transport router with audio output would do, if it has the data. We could work towards this aim. The visually impaired are a very small minority, and clearly OSM has different, more basic issues to deal with. We should focus on the mainstream first, to get OSM out of the beta version it is now. Greetings, -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 12.01.2011 11:10, schrieb Albin Michlmayr: Am Tue, 11 Jan 2011 20:21:41 +0100 schrieb Michał Borsukmichal.bor...@gmail.com: On 11 January 2011 18:59, Dominik Mahrer (Teddy)te...@teddy.ch wrote: I began searching for alternatives and found Oxomoa, unified stoparea, stop place and others. All are created because the current schema is not able to represent all eventualities. It doesn't have to. It is an S-function, reaching 100% costs much more than reaching 99%. I pretty much came the same way Dominik did. I am also a public transport fanatic. So am I. And I like to map small details and it makes me joy to when a bus route crossing a roundabout uses one half of the roundabout in one direction and the other half in the other direction. Till now I had the impression that openstreetmap follows the philosophy Everybody maps as detailed as he likes. And for enthusiasts it is not only a question of efficency and costs but also of joy, and isn't it because of enthusiasts that openstreetmap exist? It's a Pareto-principle distribution: 80% of edits are done by 20% of contributors. Still, this does not mean that we can't have more contributors. And new guys are not going to map half a roundabout, at least not immediately. Personally I've done the same as you did, until I realized that my area (2500km²) will never get done if I am to be so slow. Thereafter I imported *all* the bus stops, added more lines, and miraculously more contributors appeared! So people were encouraged to join when they saw another person do something in their area. So the learning curve was important after all: they all copied from me, instead of discovering (like I did) how it should be done. And that's my main point: we need more of those small time contributors. If not and if this detailed public transport mapping is not preferred in osm please tell me, then I will find my joy somewhere else. This is a proposal, nobody is telling you to go. Or even to change your ways. Enjoy it as you did. I am just appealing to your common sense: the standard is not only for us, but for the community. The community is often *very* different than us. Most of them will never reach our levels of proficiency, but if they map a line or two, it's very good! And, I don't know where you people get the idea that I am any different than you. I've ridden public transport in many countries, both on the right and on the left side of the street, and on two continents. I map not only German lines, but also French, and local international (yes, we do have those!). Presently I don't have a car, but I have an almost free monthly ticket to my large public transport area. I've been to more places in that PT area (VerkehrsVerbund) than any local inhabitant in his whole life. What I clearly oppose is turning OSM PT mapping into our playground. I am an idealist, ready to defend the principle that OSM is a public service, not only our personal fun. I am not aiming to take the fun from us. All I want is to have an open door for new people. More on this should actually follow in the other thread I started, about principles to follow. Michał, please feel free to tell me what to change to improve the proposal. To say this proposal has a bad learning curve may be correct, but it does not help further. In another topic. I am looking forward to that! I've posted it yesterday. Can't cite the title, because I don't see my own posts. You're very welcome to argue with the five principles I posted there, and my comparison of the proposal in the light of the principles. Greetings, -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 12.01.2011 11:16, schrieb Richard Mann: 1) We need to see a proposal that is explicitly scalable. No more than one page to describe how to map a basic bus or tram line in a way that is consistent with existing usage (ie if you look around you will see lots of examples to reinforce your understanding). 2) There is no clear case for a new public_transport key. If existing usage of existing tags works ok for basic situations, that should be enough. That seems to be a sensible proposal, but do we put it into the standard? If so, then the one-relation version should be accompanied by a comment on roles. 3) It doesn't matter whether people use one relation per direction or two. Both are readily parsable. However, forward/backward must refer to the direction of the way, not the direction of the route, otherwise you are cutting across other uses of those roles. So, who's volunteering to prepare yet another wiki page that would explain the situation? And, personal request hereby. If you provide examples how to map (also how not to map would be good), please do not only provide your own examples. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 12.01.2011 12:59, schrieb ant: Hi Michał, Certainly it doesn't make sense to talk about bus stops when the road network isn't even finished yet. Totally agree. The point is, we are in the process of establishing a kind-of-standard about public transport network. There has been lots of struggle about this topic, and therefore it's quite an important process. Since I am working on a project that deals with navigation for the blind and visually impaired, I know how important these mapping standards (if you can call anything in OSM a standard at all) are. If we continue to stick to the old scheme, or any extremely simplistic scheme, we are simply missing the basis for future development in the area of blind people's navigation (and probably many other areas as well). Yes, we are - at the cost of (sorry to repeat the mantra) efficiency, compatibility with the existing software and easier learning curve. From our point of view (or mine, depends how you see it), the quality of the final product is a mathematical product of quite a few parameters (including the mantra above), NOT the quality of the data alone. I'm not saying everybody should do it now and everywhere. But the proposed public transport scheme is a solid basis to work with and one that is scalable enough to meet requirements we might not yet be thinking about. I've already provided my criticism to the proposed schema, so not to repeat myself, on another topic: I have been sort of thinking along the same lines as you are here (assistance to the users of public transport). I came to the conclusion that the easiest thing would be to take the bus stop code and combine it with the link to the local timetable online. For example, to cover entire area of Germany one would need to import stop codes as the stop_id tag, and then have a list of online timetables combined with geographical location those timetables cover. As some people (myself included) have already imported stop_id's, the last step - the mapping of public transport authorities to the geographical area, and providing a link to the online timetable is relatively banal. An overlay would then take the stop_id, combine it with the URL, and here opens your timetable website. I am writing this, because I have heard of NAPTAN, and I am sure a similar plan could be applied in the UK. My point is not to reinvent the wheel, no matter how much one likes programming. cheers also, ant michal -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 12.01.2011 15:50, schrieb ant: Hi, Ok, nobody is forced into a complicated tagging scheme. Anybody who is uncomfortable with relations, advanced editors or whatever should just put a node to each bus stop. That's fine. And that's what we're about to standarize. Another mapper will come and turn it into a stop area and update the route relations. Exactly. But this entire process needs a website, hence this discussion here. [...] People will develop standalone OSM routing applications for public transport and won't accept any dependency on external websites... No, they won't. It's too complicated, and too expensive to maintain. I can bet on it (sadly). Those who claim otherwise have not seen the real data, or they think that a bus starts from a terminus, ends at another terminus, and does it N times a day. It's not at all that easy. (Some people may want to simply copy Google Transit data, but again, Google Transit at present covers very small area.) Greetngs, -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 12.01.2011 16:30, schrieb ant: Consider an application that takes a start and an end address, maybe other options such as night lines only, and that shall calculate the shortest PT connection including number of stops etc. How would you accomplish that with the old tagging scheme? By introducing an abstract interface layer with your own objects, that is your own internal standard, into which all the messy present standards would be translated. This is easy. Then you play with *your* objects, your program is not directly dependent on the OSM PT standards. Any changes to the standards will require only a few lines of code to the abstract interface layer. BTW Data consistency is not as important as it used to be 15 years ago. We primarily have to make sure that no contradicting standards exists. Of course, this conversation still does make sense, because we want to have a clear standard for beginners, and for our own ease of use (and fun). Greetings, -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On 01/12/2011 05:07 PM, ant wrote: A node in this context means a place where i can change from one bus (tram) line to another without having to walk more than a few metres.In the proposed scheme a stop area is exactly this. Sorry, but this is absolutely pointless. First of all, modern routing software can calculate a route finding the nodes from stops' coordinates (Hafas and Google Transit). It will consider two stops to be a node if a distance between them is lower than a certain constant. So those can be created dynamically, humans are not necessary. For speed, popular pairs of stops are stored in a static table. Secondly, if you insist on stop area, then you create a weak point for the routing program, because it would rely on human input creating those areas. One area missing, and the entire routing algorithm goes to hell, because the program would send you through another stop area. Such errors would be very visible, and the users would be disappointed. Who wants to be taken for a ride all over the town because of one missing stop area? I mean no offence, but please understand that this is the 21st century. Your suggestions are indeed correct, but are applicable to software standards that were there 10 or 15 years ago. Much more can be done now. Point: Leave it to the algorithm instead of asking humans to do it. So the point of stop area relations is to prepare the data to be interpreted as a network and thus to make routing... easy. Programs such as Hafas are some years of age, and already they do it easier than you propose. They do it the way I described above: finding connections by distance between stops, and calculating the price to walk. A connection with a shorter walk is of course preferred, as is a connection without transfers. Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On 01/12/2011 06:34 PM, ant wrote: On 12.01.2011 17:27, Richard Mann wrote: I think there is some misunderstanding. I'm talking about the use of relations to group stop positions and platforms together that are considered a stop or station where one can change vehicles. Again, why enter it by hand (expensive!), when OSM already contains all the necessary data (stop coordinates, obstacles between them)? We do not need stop areas, at least not for that purpose. The transferability between stops can be calculated by a very simple script checking the distance (foot route) and obstacles between the two stops. The distance is then added to the cost of the route. (Cost: each transfer is a cost, travel time is a cost, walk as well, etc. The connection with the smallest cost is presented to the user). Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 11.01.2011 13:14, schrieb Vincent Privat: 2011/1/11 Michał Borsuk michal.bor...@gmail.com mailto:michal.bor...@gmail.com Am 11.01.2011 10:34, schrieb Claudius Henrichs: Arguments for relations in each direction: - easier to check correctness and completeness (simply select each direction's relation in JOSM) - easier to manage routes where the vehicle takes different routes and stops in each direction ...which is very rare in Europe. I strongly disagree, it's a very common situation in my city (Toulouse, France). And I don't think at all it's a local specifity. I have no time to analyze the entire network, so I followed line 78. Not at all complicated, around Saint-Orens-de-Gameville it does split, that's all what I can see. A split into two can be marked as roles, or ignored. Please: everybody remember, the aim of this map is not to compete with timetables, the map is supposed to show where (in which street) the bus passes regularly, not exactly where it goes. It is a map, after all. This has been proposed some time ago as a reply to oxomoa's messiness with data structures. So somebody suggested a bigger mess to make order in a smaller mess. Gib's ein Wort für efficiency in deutsche Sprache? Can nobody really see how much more complicated and time-consuming this is becoming? At the cost of what, gaining 5% in data structure clarity? For me the gain isn't really worth the time. It's a possibility, not an obligation. Au contraire. This will become an obligation de facto. And that is actually good. I strongly support this proposal which 90% reflect how I'm currently mapping in Europe and Asia. Think of new users. I am a new user. And I'm waiting for this proposal acceptation, because the current schema is far too simple, and far too basic, to properly modelize the public transport network I'm using every day. A new user is not always a user who cannot understand this schema. I have mapped an area of 2500km², with ca. 100 regular bus lines. It works. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 11.01.2011 10:40, schrieb Jo: For the record: I prefer to have one relation for each direction of the bus route, as this allows to indicate 'exactly' where the buses pass. Has OpenStreetMap turned into a timetable, or is it still intended to be a map? We are not mapping merely for the ability to draw a map of the bus routes, Did I miss the moment when it was decided? but also to allow PT routing eventually. Have you look into the complexity of the problem? Seriously, are you aware what is behind a typical bus timetable program? I know Hafas from the inside, I have seen the timetable data. What you see inside is WAY more complicated than what you see at the bus stop. Granted, Germans tend to complicate things beyond necessity, but even in an American version buses make detours, e.g. off peak hours, and often such runs are not on the map because they are not regular lines/runs *). To be able to put everything on the map would be practically beyond our abilities at the moment, and it would require another layer. *I am not at all discouraging the development of a layer with a timetable*, surely this is a beautiful idea, but please people reassure me that you know what you're getting us into. *) that is my rule: if bus doesn't pass at least four times a day in the country, and more often in the city, it is not a regular line, therefore not on the map, as there is no use for John Doe with a GPS. Thus for now - and in my opinion it will be quite a long now before the timetable layer is anywhere near completion - I vote for something far simpler than yet another oxomoa. Something that will allow future expansion. Yes, it's difficult, but we aren't stupid. I have already written how I see it, but you people are blind set on this new standard like there is no alternative. And pardon me, unlike certain other users, I am not promoting my ideas just because I used them for a long time, but I have thought of the efficiency as well. BTW I have entered some thousands of bus stops, and if I was to follow the new schema (and I should, after all it's a proposed standard, and I'm not an anarchist), I assume it would take 2 to 4 times as much time. Let me make my point clear: a standard is needed. But if we develop a new standard, let it also meet the following qualities (next to clarity of data): *ease of use, *efficiency, *sensible learning curve. Greetings, -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 11.01.2011 11:55, schrieb André Joost: Am 11.01.11 08:33, schrieb Michał Borsuk: Is there anybody else using it? I'd like to see more examples out of Germany or Switzerland, bitte. You will find a lot of well-mapped routes here: http://wiki.openstreetmap.org/wiki/AVV I have opened line 24 that I seem to remember (http://www.openstreetmap.org/browse/relation/304105), and there are two for each direction, seemingly following the same path. Questions: * What has been achieved by *three *relations that could have not been achieved by roles? How faster and easier is managing two/three relations than managing a role on the route? * What is the overall difference in paths, in percent, between the directions? Isn't it that only around the Bushof, and the terminus in Kelmis that the bus indeed goes into a one-direction loop? Everybody: please note that I am not stubbornly defending the old way. I just want to make sure that *efficiency, ease of use and the learning curve* had been taken into account when designing the new standard. Looking forward to your reply, -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Mapping standard: how to make a standard that is easy to learn, use and fast to implement
Hello everybody. I would like to open another discussion about the dreaded learning curve, and other principles that a standard should meet. Let me list out what I think are the most important points that ANY mapping standard should meet: 1. Data consistency Data consistency (not having a myriad of standards) is important, but what is now is not the worst case. As I said before, Melchior Moos managed to get through the mess and created openbusmap.org / ÖPNVkarte.de, so if he could, that means the situation is not critical. It is high time we developed a standard for our own ease, but it's not like there's a tragedy with what is now. After all, we're all still mapping. 2. sensible learning curve There is only one way to become a pro in public transport mapping, that's to learn the standard. If the standard is very long, or very complicated, or has unpleasant steps to learn at some point of the fun with mapping, we're going to loose mappers. We must rely on newbies, rookies and the like, we simply can't map each city we visited. The point: system must be either simple, or if it's complicated, it must be broken into steps of increasing difficulty. Ideally it should be easy for a newbie to edit a bus line. 3. efficiency A stop point with two platforms will take significantly more time than two bus stops (or one in some situations). Two relations (or more! e.g. Paris RER) will take significantly more time to edit in case of a detour (right, RER won't be detoured, but you get the picture). 4. usability with present software Large part, let's say 80-90% of the cases one runs into when doing basic mapping must be done in the simplest available software. Why? Because mappers are not programmers. Majority of mappers (Pareto principle, anybody?) see the OSM website, the edit button, and do not much more. Those more adventurous will try to map bus lines, and they will look for a wiki page. Those guys are not as hard-set on mapping their surroundings as we are, let them map one line, that's how public collaboration works after all. 5. Info page on wiki Absolutely crucial. I hope this is simple and clear. A creative (I hope) criticism of oxomoa and Teddych's proposal follows. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Mapping standard: how to make a standard that is easy to learn, use and fast to implement
On 01/11/2011 08:53 PM, Michał Borsuk wrote: Hello everybody. Now to what I'd change in the proposal: 1. Data consistency Data consistency (not having a myriad of standards) is important, ...but it's not everything. Reaching this point to near 100% will cost us the points below. I strongly suggest that we let go some quality in exchange of gaining on the points below. Think about it, the final result will be a matematical product of all five points, not only of the first one. I'd rather have 10'000 bus lines mapped to 99% accuracy, then 1000 lines mapped to 99,9% accuracy. I monitor bus lines in my area, and find it much easier to review and correct 10 new bus lines by newbies, than enter one bus line myself. (Well, maybe three). 2. sensible learning curve This point will have to be addressed as the last one, after efficiency. 3. efficiency Now for a bit longer rant: The point of having very exact data is, among others, to have timetables in the future. Am I correct? I have looked at the source data of a few companies, both in Europe (hafas), and in US (Google Transit). The actual data is FAR MORE COMPLICATED than you can imagine. Buses may have early morning Sunday runs that aren't probably mapped in OSM, because nobody noticed them. Many more exceptions. OSM would probably have to take the day of the week and time of the day into account. It would be nice to have this data on OSM, but at this moment I *really* don't see this happening. Also, OSM seems to be in a kind of a beta state in many places. Not far from my place there's a town of 20 thousand, that has three streets, and the bus terminal, thanks to yours truly. (And lots of buildings thanks to French Cadastre. But no streets.) So in my opinion there is not so much sense caring for super correct data structures like our proposal provides, but to get on the map as many lines as possible, in the quality that we have now. It is in many cases sufficient! So what that the same bus stops at stop A in both directions? There's the printed timetable at the stop, there's Hafas/Google Transit online. For the user with GPS it matters that he/she found the bus stop. To the point: * I'd drop the requirement to have one relation in each direction. Not user friendly, not really necessary. As I said, the bus diverts, doesn't go the same route in both directions? If it's a one-way street, ignore it. Otherwise set a label, or role, and don't worry about it. ÖPNVkarte already displays it well. * drop the mother relation with it. Again, not user friendly, and normal people don't like B-Trees (e.g. nested relations - it would be two-step nested relation). * another point to dropping the relations is: leave the thinking and sorting to machines. Label (use relations) what is not standard, i.e. runs on different streets, and leave it to Melchior Moss' superb map to deal with. He managed, didn't he? * bus stops: pardon le mot, but who cares where the stop_point is? People wait at bus stops. I'd scrap it. Surely this will introduce an inconsistency between buses and trams, but this can be solved. * things like RER: for one line there is a central station, and a number of terminuses (termini). The entire schematic for *one* line looks like a Christmas tree. If we were to provide a relation for each possible destination and back, it would easily produce 10, 12 or more relations, nested in another relation. Again, what for? What do we want to achieve by this? If we want to get a timetable for a stop, there's the stop code, which can be entered into the local online timetable, and there you go. Example: Bus stop name=Pieper stop_id=40028 http://www.openstreetmap.org/browse/node/906491624 Corresponding HAFAS page: http://www.vgs-online.de/cgi-bin/stboard.exe/dn?input=40028 here's the stop ID: ^^ Simple and easy, and I've been using those codes on my telephone (opera mini). It's easier to type 12613 than Beim Weisenstein. It would be even easier if somebody could write a simple extension to OSM to automatize it. 4. usability with present software I think we can assume that a lot of edits are done by small, one-time users (Pareto principle again). Those guys are not going to download JOSM, a piece of software requiring another download (Java), just to learn it and put one bus line. Are we ready to cut off a majority of small users by introducing something that they can't do with Potlatch? (Potlatch 2 doesn't provide all the required tools for this proposal) 5. Info page on wiki The existing mess was quite recently turned into a standard of its own by a discussion on this list/newsgroup. Why don't we get back to it, make a website and just update a few things, instead of reinventing the wheel? Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
On 11 January 2011 07:24, Dominik Mahrer (Teddy) te...@teddy.ch wrote: Hi all One month ago I already posted an RFC on this proposal. In the meantime I got plenty of comments and I have extended/corrected/rewritten nearly the whole proposal. Please visit again http://wiki.openstreetmap.org/wiki/Proposed_features/Public_Transport This: - The route-[image: Relation]http://wiki.openstreetmap.org/wiki/Elements#Relationis split up into two separate *direction*-[image: Relation]http://wiki.openstreetmap.org/wiki/Elements#Relations and separate route *variants*, if required. - The *route master*-[image: Relation]http://wiki.openstreetmap.org/wiki/Elements#Relationcontains all the relations for the route directions and variants ...is a copy of oxomoa, which has been criticized as overbloated. Why was it kept in the new draft? What are the arguments for two relations in each direction? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Town names in bus stop names
On 21 December 2010 02:23, mich...@vonglasow.com wrote: Hello list, While mapping bus (and other) routes all over Europe, I have frequently encountered bus lines linking two (or more) towns, with multiple stops in each town. For example, a bus route might include the following stops (free adaptation of commonly encountered situation): Greenmond, Station Greenmond, Doe Square Greenmond, Church Greenmond, Roe Street Greenmond, New Market Mall Whitepool, Primary School Whitepool, Church What should we put in the name= tags for these stops? Where should we best put the name of the town? To complicate matters, let us look at the following conditions: - The name on the pole itself does not include the name on the town. So the pole at the station in Greenmond would just read Station. I take the name from the pole, unless it's not descriptive enought, then from the timetable. Here I'd clearly take Greenmond, Station (or Greenmond Station, but preferably not Station, Greenmond) - There is also a bus line operating only within Greenmond, which shares some of the above stops. However, timetables and line sketches for this second line omit the town name in the bus stops (i.e. Station, Doe Square, New Market Mall). In such cases I'd still use town name. It has happened to me that I wondered out of nowhere to find a bus stop without a locality name. I do it this way: only large towns and cities (let's say over 15 thousand inhabitants, or with a sensible number of bus stops) have those stops *without* locality name. - When rendered on a map, it is also advisable to omit the town name - thus names are shorter, the map is less cluttered and the town name can usually be derived from the on the map. Cf. the earlier point - if the town is small, the map is not cluttered. Besides, rendering is not much of our concern. - Line sketches and timetables for the above line list stop names along with the towns they are in. There are different ways of dong this:[...] Or (since Greenmond is a big city of a million residents or more), town names are given only for stops outside of Greenmond. I'd keep that. However, the more I think about it, the more correct it seems to me to put the town name in a separate tag. IMHO No. This is a map, and it's the bus stop's location which tells where the bus stop is. It does contradict what I wrote earlier - why then use town names at all? Because some suburbs overlap in a strange way, and with smaller places it isn't always clear. That way renderers get the actual (local) name of the stop separately from the town it is in and can decide how to process these: But it's more complicated, and not compatible with existing software, I am specifically speaking about a JOSM plugin. Michael -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Conversation on this list (was: Proposed Feature - RFC - Public Transport)
On 14 December 2010 22:56, Dominik Mahrer (Teddy) te...@teddy.ch wrote: Today morning I got this off the list: On 12/14/2010 07:56 AM, Michał Borsuk wrote: I already told you twice to behave, you little shit. If it continues, I will have you removed from the list. Perhaps I did not find the best words. Please excuse me. That's what I wanted to hear. English is not my first language. Poor excuse, for neither is mine. [...] because others have a different meaning, It was about repetitive rude behaviour, not a different meaning. Shall I elaborate? I don't know if I want/need to be on this list... That's solely your decision. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Conversation on this list (was: Proposed Feature - RFC - Public Transport)
On 15 December 2010 02:33, David Murn da...@incanberra.com.au wrote: Maybe Im a little new to this list, but this language and attitude hardly seem hardly appropriate, and English *IS* my first language. I would like to think that public lists are available for discussion and debates, not personal inflammatory insults. You only have failed to notice a certain manipulation by Dominik. What he posted here was my private communication with him. I was simply annoyed by his repeated offensive behaviour. Sorry, but what is between me and him personally is not your business. And I do have a right to feel offended, and to react. Michael, if you really dont like reading something twice, youre more than welcome to leave this list yourself. Again, my comments were in a private email to Dominik Mahrer. For such a detailed proposal, which such big potential changes, I feel (although it appears to be at odds with your opinion) that the more discussion can only improve the clarity of the situation. Surely personal accusations from one member towards the others do not help to maintain a clear discussion. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Conversation on this list (was: Proposed Feature - RFC - Public Transport)
On 15 December 2010 07:37, David Murn da...@incanberra.com.au wrote: On Wed, 2010-12-15 at 07:10 +0100, Michał Borsuk wrote: Sorry, but what is between me and him personally is not your business. Maybe you sent more to him, but the only part that was posted here were 2 sentences, one of you using profane language and another threatening to have him banned from the list, because he didn't 'behave' like you told him to. I apologize for the form. Sorry, it was too much. But I stand by the meaning. Throwing accusations and personal insults towards others is really lame. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 11 December 2010 00:39, Richard Mann richard.mann.westoxf...@gmail.comwrote: On Fri, Dec 10, 2010 at 9:12 PM, Dominik Mahrer (Teddy) te...@teddy.ch wrote: Especially see the German talk page. I would like to approve a tagging schema that is clearly defined. Doing this with new tags is portably the easiest way. Redefining highway=bus_stop on or beside the way seams to be nearly impossible. Again: Have a look at the German talk page. The English-language discussion appears to have long reached a consensus (except for you). My German is not sufficient to follow the discussion, but clearly there are more people arguing each way, and shouting about it. If some people wish to use highway=bus_stop on the road, with highway=platform alongside, that can perfectly well be deciphered by software, and clearly documented as an alternative approach, and tag stats displayed to show which is dominant where. It does not need a public_transport key to confuse matters further. Most of all, it works. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 10 December 2010 22:12, Dominik Mahrer (Teddy) te...@teddy.ch wrote: On 12/10/2010 08:55 PM, Richard Mann wrote: I would agree that on-highway highway=bus_stop should be phased out (is anyone saying they should be retained?). I think they're a hangover from the time before we realised that tagging the pole was a better approach. In the mean time, I don't think it causes any major problem (it just isn't as clear as tagging the pole). Many city and/or network public transport wiki pages in central europe recommend to use highway=bus_stop _on_ the way And they are wrong. Because according to OSM's principles, the object should be placed where it physically exists. Even on the wiki page highway=bus_stop is not clearly defined as _beside_ the way. Then we have to do it. highway=bus_stop is a fuzzy tag. I see it very clearly. I would like to approve a tagging schema that is clearly defined. ..but which is not against the principles of OSM. Doing this with new tags is portably the easiest way. Not sure about that. Backwards compatibility is very important. Approving a bunch of tags from people who created such a system as oxomoa is not my priority. I am also waiting impatiently for a clear system, but I am not in a hurry to approve crap just because we're tired of the old system. The new one could be a bigger mess than the old one. If you like oxomoa, then you're missing the understanding how unnecessarily complicated it is, and difficult for beginners. OSM is not a castle on a high mountain, we have to take care of beginners' learning curve. Redefining highway=bus_stop on or beside the way seams to be nearly impossible. Again: Have a look at the German talk page. Why? Please, take a moment and look at German solutions from a side. Imagine that you're not German. Do you see how unnecessarily complicated Oxomoa's plan is? It covers very, very small details (read: they rarely occur), at the some time forcing much more work on simple (most often occurring) situations. Sorry, but this is not efficient. Why is highway=bus_stop recommended to use _on_ the way? Because it does not make sense to have two tags _beside_ the way (highway=bus_stop and highway=platform). Au contraire, my fellow mapper, and it this discussion was *closed*. There are as many bus stops near the road as there are out there in the field, because the resolution of the map is so detailed, that placing one dot on the road is not enough. Moreover, as far as I remember, North American system (contrary to Hafas), gives each physical stop place a different index number. The platform definitely is beside the way Where? Behind the corner? On the left? On the right? No, this is not detailed enough. My understanding for those they have put hundreds of tags on/beside the way. They do not want to move them (in which direction ever). Do you have any other personal accusations towards other mappers? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 11 December 2010 15:08, Dominik Mahrer (Teddy) te...@teddy.ch wrote: On 12/11/2010 09:26 AM, Michał Borsuk wrote: Many city and/or network public transport wiki pages in central europe recommend to use highway=bus_stop _on_ the way And they are wrong. Because according to OSM's principles, the object should be placed where it physically exists. Depending of what highway=bus_stop should represent. If it represents the pole/platform they are wrong. If it represents the yellow zigzag line on the street they are right. How often is there just a pole? Quite often. Does the existence of other types of bus stops justify the addition of a new tag? Yes, if it's not too complicated, and does not break compatibility. The idea with a platform does not match either. I do use platforms, but at larger termini and transfer points, where there are indeed more than two platforms, and it's important to have them labelled. On a street with one bus stop in each direction it is not possible to confuse anything. And by the way: What physical thing is represented by railway=tram_stop? I don't deal with trams. I would like to approve a tagging schema that is clearly defined. ..but which is not against the principles of OSM. What is against the principles of OSM in public transport proposal? Points on the way do not represent bus stops' location. Imagine that you're not German. I do not have to imagine this, I am not German. Your beginners version: highway=bus_stop beside the way highway=platform beside the way One of those, of course. Not both. Oxomoas beginner version: public_transport=stop_position on the way public_transport=platform beside the way Too complicated, too much work: 1) it is not compatible with what's being used 2) platform is not a node, but a line, requires more work What does it really give? How is it better? Where is the difference in effort? Explained above. Whatever proposal/schema you take (old/unified/oxomoa/stop place): Nothing of the tags is a *must*. Everything is optional. The point is to have a sensible system that can be shown to beginners. A Wiki page with a clear system, that is easy to grasp, and not the usual bullshit about multiple-level B-Tree complicated relations. You can invest as much effort in tagging you want. But the upper limit of (unified/oxomoa/stop place) is much higher then in the old, very limited schema. My problem is the lower level, not the upper level. This is the problem with oxomoa: that by doing complicated things well, it messes up easy things. Oxomoa is centered around the quality of itself, while a good system would be centered around ease of use for the most frequently used tags, and then it would bother with crazy lines that loop somewhere in the forest. Whenever I criticize Oxomoa I hear the same silly argument: but in my Siedlung there's a bus that does such a complicated thing So what? Who cares? This is OSM, not a competitor to hafas. We show lines where they are, and not how they go. (If you wonder why, I can elaborate on the difficulty of storing data in hafas, I know it from the inside. It would be practically impossible as of today to transfer this data completely to OSM. And useless). There are as many bus stops near the road as there are out there in the field, because the resolution of the map is so detailed, that placing one dot on the road is not enough. Moreover, as far as I remember, North American system (contrary to Hafas), gives each physical stop place a different index number. How do you want to map this with the old schema? You do not have a stop place/stop position tag. I am not sure if I know what the old system is. Maybe we actually criticize the same thing. I'd do it this way: highway:bus_stop for each bus stop, and then the bus stops are added to each line (relation) that stops there. Nothing more is needed from the point of view of even rich future applications in OSM. There is the info where the bus stop is, there's the line, if we ever want to link OSM with timetables (as I am planning), then we have everything we need. The platform definitely is beside the way Where? Behind the corner? On the left? On the right? No, this is not detailed enough. As you said: There where it physically exists. Yes, my misunderstanding. My understanding for those they have put hundreds of tags on/beside the way. They do not want to move them (in which direction ever). Do you have any other personal accusations towards other mappers? This is not an accusation, this is the only plausible reason I heard until now for not changing the old schema. Would you be so kind and withdraw from the accusation that the reason behind the resistance is the unwillingness to convert the existing system? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 12/10/2010 11:20 AM, Richard Mann wrote: I think the biggest uncertainty is how you handle loops at the end of a route - do you have overlapping single-direction relations, pick an abritrary position to change direction, or stick with having both directions in the same relation and let the data user worry about it. I do it this way: end points from the timetable (Kursbuch), so the forward role goes to the last stop indicated in the timetable, and the backward role goes forth. Richard -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 10 December 2010 12:31, Richard Mann richard.mann.westoxf...@gmail.comwrote: I was thinking that role=loop on the loop stops might be one way to do it, with role=terminus for single-point route ends (and as a notional terminus on a loop)? I think we're talking about two slightly different things. In my area there are a lot of lines which *end* with a loop (instead of a terminal where the direction switches). I think you're referring to a completely circular line, like the yellow line in London, or what is often in Eastern Europe called line 0. If so, then may I ask if we really need this role? Could you provide an example, as I may not completely understand the details? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - RFC - Public Transport
On 8 December 2010 20:44, Dominik Mahrer (Teddy) te...@teddy.ch wrote: Hello Yes, the Public Transport proposal is basically based on Oxomoa, but in some details different. I do not care about which of the two proposals will be approved. But I think it is time to get a more exact schema approved then the fuzzy/non-existing schema (A railway station of 400m length and 20 platforms or a bus stop for 3 buses per direction of 50m length is reduced to one node) we have now. There is the issue of multiple relations per line in oxomoa, which in my opinion is a total misfit. There are roles in relations, and different variants of a route can be put there. Two, or more, relations per line is not only illegal (clearly against the principle, as it was stated by its creators), but also hell to administer, and JOSM-limited. Potlatch and Merkaartor account for 2/3 edits together. This simply cannot be passed to the final draft unchanged (as is). -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Again about time tables, and some interesting sites
Am 06.12.2010 09:46, schrieb Jacques Lys: Hello, In fact, PT data are most often seen by agencies as being critical data they have to protect while submitting tender for Delegation de Service Public. I expected the timetables to be organized by a government supervisory body, with only the bus lines being awarded to the winner of an auction. That's how it is west of Rhine (which is, of course, not necessarily better). Such a body is easier to approach with an offer to share the timetable. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Again about time tables, and some interesting sites
Am 06.12.2010 14:54, schrieb Andrei Klochko: Hi, That is simply not true. I know what I am doing. I would like to believe it as well, but as I know copyright laws (not of France, but of other countries), to me it also sounds weird. What I could suggest is to have an official, written advice of a legal firm that what you want to do is indeed legal. What we simply find strange is that France would leave such a loophole. It is specifically closed in the legal systems of most other countries by stating non-sequential reading of records, not leading to the copying of the entire database. And reading all timetables DOES NOT constitute a recreation of a database, because you are indeed doing a sequential copying. It does not matter how you process the data, the sequential reading is important. Again, this is how it is defined in many countries, but perhaps not in France. Stay cautious. Ask another lawyer? Greetings, and good luck. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Again about time tables, and some interesting sites
On 5 December 2010 08:07, Andrei Klochko transportspl...@gmail.com wrote: Hello, But, at least in french law, as far as the opinions of the lawyers I consulted about this question were correct, any individual or company has the right, to download one by one the timetables - and transportation plans! - of any transport company, to extract the data (timetables: only the data itself, and plans: only the path of the buses, of course, but that's all that is needed!) from its support and presentation, and to incorporate it in any database we want, without asking any permission. If we do it one by one: We have to *recreate *the database so as not to violate any right! I would double-check this. Normally (i.e. in many countries with legal systems similar to that of France) one is allowed to download non-sequentially (one-by-one, but not in a manner suggesting copying the entire dataset), but not allowed to recreate the database. Because I have indeed tried to ask permissions from the public transport operators to use their timetables and plans. But I must be bad at asking, I share your experience. I tried asking Mobiliteit in Luxembourg, they never answered. My local administrative body was so confused about my question that I first used their data, and then sent them a paper to sign. I would have never got the permission to use the data, partially out of the German national fear of anything new. And I also suspect that there is simple jealousy. People administering public transport usually have nice governmental jobs, and YOU come here and demand something. You may be uncovering the fact that what could be done by one freak is now being done by 5 individuals, all with the wrong tools. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] What's going on with ?pnvkarte?
On 17.11.2010 13:51, Hillsman, Edward wrote: Opnvkarte does not provide coverage in North America. It might, as it did shortly in September, before the stall. It's called opebusmap.org internationally. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] [Spam] Re: child relations in type=route, route=bus
On 04.10.2010 11:09, Peter Miller wrote: On 2 October 2010 05:28, Michał Borsuk michal.bor...@gmail.com mailto:michal.bor...@gmail.com wrote: 2010/10/1 Jo winfi...@gmail.com mailto:winfi...@gmail.com [...] I'm pretty sure that if one gets the PT companies to share their data, it's not going to be in there with child relations. Usually (e.g. HaFas) timetables consist of a number of routes, and those are very detailed, each direction is mapped separately, and e.g. if a bus ends its day not at the terminus, then it's yet another route. This approach is easier to store in a database, but is in my opinion that one step too detailed for humans to manage in OSM. It would apparently make sense to make a collection named line 123, and store child routes withing that collection, but as of today there is no efficient way to deal with this. Transmodel breaks public transport routes down into the following: [...] More here for brave people http://en.wikipedia.org/wiki/Transmodel Personally I suggest that we limit the transit information in OSM to the minimum and leave the detail in GTFS. Personally I would like someone to create a bus-map application using OSM together with GTFS schedules - doing that would remove a lot of the pressure to model public transport in OSM. I am for it too. There is simply too much information to deal with. I'd stick to the traditional model: graphical route display+route number. Therefore I skip lines which aren't regular ones in the traditional sense, e.g. a collection of different routes under one number, school buses and other which run few times a day, collective taxis etc. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] child relations in type=route, route=bus
2010/10/1 Jo winfi...@gmail.com [...] I'm pretty sure that if one gets the PT companies to share their data, it's not going to be in there with child relations. Usually (e.g. HaFas) timetables consist of a number of routes, and those are very detailed, each direction is mapped separately, and e.g. if a bus ends its day not at the terminus, then it's yet another route. This approach is easier to store in a database, but is in my opinion that one step too detailed for humans to manage in OSM. It would apparently make sense to make a collection named line 123, and store child routes withing that collection, but as of today there is no efficient way to deal with this. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] child relations in type=route, route=bus
On 28 September 2010 23:22, Jo winfi...@gmail.com wrote: I created 'sub'-relations for parts of bus routes that are used by more than one line. I suggest to finally solve the problem this way: we need to insert a new logical layer between what we map, and what is displayed. This logical layer would then take your mother relation plus any child relations (or roles), and make n versions of the mapped bus line out of this. That also solves the problem of one vs two relations (in each direction) per bus line. I am against it because it would be hell to manage, and in Europe, where one way streets are are, quite an overkill (because it's rarely needed, mostly around termini). This could be solved by child relations/roles as well, but only for sections where the routes forwards and backwards don't match. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] child relations in type=route, route=bus
On 29 September 2010 10:31, Richard Mann richard.mann.westoxf...@googlemail.com wrote: Lots of relations is probably conceptually less complicated than child relations, so I'd probably go for that, editors-allowing. Can one deal with this in Potlatch, which is the entry-level editor for most mappers, and common editor for 1/3 of all users? (Mind you, there are things Potlatch can do that are hardly possible in Josm or Merkaartor) -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] NPTDR in the datastore
On 21 September 2010 20:03, Peter J Stoner stone...@mytraveline.infowrote: The October 2009 public transport timetable data for Scotland, England and Wales is now released as opendata in http://data.gov.uk/dataset.nptdr Could you please correct the link? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] GTFS compatibility
On 10 September 2010 17:29, Michał Borsuk wrote:
I'd be very glad if the bug could be somehow corrected (sorry, not a Java
programmer myself).
It should be corrected now. The plugin now ignores commas within double
quotation marks and removes all double quotation marks from the input.
Thanks for acting fast!
Using the moment to ask you for something useful for me: would it be a
problem to add an optional tag to the bus stops being added? I'd need
FIXME=yes.
Do you know how single quotation marks (') and/or escaped characters (\,),
(\) and (\') should be treated? Maybe they ought get special treatment as
well.
IMHO not in any specific way, i.e. to be ignored. GTFS states that fields
containing commas or quotation marks must be enclosed in quotation marks.
--
Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia,
Michał Borsuk
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] [GTFS import] How to automatically add bus stops to relations?
Hello. Thanks to Roland Olbricht's Public Transport plugin, I have successfully merged existing bus stops with my GTFS data. There was a part of the work that required manual human intervention, e.g. mapping existing bus stops to the imported ones, but the second part, that is mapping bus stops (nodes) to lines (relations) can be done automatically. Any ideas how to do it? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] [GTFS import] How to automatically add bus stops to relations?
On 8 September 2010 18:55, Khoa Tran ktr...@mail.usf.edu wrote: Hi Michal, We're developing an application to do just exactly what you want. We have successfully run a test on Hillsborough Area Regional Transit (HART) in Tampa, FL, USA. However, it's in a premature stage and need just a little bit more of the GUI. If you don't mind, you can post the link of your GTFS dataset and let us run a test on your dataset. We'll let you know the result. Unfortunately the dataset is larger than the licence, i.e. it contains parts of other regions for which I have no permission to process and I don't touch. I could possibly provide you the data once I'm finished processing it, as I need to review stop names (it's done partially). One problem I've encountered so far: does your program accept data within qoutation marks? Our bus stops contain commas in the names, which is a GTFS requirement, but didn't go well with the Public transport plugin for JOSM. Otherwise, you can visit the application's website at http://code.google.com/p/gtfs-osm-sync/ . It's a java desktop application and there's no jar file available yet. But we'll put something up very soon with instructions on how to use the app. I've been to your website, but where's the executable? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] [GTFS import] How to automatically add bus stops to relations?
On 8 September 2010 20:41, Khoa Tran ktr...@mail.usf.edu wrote: Because the application will upload a large amount of data into OSM, I'd like to write some clear instructions first before put up the executable file (jar file in this case). Otherwise, the OSM server would have false data. Below is what the application generates: http://www.openstreetmap.org/edit?lat=28.05112lon=-82.42484zoom=17 http://www.openstreetmap.org/edit?lat=28.05112lon=-82.42484zoom=17 Too good for my data as far as bus stops go. I have to review all the bus stops, because offset of 50m is quite usual. Are you sure we're talking about the same thing? Because all I'm looking for is to match relations/lines from one dataset with stops from another. Stops have to be added separately. I'll try my best to put up the executable file by the end of this week. But if you have your dataset before that, please post it cause I haven't tested the application well yet (only on 2 dataset). OK, I'll try to somehow filter out foreign data, and post it for a test. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Line diagrams
On 31 August 2010 10:05, Ed Loach e...@loach.me.uk wrote: Looks to me like the platform is where the passengers wait (at the “bus stop”) and the “stop” role is where the bus physically stops on the way. From http://wiki.openstreetmap.org/wiki/Tag:highway%3Dbus_stop : The most widely accepted approach is to place bus stops nodes off *to one side of the highway way*, so *not* with node being part of the way. Sorry, but to me it looks like yet another fun thing to complicate the matter more than necessary. I use platform only where there is a terminus-like structure, that is where there is more than one bus stop. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Line diagrams
On 31 August 2010 17:36, Steffen dido_...@web.de wrote: [3] http://www.openstreetmap.org/browse/relation/13639 Why are the bus stops in the relation above separately mapped as a node (IMHO correct), and yet again as a platform? It is mapped ala Oxomoa/ÖPNV-Schema. Then drop the scheme at once. It is crazy. I bet that it is responsible for the suggestion that one route should be mapped twice, once in each direction. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Line diagrams
On 30 August 2010 18:34, Steffen dido_...@web.de wrot [3] http://www.openstreetmap.org/browse/relation/13639 Why are the bus stops in the relation above separately mapped as a node (IMHO correct), and yet again as a platform? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] totally abandoned rails
On 31.07.2010 20:58, Heiko Jacobs wrote: Michał Borsuk schrieb: May I ask why bother? OSM is not a historic map, am I right?. What use do I have of the information that once here there was a railway when there are no traces, nothing to be found, nothing to be feared? There are a lot of things inside OSM that for my opinion are bothering. But I don't delete them ... I meant that you should not map things that are not actually on the Earth. (Why bother means why do it) It seems that you both don't read my first mail? Neither you read the numerous replies which said that you should abandon the entire idea. Plus, you are aiming to add a new type of a tag (value), and this action requires an in-depth approach, because it disturbs simplicity. Don't complicate things that work, for better is the enemy of good. -- Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] How do you map elements of an amenity_bus_station?
Hi! I mostly deal with public transport, and I have an issue which I can't find in wiki, so I hope to have answers from users of bigger experience than mine. For termini, as well as for larger transfer points it makes sense to use amenity=bus_station in place of highway=bus_stop. Now the problem is what the elements (bus stops in real life) of the amenity should be? I see three choices in use: * highway=bus_stop seems to be the users' choice, but on some maps, namely Osm2Gps (Java offline map for telephones), there is a clutter of names, one for the amenity, one for each stop * highway=platform doesn't clutter, but then the actual location doesn't show up on mapnik * highway=bus_stop, but without a name, just platform code. Seems the most sensible solution, but is it compatible with what others are doing? -- Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] totally abandoned rails
On 31 July 2010 10:06, Heiko Jacobs heiko.jac...@gmx.de wrote: Michał Borsuk schrieb: Without getting too much into the linguistic issues, I'd support the Swedish railway=historic_path for anything further than stillgelegt (English abandoned?), that is either with track, or without, but not yet turned into a bike path (or anything similar). But let's wait for others to comment. It seems, that no one else will comment here? I'm still not satisfied to use something with time in it like historic as part of a list with timeless words describing states. levelled or disappeared might be better suitable to this list: - proposed/planned - construction - () - disused - abandonded(/dismantled) - levelled/disappeared I agree with your arguments. Then former? Disappeared cannot be used, because it implies that the railway just rolled itself and went home for Feierabend. Or a UFO took it one night. I don't like levelled for another reason: it is a word that is not easily understood for those English-challenged, that is beginners. It's not a word that easily translates into other languages. For this I would propose removed. (Then it does not contrast with dismantled very much, but frankly I am getting lost in those distinctions). - proposed/planned - construction - () - disused - abandonded - removed/dismantled/former (if there really is a difference) - [*=bike path] -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] totally abandoned rails
On 31 July 2010 14:19, Cartinus carti...@xs4all.nl wrote: On Saturday 31 July 2010 10:06:23 Heiko Jacobs wrote: It seems, that no one else will comment here? I think you don't get much comment because most mappers are too busy with mapping stuff that is still there. If we don't have some order in it now, we can run into problems later. Inconsistencies do exist already. There is actually a significant number of people that think we should _not_ map stuff that is no longer there. But IIRC the question was how to map a former railway line that is older/more damaged than mothballed / overgrown with trees, but not yet removed. That could be mapped. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] totally abandoned rails
On 31 July 2010 15:13, Heiko Jacobs heiko.jac...@gmx.de wrote: Michał Borsuk schrieb: I agree with your arguments. Then former? former is a little bit non-specific. A disused or abandoned railway may also be called former It's already called disused or abandoned. I don't like levelled for another reason: it is a word that is not easily understood for those English-challenged, that is beginners. It's not a word that easily translates into other languages. For this I would propose removed. (Then it does not contrast with dismantled very much, but frankly I am getting lost in those distinctions). Better than levelled might be the words converted or transformed? converted/transformed to farmland/residential areas/village green/... including filling of cuttings and removing embankments ... If any traces of it are removed, then it doesn't classify for OSM. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] totally abandoned rails
On 31 July 2010 16:18, Heiko Jacobs heiko.jac...@gmx.de wrote: A former railway between Ittersbach and Pforzheim I could map 90% because there are enough traces (gravel, embankments, cuttings, bridges, ...) but 10% are levveled for farmland or residential ares including buildings. But the way can be reconstrcuted May I ask why bother? OSM is not a historic map, am I right?. What use do I have of the information that once here there was a railway when there are no traces, nothing to be found, nothing to be feared? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] totally abandoned rails
On 28 July 2010 11:26, Ed Loach e...@loach.me.uk wrote: Something like http://forum.openstreetmap.org Definitely. Forum is way better than a mailing list, a threaded forum is even better. What needs to be done: * creation of a subclass in the forum (name anybody? is Transit Talk OK, or too short?) * blocking new posts here, and leaving an automatic reply with the link to the forum (can be done in the mailing list list administration page, but must be done by the admin) Greetings, -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] totally abandoned rails
On 28.07.2010 12:06, Ed Loach wrote: Sorry, I mentioned it now, then. I don’t like web forums, so wouldn’t move if the email list closed. Any sensible reasons for this? LMB -- Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] totally abandoned rails
On 28.07.2010 12:41, Heiko Jacobs wrote: Michał Borsuk schrieb: Definitely. Forum is way better than a mailing list, a threaded forum is even better. I'm reading all OSM mailing lists threaded using thunderbird and news.gmane.org Thanks! ...and the group is called gmane.comp.gis.openstreetmap.transit For the record: news:news.gmane.org/gmane.comp.gis.openstreetmap.transit Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] totally abandoned rails
On 28.07.2010 14:56, Heiko Jacobs wrote: Michał Borsuk schrieb: levelled seems to be a good idea. I'd stick to what is being used now. There is be nothing official (noted in http://wiki.openstreetmap.org/wiki/Key:railway ) for vanished ;-) rails ... There might be some undocumented tries to tag this spread over the whole planet. I found in tagwatch just only 25x railway=historic_path in Sweden and 37x historic:railway=rail in Germany the second ones leave the name space and the first one ... M... also not really suitable to construction/.../disused/abandoned I just played around in dict.leo.org http://dict.leo.org again and found vanished LOL! You want to say, that disappeared might be a better word? ;-) Without getting too much into the linguistic issues, I'd support the Swedish railway=historic_path for anything further than stillgelegt (English abandoned?), that is either with track, or without, but not yet turned into a bike path (or anything similar). But let's wait for others to comment. Mueck -- Greetings, LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] tagging stops served by multiple routes by more than one transit agency
On 24 July 2010 12:59, Gregory Arenius greg...@arenius.com wrote: When I tag bus stops with multiple operators I add the operator name to the route_ref. In the above example of HART and USF I would tag the stop as: operator=hart;usf hart_route_ref=5;12 usf_route_ref=A;C I always include route information in my bus stop tagging. I think it is more than just placeholder information. For instance, an application showing bus stops on a map should allow you to hover over the stop and see which routes it serves. That's presently done by adding the bus stop to the relation[s] containing the bus lines. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed additional tags for bus stops and an import of San Fracisco data
On 15.07.2010 09:53, Peter Miller wrote: This is a problem when it comes to creating clear map rendering where one wants to snap the stop to correct side of the correct road and not left them floating as they are currently. An additional complication comes when one wants to position the symbol correctly when the road widths on the rendering are exaggerated requiring the node to be nudged sideways for it to not appear within the junction itself. I propose that we formalise a couple of NaPTAN tags into the main bus stop schema and try these with a SF import. As far as I know, the current trend is to add the bus stop to the lines (relations) which stop there. http://www.openstreetmap.org/browse/node/354589964 Does that fit your situation? Regards, LMB -- Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed additional tags for bus stops and an import of San Fracisco data
So you change the associated bus stops. Can be done. Greetings, LMB On 15.07.2010 14:50, john whelan wrote: I don't think this is a good idea as Ottawa certainly changes the bus routes or lines four times a year. Some lines are stable for many years but many are not. The stops themselves remain in the same place its just the buses that serve them change their numbers and routes. Cheerio John As far as I know, the current trend is to add the bus stop to the lines (relations) which stop there. http://www.openstreetmap.org/browse/node/354589964 Does that fit your situation? Regards, LMB -- Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit -- Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed additional tags for bus stops and an import of San Fracisco data
On 15.07.2010 15:02, john whelan wrote: You are talking about verifying 10,000 bus stops four times a year. No, I'm talking about changing those when the bus lines change. Not all bus stops have to be reviewed. Greetings, LMB -- Jesli czytasz ten podpis, to znaczy że obijam się w biurze :: LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed changes to oxomoa schema [part 1]
On 29 June 2010 07:29, Roland Olbricht roland.olbri...@gmx.de wrote: those two would meet in point A, from which the branch line sets off/rejoins the core line. So a hypothetical future route-finding algorithm would follow different_route to its end, upon meeting core line it would continue along. It just doesn't work. Having an unordered relation or even mapping both directions within the same relation leads to ambiguities. Just two examples: http://www.openstreetmap.org/?lat=51.29314lon=7.21791zoom=17layers=B http://www.openstreetmap.org/?lat=51.29314lon=7.21791zoom=17layers=B000FTF Bus service 618 southbound comes on the Gennebrecker Str. from the north, loops into Agnes-Miegel-Straße and then proceeds on the Gennebrecker Str. to the south, always. 618 northbound passes on the Gennebrecker Str. from south to north only. From where the line split, point 768803020, to where they meet again, 768803016, they would be tagged backward and forward, or any other appropriate pair of tags. Judging by the direction, routing software would either follow one or the other. Now I would like to see how you discriminate this case from the case where 618 passes through the loop in both directions (so does line 624) if you don't have an ordered relation. I'm not completely sure what you mean without seeing it graphically, but logically I cannot see what can't be done by tagging that is now done with two separate routes. The question is whether it is easier to enter and manage, and I maintain that tags are easier than two relations. In Oxmoa it is very simple: you map what the bus does. It is simple as a data structure, but neither simple nor efficient for the user. In the 21st century software is adjusted to users, not users forced to adjust to software. What I am opting for is simpler machine-user interface, easier experience for users. What it is now is clearly a mess. Look at the number of amendments made to my original post: all that info is probably somewhere there, but how does a beginner find and compile it? Second example http://www.openstreetmap.org/?lat=51.255881lon=7.150008zoom=18layers=B000FTF Line 643 passes in both directions from Morianstraße on the left to Islandufer on the right. But in eastbound direction, it passes through platform 5, in westbound direction is passes through platform 4. This is important, because buses in both directions are at the stop at almost the same time. In Oxmoa, it is again simple and intuitive: Raw XML simple and intuitive? We may be speaking a different language here. I am talking about user experience. User = map editor. Not a programmer by definition. Second example http://wiki.openstreetmap.org/wiki/Opening_hours http://www.openstreetmap.org/?lat=51.255881lon=7.150008zoom=18layers=B000FTF Line 643 passes in both directions from Morianstraße on the left to Islandufer on the right. But in eastbound direction, it passes through platform 5, in westbound direction is passes through platform 4. This is important, because buses in both directions are at the stop at almost the same time. Not difficult. You'd put direction_to and direction_from tags to the bus stop and the route. Same goes for lines with variants, you can have forward_variant_a, backward_variant_a, forward_variant_b, backward_variant_b. Believe me, my Verkehrsverbund is not any different from yours. We face the same problems. Nonetheless, there are still things that Oxmoa leaves open. For example, there is no specification how to store approximate journey time. But the usage of ordered relations and the separation of directions is one of the strengths of Oxmoa, not a weakness. Please convince me that tagged routes are more difficult than dealing with a nested collection of multiple routes. Possibly I am misled in my belief that editing/rerouting multiple variants as multiple relations is just time-consuming. For me now the system seems unnecessarily complex. B-trees are not easy to comprehend to common users-editors, who are not, by definition, programmers. Concerning Potlatch ... It's just not open. You can easily contribute to JOSM by writing a plug-in or even submitting a patch. Potlatch makes the life for the programmer much more difficult; This is about editors, not programmers. I'd suggest that we use the discussion page http://wiki.openstreetmap.org/wiki/Public_Transport of the wiki once the server is back again to write a consistent, easy-to-use and easy-to-implement standard. I second that opinion. Email exchanges are a bit difficult when they grow. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed changes to oxomoa schema [part 2: stops]
On 29.06.2010 09:33, Tiziano D'Angelo wrote: +1 On Tue, Jun 29, 2010 at 08:23, Arun Ganesh arun.plane...@gmail.com mailto:arun.plane...@gmail.com wrote: Shouldn't we keep the schema to something that is easily compatible with the Google Transit GTFS format instead of developing something different all together? Doesn't GTFSsuggest one location for one unique stop name, whereas we want each physical location belonging to a name as a separate point? (this does not suggest incompatibility, just an overlay on GTFS) LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] OSM Transit platform: call for action
On 28 June 2010 14:14, Tiziano D'Angelo tiziano.dang...@gmail.com wrote: Hello everybody! In the past months, as you probably read here, I mapped almost entirely the bus network of Padova, Italy. Abstract: A new standard, better suited but compatible with what has been done is needed. Hi! I have also mapped almost my entire area, and I have found that the option of combining OSM with bus timetables is not presently feasible. There are the following problems: * missing important details. Just like you did, I skipped some strange variants such as special Sunday early morning runs, or collective taxis (because they tend to go wherever the people want). Also, there is at present no provision for implementing the time of bus lines, so at present one could be advised to take a night line at daytime. * no approved standard. Should the stops be within the line as a point, or as their physical location shows? Should we map a separate relation just for the branch of the line from the split, or for the entire line? What is the point of having two relations for two directions in Europe? IMHO Oxomoa seems way too difficult for beginners, and it's overblown. The overhead needed to maintain the standard is WAY too big. I have calculated that sticking to the standard would cost me 25 to 50% more time, with just marginally better results. The time to understand the standard is also not to be ignored. A new standard, better suited but compatible with what has been done is needed. * negligent edits (unintended 'vandalism'). I keep needing to repair the ca. 80 bus lines that I have mapped, that is some 50 regional lines times each 15-30 km, plus city lines, much easier to maintain. I practically need to repair the bus lines all the time, as when I finish, I might just as well start over. Typically people just remove small sections of the line when they map another relation, must be a bug of one of the editor. Nevertheless, I am having trouble maintaining the collection, and there is no queue of editors waiting to help. To sum it all up, at present I decided to put the lines on the map just so that openbusmap.org (ÖPNVkarte) can show them, but details must wait. I suggest that you just remember what you want to introduce, and I suggest that presently we work on slimming the oxomoa suggestion to make them scale better, that is to make them accessible to beginners, as well as usable for pros. In my opinion OSM is no Wikipedia, where one can just click Edit and produce sensible results. We need to step out to prospective editors, make the experience less of a hell for beginners. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] OSM Transit platform: call for action
On 28 June 2010 18:39, Vincent Pottier vpott...@gmail.com wrote: Le 28/06/2010 17:37, Michał Borsuk a écrit : * no approved standard. Should the stops be within the line as a point, or as their physical location shows? If I have well understood the question, I think that a bus stop must be mapped where it is physicaly, and not on the line. So at a bus stop you usualy have two nodes one on left, one on right. Sure, this is my logic. But the currently most applied oxomoa standard states otherwise. Should we map a separate relation just for the branch of the line from the split, or for the entire line? For the entire line. It is easy to make a copy of a relation in JOSM, a to fulfill it. 1. Aren't they going to appear as separate lines in openbusmap (ÖPNVkarte)? Or do they have to be nested in another relation, which is clearly against the intention of the authors of relations? 2. JOSM in hands of beginners = disaster (if they ever get past the installation stage). Personally I try to avoid JOSM as much as possible. Personal preferences. What is the point of having two relations for two directions in Europe? IMHO Oxomoa seems way too difficult for beginners, and it's overblown. The overhead needed to maintain the standard is WAY too big. I have calculated that sticking to the standard would cost me 25 to 50% more time, with just marginally better results. The time to understand the standard is also not to be ignored. A new standard, better suited but compatible with what has been done is needed. I feel also that the Oxoma schema is sometimes too eavy. But for maintenance two relations, one in each way, is easyer to maintain for me. Because the road taken in the two ways are very often different. Surely if so! But if the difference is such that one direction goes on one side of the avenue, and other direction of course goes on the other side of the trees, then the road's one_direction tag kind of makes it clear where the bus goes. If we intend to show routing on OSM in the future, then missing pieces of information that would have to be entered by hand can be dealt with by software. That's why I asked about a tree-structured lines, e.g. RER. Presently one has to map one entire line, then copy it as another version. And what if I don't know the entire line? Do I copy the non-complete version and then deal with extending 8 identical relations towards their terminus? Or if the relation is remporarily re-routed due to construction, do I also have to play with all versions? Having ordered members in the relation is an easy way to find a mistake in JOSM. Is JOSM an integral part of OSM, or is it only one of the three editors? Each editor is responsible for ca 1/3 of edits, and I would be really hesitant to force upon users features that can be done only in JOSM. Personal preferences of editors are not important? With two stops (one on each side of the road) it is easier to fill the right relation with the right stop. It was just a rhetoric question to show how disconnected from reality oxomoa can be. As a principle I dislike criticizing without providing an alternative, so I would be very interested in having a discussion on improving the schema. I strongly believe that it is possible to improve it without damaging compatibility. The schema could seem too difficult for a beginner but: The beginners don't start mapping with a transport network. The reality is complex. Surely total beginners should not be allowed to mess with maps, this is not wikipedia. But having mapped 97% of lines in my area I still consider myself a beginner. Maybe not a total one, but still, I find the learning curve a bit complex. Do we want to keep the project elitist? The tools are more and more handful. Really? I know three: potlatch, merkaartor and josm. Are there any others, excluding plugins? I'm sure that the Google specifications are usually enough. How can we map them ? Can you please elaborate what Google specifications are? I think I have heard of such, but failed to find them. Any hints? To sum it all up, at present I decided to put the lines on the map just so that openbusmap.org (ÖPNVkarte) can show them, but details must wait. I suggest that you just remember what you want to introduce, and I suggest that presently we work on slimming the oxomoa suggestion to make them scale better, that is to make them accessible to beginners, as well as usable for pros. In my opinion OSM is no Wikipedia, where one can just click Edit and produce sensible results. We need to step out to prospective editors, make the experience less of a hell for beginners. With a good documentation, maybe the beginners would understand the schema. But you are right, the Oxoma page is not synthetic! I am repeating myself, but I seem to be a bit newer than you people are, so let me share my experience: the learning curve to producing a sensible network is a hell. The worst
Re: [Talk-transit] OSM Transit platform: call for action
On 28 June 2010 18:58, Claudius Henrichs claudiu...@gmx.de wrote: A Just a comment on the complexity of the public transport scheme by Oxomoa: You could get along with a very basic variant already and thus be standard-conform: - Just put all way segments and the stop_positions in a relation with from=... and to=... - Clone the relation in JOSM and reverse the order and switch from=... and to... - put those two relations in a line=bus/tram relation and you're done. Not much more effort. Doch, or on the contrary. First of all, there is the talk of JOSM again, which itself has a steep learning curve. I think we possibly don't understand each other: I don't have a problem with difficult tools, I have enough courage to learn them, but I *need helpers quickly*. I need to assign simple things to simple people, beginners with almost zero knowledge, so JOSM is out of question, potlatch is the ultimate medium. Potlatch allows mapping, but not much more. The answer is not necessarily to go to a more difficult tool, but maybe in the other direction of easier rules. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed changes to oxomoa schema [part 1]
On 28 June 2010 20:35, Richard Mann richard.mann.westoxf...@googlemail.comwrote: It's probably worth knowing what Potlatch2 will be capable of. Presumably it's relation-editing will be (is?) much improved, and the difficulties with implementing the Oxmoa standard will mostly go away. Oxomoa is not only complex, but time-consuming. And while Potlatch2 may allow better relation editing, it does not solve the problems completely. It will still be time-consuming and limiting for experienced users, and complex for beginners. How does one move (on the map, e.g. for construction works)) a relation containing other relations in an editor, anyway? Is it enough to move the parent relation, or is one required to move all child relations? I don't know if you people share my problems, but I have been looking for potential candidates to help editing, and the problem is that for most people the learning period is too long (the learning curve is too steep). Since we cannot change people, we should bend the rules, and that's what I am suggesting here: make it official. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed changes to oxomoa schema [part 1]
How would you enter this core line? It would be a relation with the ways and stops of the course again. So you would need the core line be a member of the branches and exception relations again. Example: Core line route=bus ref=100 additional_tag=[empty] branch line route=bus ref=100 additional_tag=different_route those two would meet in point A, from which the branch line sets off/rejoins the core line. So a hypothetical future route-finding algorithm would follow different_route to its end, upon meeting core line it would continue along. Since we already have a collection or a tag stating to which public company/ticket area a line belongs, line ref should be enough to uniquely identify a line (route). -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed changes to oxomoa schema [part 2: stops]
To Claudius and Shaun: why don't we have those rules written? -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
