Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Am 14.01.2011 02:16, Tobias Knerr: Dominik Mahrer wrote: 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. I'm not very happy with the extensive use of relations. Especially nested relations strongly suggest that the level of complexity is beyond what's appropriate for a crowd-sourced project like OSM. The most prominent issue are stop area groups. The necessity of these has already been questioned. I, too, tend to think that determining them algorithmically would ultimately be a better choice. Removing the nested relations for stop area groups would eliminate one of the most complex concepts from the proposal, making it more accessible to mappers. Additionally, I suggest to reconsider the requirement to use stop area relations even in simple cases Many bus stops are very straightforward: They consist of usually two platforms with a common name. This name is usually unique within a range of several kilometres and, if tagged to the platform elements, could therefore be used instead of a relation to identify the components of the stop area. +1 I don't think the stop_area-relation for the vast majority of simple bus, tram or train stops is necessary. öpnvkarte.de and other sites working with the data prove that you can reliably determine nodes belonging to one stop via easy algorithms/preprocessing. Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Dominik Mahrer wrote: 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. I'm not very happy with the extensive use of relations. Especially nested relations strongly suggest that the level of complexity is beyond what's appropriate for a crowd-sourced project like OSM. The most prominent issue are stop area groups. The necessity of these has already been questioned. I, too, tend to think that determining them algorithmically would ultimately be a better choice. Removing the nested relations for stop area groups would eliminate one of the most complex concepts from the proposal, making it more accessible to mappers. Additionally, I suggest to reconsider the requirement to use stop area relations even in simple cases Many bus stops are very straightforward: They consist of usually two platforms with a common name. This name is usually unique within a range of several kilometres and, if tagged to the platform elements, could therefore be used instead of a relation to identify the components of the stop area. Tobias Knerr ___ 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 Tue, 11 Jan 2011 20:21:41 +0100 schrieb Michał Borsuk michal.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. 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? 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. I am open to change my proposal. I am also open to approve a completely different schema. 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! Albin (Almich) ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
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. 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. ___ 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
On 12.01.2011 09:52, Michał Borsuk wrote: 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. 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. It is not our primary aim to serve some kind of mainstream. It is to collect any geographical data that could be useful to somebody. And yes, somebody includes blind people, too. cheers ant ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed Feature - 2nd RFC - Public Transport
Richard wrote: put unified_stoparea as an elaboration rather than an alternative; I hope it doesn't spark an edit war). It might. Unified_stoparea is flawed in that it isn't backwards compatible as it contradicts the documentation for highway=bus_stop (node beside way) to use it for the stopping position (rather than the platform). This is why the proposals that use public_transport tags are immediately better. Adding bus stop nodes is one of the simple things new mappers can do; more advanced users can add them to the appropriate relations later. Ed ___ 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
On Wed, Jan 12, 2011 at 12:21 PM, Ed Loach e...@loach.me.uk wrote: Unified_stoparea is flawed in that it isn't backwards compatible as it contradicts the documentation for highway=bus_stop (node beside way) to use it for the stopping position (rather than the platform). This is why the proposals that use public_transport tags are immediately better. You have to make sense of all the main existing schemas already (since they are unlikely to disappear). The main requirement is understanding what they are and how to tell them apart, not to try to standardise them (and especially not to standardise by multiplying the number of tags several-fold). Richard ___ 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 12/01/2011 11:10, Albin Michlmayr a écrit : I pretty much came the same way Dominik did. I am also a public transport fanatic. 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. I like precision too. But on that point I think it's a mistake to cut roundabouts for routing. Included in a route, a roundabout has an entry point, a outgoing point and a oneway circulation. So it is very easy to comput the part of the roundabout used by the route without cuting it. A roundabout is to be considered as a cross, just a big cross. I have stopped cutting them when someone explained this easy comput. I think roundabouts would be cut only when part of them are bridges. -- 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
On Wed, Jan 12, 2011 at 2:50 PM, ant antof...@gmail.com wrote: 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. Another mapper will come and turn it into a stop area and update the route relations. But if applications can cope with only having an unordered relation and bus stop pole nodes (or indeed just tram_stop centroids), then why clutter the map with lots more tags and info that the applications can perfectly well derive for themselves 99.9% of the time? You should only supply the extra info for the 0.1% of the time when it can't readily be derived. Richard ___ 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
On 12.01.2011 16:00, Richard Mann wrote: On Wed, Jan 12, 2011 at 2:50 PM, antantof...@gmail.com wrote: 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. Another mapper will come and turn it into a stop area and update the route relations. But if applications can cope with only having an unordered relation and bus stop pole nodes (or indeed just tram_stop centroids), then why clutter the map with lots more tags and info that the applications can perfectly well derive for themselves 99.9% of the time? You should only supply the extra info for the 0.1% of the time when it can't readily be derived. I don't know what applications you have in mind, but if they can do more than draw some lines on a map, this sounds like black magic to me. 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? cheers ant ___ 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 12.01.2011 16:40, Michał Borsuk wrote: 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. There are some minimum requirements that the data should meet in order to make it easy. In particular, it should resemble the network structure of a PT network, i.e. bus and tram stops acting as nodes that connect bus and tram lines with each other. 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. So the point of stop area relations is to prepare the data to be interpreted as a network and thus to make routing... easy. cheers ant ___ 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 Wed, Jan 12, 2011 at 4:07 PM, ant antof...@gmail.com wrote: So the point of stop area relations is to prepare the data to be interpreted as a network and thus to make routing... easy. Stop areas are about linking the stop (notionally on the footway) to the road. Or they are about linking platforms with the same name. You can do that as you go along. The stopping_position and stop_area relation are just clutter. If you know the latlons of two stop areas, you can work out how to get between them by running your pedestrian routing algorithm. Marking footways between stops (other than the ones you can assume are adjacent to any roads not marked with footway=no) is more useful than linking the stop areas into a group and implying there is free access between any stop area within it. Basically you use relations to link objects which have a geographical relationship - not just a geographical proximity. There's sense in adding group objects if data relates to the group (eg to a station and not to it's individual platforms), but I'd find a convenient node or area to hold the info, not put it on an unnecessary relation. And if the information is relatively simple (eg a name), I'd settle for putting it on all the nodes, rather than create an artificial single object to hold it. Richard ___ 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
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
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] 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
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
