Perhaps I can add a comment to this debate, as a native English speaker? The term "LINE" is as awkward for me as it is for everyone else ... because it is describing something which in everyday language has many approximate synonyms. But in the comprehensive European Transmodel (public transport reference data model) standard LINE is defined precisely to give an unambiguous meaning - and that then leaves ROUTE and other terms to have their own unambiguous meanings.
To me these are classic examples of why a carefully constructed data model dealing with something as "everyday" as public transport is almost inevitably going to use words which are not necessarily the same as those which might be used colloquially in a very imprecisely way. The terms in a reference data model ensure that everyone working with data can be sure that they are talking about the same abstract concepts when they use a particular defined term .... and that saves a lot of time debating such terms and concepts. I have watched this debate over the years - and I keep coming back to what I think is a key question for the OSM community ... if there is an existing robust standard for public transport information, then is it really worth trying to add to OSM a different standard (or set of terms) for that information? If so, can you afford to be less precise in your terminology than that defined over many, many years of work in Transmodel? The same issue was faced by GTFS many years ago and, for better or worse, the decision was taken by the GTFS community to go ahead with a separate standard. But whilst GTFS is not underpinned by the Transmodel standard, many aspects of it have taken the Transmodel reference data model into account. GTFS is not as comprehensive, I suggest, as Transmodel - and it is an implementation standard and not a reference data model. There is no easy approach to these discussions - and as the world of public transport information becomes ever more complex and comprehensive, so the challenges of maintain integrity in the handling of the available information get ever bigger - and the need for robust data models becomes every stronger. Roger -----Original Message----- From: Stephen Sprunk [mailto:[email protected]] Sent: 31 October 2016 16:16 To: Public transport/transit/shared taxi related topics <[email protected]> Subject: Re: [Talk-transit] Naming concepts On 2016-10-31 07:54, Greg Troxel wrote: > Felix Delattre <[email protected]> writes: >> I also like them. Thanks, Jo! >> But isn't "line" an European wording? Would an English native speaker >> intuitively understand the concepts of "line" and "itinerary"? I >> always > > For me (en_US), I find it awkward. I (en_US) find it a bit awkward, but mainly because I think the general public uses "route" to refer to both, and which they're referring to (if they even make that distinction) can be inferred from context--something a computer can't do. >> thought a "line" is more likely to understand as a network or public >> transport operator for US boys and girls - but (hopefully) I might be >> wrong. > > "line" often refers to a company that operates routes, like a "cruise > line". Like many English words, the meaning of "line" depends on context, to the point it's both clearly right and clearly wrong to different people. I should point out that "bus lines", "cruise lines", "air lines", etc. are plural when talking about one company (e.g. American Airlines) because they operate a collection of individual lines between specific locations, such as New York-Los Angeles. It is illogical to think of a line as going in only one direction, whereas a route does have a direction, so logically a line must be a collection of two (or more?) routes, right? Overall, I think this is the best one can come up with for this concept. Unfortunately, "line" alone is too generic to use in OSM, which is probably where "route_master" came from. > itinerary is usually a set of places that a person or group is going > to, often including cities/hotels on multi-day trips and sometimes > including > flights. If someone said "please send me your itinerary for your trip > to France" they would expect a list of "this night we are at this > hotel, address and phone, and this night....". Exactly; one speaks of the itinerary for a specific trip. > I'm still not 100% following. In the wiki table, is concept number 1 > just a name for the collection of route variants, and basically the > name that the bus company (agency/whatever) uses? I would call that > "bus_route_name" then, with a name, and perhaps bus_route_ref for just > the numberish part, along with bus_route_operator. This is making it > like highway ref tags. Incidentally, this drives me nuts about transit. If the agencies actually published the names that way (e.g. variants 42A and 42B, perhaps with the shared portions just labeled 42), it'd make their services a lot easier to use; today, it's very easy to accidentally get on a "42 to Foo Street" when you actually needed a "42 to Bar Avenue". When "via"s get involved, it's even worse. Who came up with this nonsense and thought it was a good idea? > I think "route_variant" is a good name, in that it captures the sense > that all of the route_variants of a route are similar somewhow but not > quite. The only awkwardness is that sometimes there will be only one > route_variant in a route. If one is trying to avoid the word "route" for this, but not a specific trip, then the only term coming to mind is "service pattern", but a layman would need a bit to work out exactly what you're referring to. I doubt many have ever thought of the formal distinctions that we need. > Overall, though, I would try very hard to just reuse the GTFS terms > for the GTFS concepts, and to put a comment in the source or docs > clarifying what they mean. I think the benefit of clearer terms will > be outweighed by having more to learn. > > Finally, I think osm2gtfs is going to want to use information that > isn't > in OSM. I'm not sure what the plan is, or if one can produce a GTFS > version that is just missing the fine-grained schedule information, > and if that's what you want to do. Indeed, if we can get more information on the desired use, we may be able to provide more specific guidance. But I've been thinking more in terms of how to get GTFS data into OSM and/or match the two together, rather than OSM data into GTFS. Since GTFS already has ID numbers for each entity and OSM is free tagging, the former are fairly straightforward, whereas the (current) policy of not putting schedule data in OSM makes that latter seemingly impossible. S -- Stephen Sprunk "Those people who think they know everything CCIE #3723 are a great annoyance to those of us who do." K5SSS --Isaac Asimov _______________________________________________ Talk-transit mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-transit _______________________________________________ Talk-transit mailing list [email protected] https://lists.openstreetmap.org/listinfo/talk-transit
