Re: [Talk-transit] Naming concepts
"Roger Slevin"writes: > 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. I agree in general - OSM has too much making up of schemas rather than studying the schemas which have been developed in the various professional communities. Overall, though, I am wondering if this discussion is about identifiers to use in source code, or is about some user-facing aspect of the program or something else. I would advocate picking a well-established set of terms (transmodel seems like a good fit, even though I know zero about it) and just use that. The key is defining the terms so that people can understand them. signature.asc Description: PGP signature ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naming concepts
Stephen Sprunkwrites: > 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. But one would say 'Holland America is a cruise line". So it's messy. >> 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 agree, and the for the most part the agency near me (MBTA, www.mbta.com) is good about this, having two route numbers for the two ways the bus can run. But then they publish a "74/75" schedule that shows information about 74 and 75 since they are mostly the same and departures are interleaved. I don't think there's any way to totally win here. signature.asc Description: PGP signature ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naming concepts
On 2016-10-31 07:54, Greg Troxel wrote: Felix Delattrewrites: 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 Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naming concepts
On 31/10/16 13:54, Greg Troxel wrote: > Felix Delattrewrites: >> 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. The same thing told me a friend (en_US) I asked. > 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. Yes, that's what it is a collection of variants. I think in proper English the overall collection of route variations is just called a "route". Unfortunately OpenStreetMap's tagging schema uses "route" for route variations and "route_master" for what should be called a route :/ That is also the reason why I want to avoid the use of the pure word "route" - to avoid confusion. I like the idea of using bus_route_name, as this is most understandable in human language, but can be misleading as well - somtimes variations have different names (Bus route 37A, Bus route 37B). Maybe it's a good option to use: 1. RouteContainer (which can have then one to several) 2. RouteVariation(s) This is also computer jargon, but better understandable than route_master, I guess? > 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. > > trip and itinerary are both confusing in that there is ambiguity between > a specific one-time departure (e.g., 0800 from Harvard Square on 31 > October 2016) and a planned recurring departure (0800 from Harvard > Square on all weekdays). I would use the terms > > recurring_trip > > specific_trip > > but don't really like the second one. > > > 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. Yes, that's true. Use route for route (as GTFS does) and put a comment in there, every time OSM routes are used, that they are actually representing route variations... > 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. It combines OSM data with other sources of schedule/time information to create a GTFS format out of it. ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naming concepts
Felix Delattrewrites: > 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. > 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". 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". 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. 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. trip and itinerary are both confusing in that there is ambiguity between a specific one-time departure (e.g., 0800 from Harvard Square on 31 October 2016) and a planned recurring departure (0800 from Harvard Square on all weekdays). I would use the terms recurring_trip specific_trip but don't really like the second one. 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. signature.asc Description: PGP signature ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naming concepts
signature.asc Description: PGP signature ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit
Re: [Talk-transit] Naming concepts
Hi all, 1. A general public transport service (e.g. No. 38): In OSM: "route_master" in GTFS: "route" For me that is a line. It has a line number. (which sometimes is not simply numeric, so it's more of a symbol, but OK) 2. A theoretical tour a bus takes, but without schedule information, it represents one each for different direction, but also if one is shorter than the other In OSM: "route"; in GTFS: /not existent/ I would call those itinerary. If OSM had started out with that term, we wouldn't have the ambiguity today. But route is used for foot/bicycle/horse and PT itineraries. For PT I resorted to call them route variations, but they are 'represented' by route relations in OSM. 3. An actual tour a bus takes, on a certain time In OSM" not existen; in GTFS: "trip" [..] If we could figure out a way to represent it anyway, I think it would be a plus. But I won't be holding my breath. I fully support that wording. But I would like to point you to another problem that has kept and is keeping OSM PT painful: There are two very distinct underlying data models in use by the transit agencies. The metropolitan (line based) model looks like subway lines usually look: The full schedule is essentially modeled by the itineraries plus the list of departure times per itinerary. This works because all trips have the same set of stops and approximately the same travel time. If there are many trips per itinerary then there might not even be a fixed list of departure times but just a defined departure frequency, like 05h48 06h00 then every 2 to 5 Minutes 19h00 19h13 19h28 ... That is all you need to know. Frequencies depend on the hardware (signalling limits, number of vehicles for the line). Thus they usually persist for years or decades. First and last times depends on the habits of the local users and therefore also persist usually for years. It would make sense to have that information in OSM. The rural model, also often used for long distance service, looks like school buses: Different trips may vary wildly, and times fluctuate quite often. A useful data model would have to capture not only an itinerary for each single trip, but also the operating dates. This is out of scope for OSM, because it is ephemeral. Nonetheless, trips have a line number that is displayed. Operations based on the metropolitan model tend to be attractive for passengers from the general public. Operations based on the rural model tend to be cheap for the agency. This is why it is a political issue to tell a local community that their public transport network is too rural for OSM. Long story cut short: I would suggest that you keep a structure for unassigned trips in your intermediate data structure, even if that is not filled from OSM. If you want to fight for timetable data according to the metropolitan model in OSM, then you have my support. But a lot of people have tried that years ago and each eventually resigned. There is quite a vocal part of the community concerned with more rural-style services, and they have defeated so far all apporaches to metropolitan style information to OSM. Best regards, Roland -- Dr. Roland Olbricht MENTZ GmbH, Am Mittelhafen 10, 48155 Münster T: +49 (0)251 7 03 30-232, F: +49 (0)251 7 03 30-300 E: olbri...@mentz.net, www.mentz.net Sitz der Gesellschaft: Grillparzerstraße 18, 81675 München Geschäftsführer Dr.-Ing. Hans-J. Mentz Amtsgericht München, HRB 91898 ___ Talk-transit mailing list Talk-transit@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-transit