Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
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. We are not mapping merely for the ability to draw a map of the bus routes, but also to allow PT routing eventually. Jo 2011/1/11 Michał Borsuk michal.bor...@gmail.com 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 Regards Teddych Extending my previous post: I've given a quick look to the proposal, and it seems to combine what is now used, with what oxomoa had proposed. Oxomoa has been criticized as unnecessarily complicated, and you seem not to have addresses this issue. What is now proposed is in my opinion worse that what was before, exactly because it does not address oxomoa's issues. The proposed schema is more complicated, i.e. instead of one point for a bus stop, three (!) are proposed: one for the place where the bus stops, and two platforms, if they exist. Moreover, the unnecessary in 99% of cases practice of using two relations for each line is kept, two relations (one in each direction), plus there's a mother relation, the so-called route master. A few important issues arise: * First of all, *Potlatch** does not allow the creation of nested relations*. Potlatch, when I last looked at statistics, was responsible for 1/3 of all edits. How do you plan to address this issue? * Secondly, the creation of such relations is neither easy, nor quick. It may discourage new mappers as *the learning curve would be much more difficult*. And it may be perceived as an unnecessary and discouraging. Not the way to go if we want to increase the quality of the map, which has to be done by humans. * Thirdly, Please again *elaborate on the efficiency* of such a solution, because it seems that the small gain in quality is offset by the huge loss in time necessary to achieve this. Also, maintaining lines in *three *relations will be hell: any change of the line will require at least *double* work. Is there really a good reason for the double work? There have been other proposals how to deal with lines that have different trace in each direction, and those were easier than one relation in each direction (disclosure: one proposal was mine) As for the examples, all those below seem to be coming from you: http://www.openstreetmap.org/browse/relation/1342798/history http://www.openstreetmap.org/browse/relation/1244886/history http://www.openstreetmap.org/browse/relation/1281532/history Is there anybody else using it? I'd like to see more examples out of Germany or Switzerland, bitte. -- 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 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.11 10:42, schrieb Sander Deryckere: Before this becomes standard, could someone please make a script to transform one tagging scheme in an other? Not for uploading, just because apps have difficulties to support all the different tagging schemes. And after all, we want the data to be useful. We do not map for any specific app. The german öpnvkarte deals with bus routes regardless of the scheme they are tagged by; so other apps should be able to do this on their own. Greetings, André Joost ___ 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.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 Greetings, André Joost ___ 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.11 12:15, schrieb Michał Borsuk: So I vote for a simple solution to the existing problem. Simple already eliminates anything that resembles oxomoa. And what Teddych proposed is even more complicated. Ok, put every highway=bus_stop a specific bus service is serving in a relation tagged name=Bus xy. Is that simple enough for you? If not: Only put a note=Bus xy on those nodes. Relations *are* complicated, but no one *has* to use them. Greetings, André Joost ___ 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 11.01.2011 12:15, Michał Borsuk wrote: 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. Can't comment on anything else in this discussion, but in the part of Northern Germany where I live, a lot of buses use different routes depending on the direction. I think the main reason is one way roads all over the place. Christian ___ 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
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 11.01.11 15:00, schrieb Michał Borsuk: 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. Line 24 has only one relation for each direction. 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? This role thing is much more complicated than different relations. Does forward mean the direction of the bus line, or that of the way element in OSM? *That* is what confuses new users. Furthermore. The Platforms are different for the two directions. If you take this node: http://www.openstreetmap.org/browse/node/428573541 you see that busses to Weststraße, Kelmis Bruch and Uniklinik are stopping here. if you want the other direction, you have to change the platform. With one relation for every service, you dont get that information. Grrets, André Joost ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Le 11/01/2011 12:15, Michał Borsuk a écrit : 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. Hum ! It seems you have not mapped busses in Besançon... where it is very rare that a bus come and go by the same way... -- FrViPofm ___ 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] Proposed Feature - 2nd RFC - Public Transport
On Tuesday 11 January 2011 17:01:32 Michał Borsuk wrote: This role thing is much more complicated than different relations. Does forward mean the direction of the bus line, or that of the way element in OSM? *That* is what confuses new users. Then all we need is to clear that confusion. Yes, we need to explain it again and again and again and again, because it is too difficult to understand for a significant number of new users. So if we just dump it we can stop explaining. -- m.v.g., Cartinus ___ 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
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Le 11/01/2011 20:21, Michał Borsuk a écrit : IMHO it has to be simple and scalable first of all. Scalable in this case would mean that an _average_ Joe can learn some parts of it and start mapping, then he can learn more (e.g. termini, large transfer stations), and proceed from simple to complicated. I don't understand you. The scheme is scalable. the new comer will not start mapping platforms, stop_areas... He will start mapping a lonely route. He will discover that the scheme is richer and his needs deeper, he will discover other towns well mapped. He is not stupid... He will learn 'poco a poco' how to use the scheme... How do I knwo this process ? Because they are more and more mappers un France, and more and more tonws with bus routes, and the mappers already use a scheme that is not so different. In don't understant why you don't admit that mappers already are able to learn a scheme. I see it ! -- FrViPofm ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Le 11/01/2011 18:25, Michał Borsuk a écrit : On 11 January 2011 18:06, Albin Michlmayr alm...@gmx.at mailto:alm...@gmx.at wrote: Am Tue, 11 Jan 2011 15:15:27 +0100 schrieb André Joost andre+jo...@nurfuerspam.de mailto:andre%2bjo...@nurfuerspam.de: Am 11.01.11 15:00, schrieb Michał Borsuk: 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? This role thing is much more complicated than different relations. Does forward mean the direction of the bus line, or that of the way element in OSM? *That* is what confuses new users. I totally agree! For me it was a very timeconsuming search when I tried to figure out how to set the role of an element in the route. I found contradicting wiki pages YES! that's the point, and that's been said before. Make the wiki pages clear, call it standard, and there you go. When a new comer is mapping on JOSM, with a good interface, he has not his eyes in the wiki. It is easier for him to manage a one way relation, and an other one way relation. For those loving learning curves : the curve is less hard ! ;-) an when I found the Oxomoa scheme with different relations for each direction I thought this is a quite simple solution for the confutision. Again, how do you implement it in Potlatch? It is an other matter. We don't map for the editors. And Potlatch evolves. JOSM did it. How about changing the route temporarily? How about Paris RER, which has several trains with different destinations? Do we produce 12 relations for line X, which has 6 variants? Possible, but crazy. OK, the new comer will do maintenance on potlatch for the French RER ? They are people with more skill, and other tools for that. -- FrViPofm ___ 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.11 17:01, schrieb Michał Borsuk: Am 11.01.2011 15:15, schrieb André Joost: Furthermore. The Platforms are different for the two directions. If you take this node: http://www.openstreetmap.org/browse/node/428573541 you see that busses to Weststraße, Kelmis Bruch and Uniklinik are stopping here. if you want the other direction, you have to change the platform. With one relation for every service, you dont get that information. 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. And on the time-table you wont find a hint *where* the right platform is. A public transport router with audio output would do, if it has the data. We could work towards this aim. Greetings, André Joost ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
