[Talk-transit] OSM Transit platform: call for action
Hello everybody! In the past months, as you probably read here, I mapped almost entirely the bus network of Padova, Italy. Result: all the stops are there, almost all route relations (except some variations of a route which happen once a day), now duplicating them with both directions). I presented my work at OSMit 2010 including a review of the different tools available with their pro and cons (slideshow available in Italian here: https://docs.google.com/present/edit?id=0AX90JH2rM34XZGR6cGJoczlfODU3anM2emgzcAhl=it ). Fellow mappers started mapping other towns in Italy (Ferrara, Milan), some tools were improved a lot: Roland Olbricht added loads of features to the sketch generator, City Advisor and Metro applications for smartphones respectively added features to easily import a list of stops with name and location from OSM in CSV format or updates of the database with my data... But I realized there was not (or if there is I didn't find it!) a unique open source platform for public transport but many separated tools, all with their pro and cons...A unique platform (as Google Transit) would be a killer application for public transport data on OSM. Imagine to: - view a map of the entire network of a specific area (OPNVKarte, OSMTransport, LatLon) - specify the desired level of detail showing one, two...all routes (OSMTransport) and possibility of showing different renderings - click over a line on the map/select the line from a list and see the sketch of that line with all the stops and with the desired level of details as correspondences, P+R, train stations, etc... (Roland Olbricht Sketch Generator) - click over a line on the map/select the line from a list to see its operating hours, frequency, timetables, wheelchair accessibility and other important details (no OSM-derived website supports this at the moment) - have door-to-door/stop-to-stop routing using OSM data + timetables or frequency information (no no OSM-derived website supports this at the moment - for example of competitors: Google Transit, http://imetro.nanika.net) - download the data (database, timetables, maps) for use in mobile phones with designed applications (for example City Advisor for Windows Mobile) or provide a simplified interface for mobile browsers or SMS-based requests. - provide local transport authorities tools to render timetables, sketch of routes, proximity maps of each stop for internal use or for users at each stop all of this on the same platform/website! Unfortunately, I don't have the programming skills to build such a platform, but I'm writing here to see if any of you is interested either in the programming either (like I would do to contribute to the project) in the testing, support, design, translations and documentation.The project could be then advertised through local representatives at local transport authorities so they can adopt it. In these months I aquired expertise in this field and have found interesting contacts with possible partners in this project, so I would be delighted to give my best to make this project possible. A test city could be Padova, whose local transport authority doesn't have such a tool and which has a complete mapping of stops. Waiting for your reactions :) ciao Tiziano ___ 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
Le 28/06/2010 14:14, Tiziano D'Angelo a écrit : Hello everybody! In the past months, as you probably read here, I mapped almost entirely the bus network of Padova, Italy. Bello lavoro ! Nice work ! Could you fill the wiki page. Some relations seem not present so it is difficult to find the model you took. I presented my work at OSMit 2010 including a review of the different tools available with their pro and cons (slideshow available in Italian here: https://docs.google.com/present/edit?id=0AX90JH2rM34XZGR6cGJoczlfODU3anM2emgzcAhl=it https://docs.google.com/present/edit?id=0AX90JH2rM34XZGR6cGJoczlfODU3anM2emgzcAhl=it). Interresting. Could also be linked on the wiki page. Imagine to: * view a map of the entire network of a specific area (OPNVKarte, OSMTransport, LatLon) * specify the desired level of detail showing one, two...all routes (OSMTransport) and possibility of showing different renderings * click over a line on the map/select the line from a list and see the sketch of that line with all the stops and with the desired level of details as correspondences, P+R, train stations, etc... (Roland Olbricht Sketch Generator) with links on correspondences. * provide local transport authorities tools to render timetables, sketch of routes, proximity maps of each stop for internal use or for users at each stop provide transport files such as http://code.google.com/intl/fr/transit/spec/transit_feed_specification.html Allready we can build some of those files (stops.txt, routes.txt, trips.txt, shapes.txt) from OSM data. The excercie of creating such files will strenghten the model. In these months I aquired expertise in this field and have found interesting contacts with possible partners in this project, so I would be delighted to give my best to make this project possible. A test city could be Padova, whose local transport authority doesn't have such a tool and which has a complete mapping of stops. I have writen a little program in python that analyse a GPX to find stops and times. But I can make it run only on my computer. It could be a tool to help gathering data. The code is available on demand. 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. 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. 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. Having ordered members in the relation is an easy way to find a mistake in JOSM. With two stops (one on each side of the road) it is easier to fill the right relation with the right stop. The schema could seem too difficult for a beginner but: The beginners don't start mapping with a transport network. The tools are more and more handful. The reality is complex. It is longer to build but easier to maintain. I'm sure that the Google specifications are usually enough. How can we map them ? * Nevertheless, I am having trouble maintaining the collection, and there is no queue of editors waiting to help. The problem of maintaining elements of relations in Potlatch (and keeping them ordered) have been talked with the authors. To sum it all up, at present I decided to put the lines on the map just so that openbusmap.org http://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 ! -- FrViPofm ___ Talk-transit mailing
Re: [Talk-transit] OSM Transit platform: call for action
Am 28.06.2010 17:37, Michał Borsuk: On 28 June 2010 14:14, Tiziano D'Angelo tiziano.dang...@gmail.com mailto: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. I think the first step is getting hold if unique station identifiers. You would need to check if something like that exsists for your country or at least transport association. From than on it's quite easy to go forward. See http://wiki.openstreetmap.org/wiki/Naptan * 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. 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. In later expansions you might add the public_transport=platform and stuff The wiki article is indeed very long, but as a starter it can be reduced to the above :) Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] OSM Transit platform: call for action
Le 28/06/2010 18:58, Claudius Henrichs a écrit : Am 28.06.2010 17:37, Michał Borsuk: On 28 June 2010 14:14, Tiziano D'Angelo tiziano.dang...@gmail.com mailto: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. I think the first step is getting hold if unique station identifiers. You would need to check if something like that exsists for your country or at least transport association. From than on it's quite easy to go forward. See http://wiki.openstreetmap.org/wiki/Naptan * 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. 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=... - click on the order button on the relation tool in JOSM - 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. In later expansions you might add the public_transport=platform and stuff The wiki article is indeed very long, but as a starter it can be reduced to the above :) Claudius Thank for this very short synthesis !-) Said like that, it is easy also for beginners ! Sometimes the realty is a little bit more complicated. But it is a good and solid start ! -- FrViPofm ___ 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]
Please find my comment on core lines below. Am 28.06.2010 19:54, Michał Borsuk: -- *ISSUE RAISED: * change to the way more complex lines are mapped, that is the introduction of tags or roles instead of nested collections* Present status: For lines with variants, each variant needs a separate relation Problems: * Nested relations are difficult to impossible to manage in potlatch, * They are difficult to understand * Creating a variant requires the entire route to be duplicated: impossible in potlatch * Extending or rerouting such lines can be hell * High risk of introducing a mess by inexperienced users (I think). I actually think my proposal is more error-resistant. * It's time-consuming! It's easy to duplicate a line once one knows JOSM, but how much time does it take to get JOSM running, from downloading to having results? A lot. *Proposed change: introduction of a core line, that is shared by all variants in all directions, and having the branches or exceptions in one direction tagged appropriately. Core line would have no tags, branch lines would be tagged arbitrarily. * Result: lower consistency of the data entered, but much less time needed to enter and manage lines. The mess can be easily dealt with by server-side software presenting data to users. If one wants a route from one's side branch of a line, one looks down the tagged branch up to the main branch, and then up to the stop needed. Nothing hard to implement. It's the 21st century, I believe that we don't have to rely on simple parsers that take nothing else but point-to-point connections. 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. Probably I haven't fully understood how you would see your core lines respresented in the OSM data model. Pozdrowienia, Claudius ___ 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]
Oxomoa is suggesting bus stop on the way only for the most basic bus stop (think of a bus stop on a crossing on the country side with just a sign). If you have a more advanced bus stop with waiting positions for passengers on both sides of the street you add a public_transport=stop_position on the way *and* add a public_transport=platform node/way on the location you are proposing (e.g. where they are). This solution allows to fulfill the data requirements of routers you described. More details in the graphics here: http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema#Examples_for_the_application_of_the_model_for_stops Claudius Am 28.06.2010 20:07, Michał Borsuk: *ISSUE RAISED: * map bus stops to their physical location, not a point on the route/street * Present status: If I understand correctly, oxomoa suggests that the bus stop data (name, unique number, etc.) be entered as properties of a point on the route/street. Problems : * Lines often have stops that are quite far apart for each direction * This prohibits proper routing (GPS + walking), * this system is not very intuitive I find. *Proposed change: bus stops to be mapped exactly to where they are, and to be added to relations * Result: * better routing results e.g. one wants to find a correct way to the bus stop, and not to the average point somewhere between two stops of the same name in either direction. * more intuitive system - easier learning curve for new users. Influence on possible future software solutions: minor. May require all the stops on the route to be ordered based on their geographical location, as opposed to their place on the route (the latter is easier). Comments: I have seen this system very often implemented - two bus stops on each side, so my suggestion is just to codify the situation for future editors. Hope this is not too much at once, for more is to follow. 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 ___ 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]
Am 28.06.2010 22:16, Michał Borsuk: More details in the graphics here: http://wiki.openstreetmap.org/wiki/User:Oxomoa/Public_transport_schema#Examples_for_the_application_of_the_model_for_stops The link you provided is a very good example of oxomoa's weakness. While the first simple bus stop is clear, for two bus stops I must create a stop_area. How do you do that? (the example is not clear enough) And more importantly, what for? Is the gain worth the extra time, which is considerable? Most of the time a relation for public_transport=stop_area is not necessary e.g. if you have two crossing bus lines which have the same name. In this case the router can easily determine that there's a changing location. But if you have more infrastructure like a taxi stand (See here: http://www.openstreetmap.org/browse/relation/152809 ) or a ferry terminal it's sometimes necessary to create a stop_area. But no need to worry: Don't do it if you think it's too much time. Eventually someone else does it. In OSM you don't have to do everything yourself. And you don't need to do the whole 1000km² yourself :) Do you have a map link to the area you are mapping public transport data? Maybe a complex example which took you time to tag? Claudius ___ 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]
In the UK as part of the Naptan import we already have decided that bus stops must be marked exactly where they are on the ground and added to the route relation of the bus route. Shaun On 28 Jun 2010, at 19:07, Michał Borsuk wrote: Hi everybody again: This time I'd like to propose a smaller change, but this one may break compatibility with oxomoa - it has been, however, already commonly implemented. ISSUE RAISED: * map bus stops to their physical location, not a point on the route/street Present status: If I understand correctly, oxomoa suggests that the bus stop data (name, unique number, etc.) be entered as properties of a point on the route/street. Problems : * Lines often have stops that are quite far apart for each direction * This prohibits proper routing (GPS + walking), * this system is not very intuitive I find. Proposed change: bus stops to be mapped exactly to where they are, and to be added to relations Result: * better routing results e.g. one wants to find a correct way to the bus stop, and not to the average point somewhere between two stops of the same name in either direction. * more intuitive system - easier learning curve for new users. Influence on possible future software solutions: minor. May require all the stops on the route to be ordered based on their geographical location, as opposed to their place on the route (the latter is easier). Comments: I have seen this system very often implemented - two bus stops on each side, so my suggestion is just to codify the situation for future editors. Hope this is not too much at once, for more is to follow. 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 ___ 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]
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=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. Oxmoa suggests two relations rel tag k=ref v=618/ tag direction=southbound/ ... member ref=northern Gennebrecker Str./ member ref=Agnes-Miegel-Straße/ member ref=southern Gennebrecker Str./ ... /rel rel tag k=ref v=618/ tag direction=northbound/ ... member ref=southern Gennebrecker Str./ member ref=northern Gennebrecker Str./ ... /rel 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. In Oxmoa it is very simple: you map what the bus does. 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: rel tag k=ref v=643/ tag direction=eastbound/ ... member ref=Morianstraße/ member ref=platform 5/ member ref=Islandufer/ ... /rel rel tag k=ref v=643/ tag direction=westbound/ ... member ref=Morianstraße/ member ref=platform 4/ member ref=Islandufer/ ... /rel 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. See http://wiki.openstreetmap.org/wiki/Opening_hours (the server is currently down): just add something like Mo-Fr 5:00-21:00 to indicate when the service is operational. 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. 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; it has no defined interface for extensions. By the way, it doesn't work in a densely populated area at all. The reason why I have written the plug-in for JOSM is that I wanted an easy way to map bus lines, not a personal preference of JOSM. 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. Cheers, Roland ___ 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
