>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<mailto: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<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! 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 point is to try to stick to oxomoa. It is fairly easy to start mapping one bus line, but then it becomes very difficult to get everything under control. I don't want to sh*t on the standard, because it is the only one, but I suggest we get to work pretty early to divide the entire process of mapping lines into a few (I would see two-three) different levels of difficulty, on which I will elaborate in a separate email for clarity. 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
