Re: [Talk-transit] Proposed changes to oxomoa schema [part 1]
On 29 June 2010 07:29, Roland Olbricht roland.olbri...@gmx.de wrote: those two would meet in point A, from which the branch line sets off/rejoins the core line. So a hypothetical future route-finding algorithm would follow different_route to its end, upon meeting core line it would continue along. It just doesn't work. Having an unordered relation or even mapping both directions within the same relation leads to ambiguities. Just two examples: http://www.openstreetmap.org/?lat=51.29314lon=7.21791zoom=17layers=B http://www.openstreetmap.org/?lat=51.29314lon=7.21791zoom=17layers=B000FTF Bus service 618 southbound comes on the Gennebrecker Str. from the north, loops into Agnes-Miegel-Straße and then proceeds on the Gennebrecker Str. to the south, always. 618 northbound passes on the Gennebrecker Str. from south to north only. From where the line split, point 768803020, to where they meet again, 768803016, they would be tagged backward and forward, or any other appropriate pair of tags. Judging by the direction, routing software would either follow one or the other. Now I would like to see how you discriminate this case from the case where 618 passes through the loop in both directions (so does line 624) if you don't have an ordered relation. I'm not completely sure what you mean without seeing it graphically, but logically I cannot see what can't be done by tagging that is now done with two separate routes. The question is whether it is easier to enter and manage, and I maintain that tags are easier than two relations. In Oxmoa it is very simple: you map what the bus does. It is simple as a data structure, but neither simple nor efficient for the user. In the 21st century software is adjusted to users, not users forced to adjust to software. What I am opting for is simpler machine-user interface, easier experience for users. What it is now is clearly a mess. Look at the number of amendments made to my original post: all that info is probably somewhere there, but how does a beginner find and compile it? Second example http://www.openstreetmap.org/?lat=51.255881lon=7.150008zoom=18layers=B000FTF Line 643 passes in both directions from Morianstraße on the left to Islandufer on the right. But in eastbound direction, it passes through platform 5, in westbound direction is passes through platform 4. This is important, because buses in both directions are at the stop at almost the same time. In Oxmoa, it is again simple and intuitive: Raw XML simple and intuitive? We may be speaking a different language here. I am talking about user experience. User = map editor. Not a programmer by definition. Second example http://wiki.openstreetmap.org/wiki/Opening_hours http://www.openstreetmap.org/?lat=51.255881lon=7.150008zoom=18layers=B000FTF Line 643 passes in both directions from Morianstraße on the left to Islandufer on the right. But in eastbound direction, it passes through platform 5, in westbound direction is passes through platform 4. This is important, because buses in both directions are at the stop at almost the same time. Not difficult. You'd put direction_to and direction_from tags to the bus stop and the route. Same goes for lines with variants, you can have forward_variant_a, backward_variant_a, forward_variant_b, backward_variant_b. Believe me, my Verkehrsverbund is not any different from yours. We face the same problems. Nonetheless, there are still things that Oxmoa leaves open. For example, there is no specification how to store approximate journey time. But the usage of ordered relations and the separation of directions is one of the strengths of Oxmoa, not a weakness. Please convince me that tagged routes are more difficult than dealing with a nested collection of multiple routes. Possibly I am misled in my belief that editing/rerouting multiple variants as multiple relations is just time-consuming. For me now the system seems unnecessarily complex. B-trees are not easy to comprehend to common users-editors, who are not, by definition, programmers. Concerning Potlatch ... It's just not open. You can easily contribute to JOSM by writing a plug-in or even submitting a patch. Potlatch makes the life for the programmer much more difficult; This is about editors, not programmers. I'd suggest that we use the discussion page http://wiki.openstreetmap.org/wiki/Public_Transport of the wiki once the server is back again to write a consistent, easy-to-use and easy-to-implement standard. I second that opinion. Email exchanges are a bit difficult when they grow. -- Best regards, mit freundlichen Grüssen, meilleurs sentiments, Pozdrowienia, Michał Borsuk ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Proposed changes to oxomoa schema [part 2: stops]
Shouldn't we keep the schema to something that is easily compatible with the Google Transit GTFS format instead of developing something different all together? I believe the GTFS was developed after extensive research on how transit companies actually manage their data and how that data can be used for routing. On the plus side the entire specification documentation and tools have been released under cc-by-sa. in addition to which transit agencies are making their feed public toohttp://code.google.com/p/googletransitdatafeed/wiki/PublicFeeds, making it easy to update routes. I haven't had the time to go through the proposed osm transit schema in detail, but i would hope that in the end, it would allow easy conversion to and from GTFS. This hasnt got anything to do with me supporting google transit, but just that i feel that the format is quite comprehensive and indepth, And in future when an OSM transit app comes out, agencies would be able to easily publish their data in the OSM schema as well without much hassle. -- http://j.mp/ArunGanesh ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] OSM Transit platform: call for action
Thanks for all the inputs! Actually, today I did a quick google search with open source transit and found out a couple of interesting website: http://onebusaway.org/ which offers right what I was looking for (multi-platform, open-source, gtfs...) and the twin project: http://opentripplanner.org/ (support of OSM, GTFS) well...the tools are there, we could give a look to them and start planning something :) I guess timetable infos and other details can reside into GTFS, while OSM stands for simple route rendering + map background. An import/export GTFS-OSM tool should be designed for easy conversion and use, Ciao Tiziano On Mon, Jun 28, 2010 at 19:40, McGuire, Matthew matt.mcgu...@metc.state.mn.us wrote: Can you please elaborate what Google specifications are? I think I have heard of such, but failed to find them. Any hints? GTFS – General Transit Feed Specification formerly Google Transit Feed Specification http://code.google.com/transit/spec/transit_feed_specification.html *From:* talk-transit-boun...@openstreetmap.org [mailto: talk-transit-boun...@openstreetmap.org] *On Behalf Of *Michal Borsuk *Sent:* Monday, June 28, 2010 12:17 PM *To:* Public transport/transit/shared taxi related topics *Subject:* 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.
Re: [Talk-transit] Proposed changes to oxomoa schema [part 2: stops]
On 29.06.2010 09:33, Tiziano D'Angelo wrote: +1 On Tue, Jun 29, 2010 at 08:23, Arun Ganesh arun.plane...@gmail.com mailto:arun.plane...@gmail.com wrote: Shouldn't we keep the schema to something that is easily compatible with the Google Transit GTFS format instead of developing something different all together? Doesn't GTFSsuggest one location for one unique stop name, whereas we want each physical location belonging to a name as a separate point? (this does not suggest incompatibility, just an overlay on GTFS) LMB ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] Naptan import stop tagging (was: Proposed changes to oxomoa schema [part 2: stops])
One question on the Naptan import: Did you use any tags from the public_transport therefore? Or are these all highway=bus_stop? Would be a great chance to increase coverage of the more detailed public_transport=platform Claudius Am 29.06.2010 02:07, Shaun McDonald: 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 mailto: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 ___ 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 29.06.2010 10:22, Michał Borsuk: On 29.06.2010 09:33, Tiziano D'Angelo wrote: +1 On Tue, Jun 29, 2010 at 08:23, Arun Ganesh arun.plane...@gmail.com mailto:arun.plane...@gmail.com wrote: Shouldn't we keep the schema to something that is easily compatible with the Google Transit GTFS format instead of developing something different all together? Doesn't GTFSsuggest one location for one unique stop name, whereas we want each physical location belonging to a name as a separate point? (this does not suggest incompatibility, just an overlay on GTFS) LMB GTFS covers Oxomoa's extended form of tagging a stop area as well: stops.txt contains an optional location_type where the value 1 would represent a public_transport=stop_area: 0 or blank - Stop. A location where passengers board or disembark from a transit vehicle. 1 - Station. A physical structure or area that contains one or more stop. In most cases the stop positions in both directions will have different locations and thus different stop_lat and stop_lon in GTFS as well. So we are already easily compatible. Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naptan import stop tagging
I was referring to public_transport=platform + bus=yes public_transport=bus_stop would not work because there are stop positions where trams, buses and sometimes (Karlsruhe comes to my mind) even light_rails stop at the same position (Image: http://www.dvn-berlin.de/i/verein/2009_alex_bus_hpa.jpg ) and these would be tagged as public_transport=platform + bus=yes + tram=yes (+ light_rail=yes) Claudius Am 29.06.2010 11:32, Richard Mann: They're all still highway=bus_stop. I think I'd need some convincing that public_transport=platform was appropriate for bus stops. Public_transport=bus_stop, maybe. Why change? Richard On Tue, Jun 29, 2010 at 9:59 AM, Claudius Henrichsclaudiu...@gmx.de wrote: One question on the Naptan import: Did you use any tags from the public_transport therefore? Or are these all highway=bus_stop? Would be a great chance to increase coverage of the more detailed public_transport=platform Claudius ___ Talk-transit mailing list Talk-transit@openstreetmap.org http://lists.openstreetmap.org/listinfo/talk-transit
[Talk-transit] GTFS compatibility (was Re: Proposed changes to oxomoa schema [part 2: stops])
I agree that it would be helpful to end up with something that allows straightforward conversions to and from the GTFS format. GTFS is a CC-licensed specification [1] which is evolved by an open community process [2]. Also, the great majority of U.S. and Canadian transport data is already available to developers in GTFS format [3], which has led to a community of developers creating apps which can consume and produce it [4]. Incidentally, as someone who's been deeply involved in the development of the format, I'm happy to answer any questions, and generally help to get this substantial mass of transport data into OSM. Cheers, Joe Links: [1] http://code.google.com/transit/spec/transit_feed_specification.html [2] http://groups.google.com/group/gtfs-changes/ [3] http://www.gtfs-data-exchange.com/ [4] http://groups.google.com/group/transit-developers On Tue, Jun 29, 2010 at 7:23 AM, Arun Ganesh arun.plane...@gmail.com wrote: Shouldn't we keep the schema to something that is easily compatible with the Google Transit GTFS format instead of developing something different all together? I believe the GTFS was developed after extensive research on how transit companies actually manage their data and how that data can be used for routing. On the plus side the entire specification documentation and tools have been released under cc-by-sa. in addition to which transit agencies are making their feed public too, making it easy to update routes. I haven't had the time to go through the proposed osm transit schema in detail, but i would hope that in the end, it would allow easy conversion to and from GTFS. This hasnt got anything to do with me supporting google transit, but just that i feel that the format is quite comprehensive and indepth, And in future when an OSM transit app comes out, agencies would be able to easily publish their data in the OSM schema as well without much hassle. -- http://j.mp/ArunGanesh ___ 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
