Re: [Talk-transit] Proposed changes to oxomoa schema [part 1]
On 29 June 2010 07:29, Roland Olbricht roland.olbri...@gmx.de wrote: those two would meet in point A, from which the branch line sets off/rejoins the core line. So a hypothetical future route-finding algorithm would follow different_route to its end, upon meeting core line it would continue along. It just doesn't work. Having an unordered relation or even mapping both directions within the same relation leads to ambiguities. Just two examples: http://www.openstreetmap.org/?lat=51.29314lon=7.21791zoom=17layers=B http://www.openstreetmap.org/?lat=51.29314lon=7.21791zoom=17layers=B000FTF Bus service 618 southbound comes on the Gennebrecker Str. from the north, loops into Agnes-Miegel-Straße and then proceeds on the Gennebrecker Str. to the south, always. 618 northbound passes on the Gennebrecker Str. from south to north only. From where the line split, point 768803020, to where they meet again, 768803016, they would be tagged backward and forward, or any other appropriate pair of tags. Judging by the direction, routing software would either follow one or the other. Now I would like to see how you discriminate this case from the case where 618 passes through the loop in both directions (so does line 624) if you don't have an ordered relation. I'm not completely sure what you mean without seeing it graphically, but logically I cannot see what can't be done by tagging that is now done with two separate routes. The question is whether it is easier to enter and manage, and I maintain that tags are easier than two relations. In Oxmoa it is very simple: you map what the bus does. It is simple as a data structure, but neither simple nor efficient for the user. In the 21st century software is adjusted to users, not users forced to adjust to software. What I am opting for is simpler machine-user interface, easier experience for users. What it is now is clearly a mess. Look at the number of amendments made to my original post: all that info is probably somewhere there, but how does a beginner find and compile it? Second example http://www.openstreetmap.org/?lat=51.255881lon=7.150008zoom=18layers=B000FTF Line 643 passes in both directions from Morianstraße on the left to Islandufer on the right. But in eastbound direction, it passes through platform 5, in westbound direction is passes through platform 4. This is important, because buses in both directions are at the stop at almost the same time. In Oxmoa, it is again simple and intuitive: Raw XML simple and intuitive? We may be speaking a different language here. I am talking about user experience. User = map editor. Not a programmer by definition. Second example http://wiki.openstreetmap.org/wiki/Opening_hours http://www.openstreetmap.org/?lat=51.255881lon=7.150008zoom=18layers=B000FTF Line 643 passes in both directions from Morianstraße on the left to Islandufer on the right. But in eastbound direction, it passes through platform 5, in westbound direction is passes through platform 4. This is important, because buses in both directions are at the stop at almost the same time. Not difficult. You'd put direction_to and direction_from tags to the bus stop and the route. Same goes for lines with variants, you can have forward_variant_a, backward_variant_a, forward_variant_b, backward_variant_b. Believe me, my Verkehrsverbund is not any different from yours. We face the same problems. Nonetheless, there are still things that Oxmoa leaves open. For example, there is no specification how to store approximate journey time. But the usage of ordered relations and the separation of directions is one of the strengths of Oxmoa, not a weakness. Please convince me that tagged routes are more difficult than dealing with a nested collection of multiple routes. Possibly I am misled in my belief that editing/rerouting multiple variants as multiple relations is just time-consuming. For me now the system seems unnecessarily complex. B-trees are not easy to comprehend to common users-editors, who are not, by definition, programmers. Concerning Potlatch ... It's just not open. You can easily contribute to JOSM by writing a plug-in or even submitting a patch. Potlatch makes the life for the programmer much more difficult; This is about editors, not programmers. I'd suggest that we use the discussion page http://wiki.openstreetmap.org/wiki/Public_Transport of the wiki once the server is back again to write a consistent, easy-to-use and easy-to-implement standard. I second that opinion. Email exchanges are a bit difficult when they grow. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed changes to oxomoa schema [part 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 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 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
