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
