[Talk-transit] Naming concepts

Stephen Sprunk stephen at sprunk.org
Mon Oct 31 16:15:47 UTC 2016

On 2016-10-31 07:54, Greg Troxel wrote:
> Felix Delattre <felix-lists at delattre.de> 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.


Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

More information about the Talk-transit mailing list