Re: [Talk-transit] Naming concepts

2016-11-01 Thread Stephen Sprunk

On 2016-10-31 17:59, Greg Troxel wrote:

Stephen Sprunk  writes:


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".


In formal writing, I'd probably correct that to "Holland America is a 
cruise line operator", but I'm not pedantic enough to do that in 
informal writing, much less speech.



So it's messy.


True, but English is a messy language; things have a habit of morphing 
into forms that are de jure incorrect, yet so many people repeat them 
that they become de facto correct over time.  We joke about how some 
non-natives speak English "better" than us, yet correctness just doesn't 
"sound right"; one of the hardest things to learn is speaking 
incorrectly like we natives do!


For instance, "than us" above should really be "than we [do]", but if 
you actually say "than we" without the "do", native speakers will 
probably think you're pretentious--or a non-native speaker.



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.


That makes sense since they're obviously related, at least if the shared 
segment is significant, yet it recognizes a clear difference between the 
two services outside the shared segment.  Seems like a win to me.


Note that I'm comparing that to using a single line label, which makes a 
schedule like this much harder to understand that it should be:

http://dart.org/schedules/w019no.htm
http://dart.org/schedules/w019so.htm

It's one thing for some trips (particularly the first and last few of 
the service day) to not run the entire length of a line, but when you 
branch at one or both ends, i.e. serving mutually exclusive subsets of 
stops, calling it a single line seems rather questionable.


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

2016-11-01 Thread Stephen Sprunk

On 2016-11-01 06:12, Felix Delattre wrote:

On 31/10/16 19:05, Stephen Sprunk wrote:

For those not familiar with Transmodel, can you either explain what
its terms are for the concepts in question and/or point us to
resources that do?


I found this PDF on transmodel's definitions and concepts useful:
http://transmodel-cen.eu/wp-content/uploads/2015/02/TRM6_Glossary-Part-123.pdf


That'll take a while to digest fully, but it appears your excerpt covers 
the current topic succinctly.  Thanks!



* LINE: A group of ROUTEs which is generally known to the public by a
similar name or number
* ROUTE: An ordered list of located POINTs defining one single path
through the road (or rail) network. A ROUTE may pass through the same
POINT more than once.


I take it as a good sign that those are roughly the same terms/ideas 
that we collectively came up with off the cuff.  It's also good that 
they're ones a layman can fairly easily understand.  Unfortunately, both 
end here.



* JOURNEY PATTERN: An ordered list of SCHEDULED STOP POINTs and TIMING
POINTs on a single ROUTE, describing the pattern of working for public
transport vehicles.A JOURNEY PATTERN may pass through the same POINT
more than once. The first point of a JOURNEY PATTERN is the origin. The
last point is the destination.


OSM: This seems to be (very) roughly equivalent to the set of 
stop_positions in a given route.  Without an additional formal level of 
abstraction, journey patterns along the same route have to duplicate the 
correct subset of ways in addition to the stop_positions.  I recognized 
that as frustrating when I did the rail lines here but I couldn't put my 
finger on exactly why at the time.


GTFS: This sounds like a shape, but it's optional and most agencies 
don't seem to bother, which means you have to compare the full list of 
stops to determine if two trips are using the same pattern.  But lazy 
agencies would probably give up entirely if they had to create/provide 
shapes, so I get it.



* VEHICE JOURNEY: The planned movement of a public transport vehicle on
a DAY TYPE from the start point to the end point of a JOURNEY PATTERN 
on

a specified ROUTE.


OSM: If schedule information is out of scope, I don't see a need/use for 
an equivalent to this.  (Not an argument either way, just a 
consequence.)


GTFS: This sounds like a trip.

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

2016-11-01 Thread Felix Delattre
Thank you all for this great input!

On 01/11/16 00:02, Greg Troxel wrote:
> "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.

Personally, the initial question was about the use in code, but making
also the code as readable as possible. Generally I think the whole
discussion is good and interesting even without looking too much on my
specific use case

The transmodel standard is good information and even it introduces
another naming convention (besides OSM and GTFS) it seems to be the best
thought-threw definition (with some awkward terms however :) )

With all this input I will make my head around and see how I name my
classes for the osm2gtfs script:
https://github.com/grote/osm2gtfs/issues/30#issuecomment-257162677

Thank you!


On 31/10/16 19:05, Stephen Sprunk wrote:
> For those not familiar with Transmodel, can you either explain what
> its terms are for the concepts in question and/or point us to
> resources that do?

I found this PDF on transmodel's definitions and concepts useful:
http://transmodel-cen.eu/wp-content/uploads/2015/02/TRM6_Glossary-Part-123.pdf

* LINE: A group of ROUTEs which is generally known to the public by a
similar name or number
* ROUTE: An ordered list of located POINTs defining one single path
through the road (or rail) network. A ROUTE may pass through the same
POINT more than once.
* JOURNEY PATTERN: An ordered list of SCHEDULED STOP POINTs and TIMING
POINTs on a single ROUTE, describing the pattern of working for public
transport vehicles.A JOURNEY PATTERN may pass through the same POINT
more than once. The first point of a JOURNEY PATTERN is the origin. The
last point is the destination.
* VEHICE JOURNEY: The planned movement of a public transport vehicle on
a DAY TYPE from the start point to the end point of a JOURNEY PATTERN on
a specified ROUTE.

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Naming concepts

2016-10-31 Thread Greg Troxel

"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

2016-10-31 Thread Greg Troxel

Stephen Sprunk  writes:

> 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

2016-10-31 Thread Stephen Sprunk

On 2016-10-31 11:46, Roger Slevin wrote:

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.


For those not familiar with Transmodel, can you either explain what its 
terms are for the concepts in question and/or point us to resources that 
do?


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

2016-10-31 Thread Roger Slevin
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:step...@sprunk.org] 
Sent: 31 October 2016 16:16
To: Public transport/transit/shared taxi related topics 

Subject: Re: [Talk-transit] Naming concepts

On 2016-10-31 07:54, Greg Troxel wrote:
> Felix Delattre  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_o

Re: [Talk-transit] Naming concepts

2016-10-31 Thread Stephen Sprunk

On 2016-10-31 07:54, Greg Troxel wrote:

Felix Delattre  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
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Naming concepts

2016-10-31 Thread Felix Delattre
On 31/10/16 13:54, Greg Troxel wrote:
> Felix Delattre  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.

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

2016-10-31 Thread Greg Troxel

Felix Delattre  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.

> 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

2016-10-31 Thread Greg Troxel



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

2016-10-31 Thread Felix Delattre
On 31/10/16 10:05, Roland Olbricht wrote:
 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.
>>
>
> I fully support that wording. 

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
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.

___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


Re: [Talk-transit] Naming concepts

2016-10-31 Thread Roland Olbricht

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


Re: [Talk-transit] Naming concepts

2016-10-30 Thread Jo
2016-10-30 21:27 GMT+01:00 Greg Troxel :

>
> Felix Delattre  writes:
>
> > There are different concepts of routes in OpenStreetMap and GTFS.
> > Sometimes they are not existent or ambiguous.
>
> I am a native speaker of en_US.
>
> > 1. A general public transport service (e.g. No. 38):
> > In OSM: "route_master" in GTFS: "route"
>
> I find route_master to be an odd term, and very much computer jargon vs
> human language.
>

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 this a bus route.  Around me, it would have a number, and a
> set of stops.   Then there would be a schedule for the bus route that
> says what time the bus starts from each end and the time for at least
> some of the intermediate stops.   So I find the use of the word route in
> OSM natural.  It also parallels the use of route for a road, which is a
> sequence of ways, but without timing.
>

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"
>
> It makes sense to use "trip" in GTFS, and it makes sense that this is
> not in OSM because we don't represent that level of information.
>

Indeed. 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.


>
> > Route: Is used for different concepts (I guess because of British and
> > American English)
>
> I don't think it's en_GB vs en_US.  I've recently driven in Scotland and
> about 10 years ago in Ireland, and didn't find route to mean something
> significantly differently.  In the US, we use it as part of the name of
> a numbered highway, e.g. "Route 2" is a state highway that goes for
> about 200 miles.  It is signed the whole way and you change road name
> often, but you follow that sequence of roads to get from Boston to the
> New York border, more or less.  Perhaps that isn't used that way in the
> UK, but the notion of "bus route" seemed similar to me.
>
> > Routemaster:  Is a very technical term. I thinks, it's not
> > understandable when looking at it naively (isn't this the bus driver?)
>
> Agreed.  This is a defined term that doesn't mean anything to native
> speakers without reading the definition.
>
> Absent a definition, I wouldn't expect it to mean the driver.   I would
> expect it to mean the official at the transit organization or bus
> company that has the authority to decide what streets that route will go
> on (and can change the set of stops).
>

I'm sure whoever came up with the term wanted to make sure it had route in
the name, as it's grouping a bunch of route relations. For me this is the
'line'. Service line definitely doesn't sound very English to me. (But I'm
not a native speaker either). PT line, maybe?

>
> > It call them 1: Service Line; 2. Route Variant 3: Trip
> >
> > English native speakers, please help: Does this make sense to you? Would
> > you suggest other terms for the concepts to be even more understandable?
>
> Service line and variant don't give me the right idea.  But on really
> thinking I can see where you are coming from.
>
> My basic thoughts are to give the right impression and to align with
> GTFS.
>
> Your #1 I am not 100% sure what it is.  If it's essentially the string
> "Route 38" and doesn't contain information about where, then I would
> call it "route name".
>
> Your #2: I would use route to represent the set of stops and the choice
> of roads, and would expect this to be a pair for the two directions
> (usually; a route could be circular and not bidirectional).  I find it
> funny that GTFS doesn't have this, as the theory of putting databases in
> normal form would lead to representing the set of stops and then having
> sets of times.  However, I can see that this wouldn't quite work.  There
> are train routes near me where some trains skip some of the smaller
> stops.  So here I would expect the "route" to be a set of stops that
> might be made, and the "trip" to sometimes omit some stops.
>
> I do find "trip" to be pretty close to intuitive, although there is
> ambiguity about whether it is a scheduled trip that repeats on multiple
> days, or an actual single trip that happened.   That is not bothersome
> though.
>
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit
>
>
___
Talk-transit mailing list
Talk-transit

Re: [Talk-transit] Naming concepts

2016-10-30 Thread Felix Delattre
Thanks for your input, Greg!

And how can I make an understandable distinction without using to much
computer jargon between:

1. The overall "route" as you were saying ("route_master" in OSM;), it
has a number (eg. Route 38)

AND (consists of)

2. a subset of route variants ("route" in OSM), one for each direction,
where the bus stops are usually on the other side of the street (so not
the same ones!), maybe there is an additional variant (only runs after
10pm...) that has the same number, but is shorter than the other, or one
that skips a couple of stops, etc.

* The use of "route" alone I would not recommend, because it's to
ambiguous and is used for different concepts.
* "Service Line" for 1. sounds too much German to me :)

Here I made a little table to show the different concepts and terms in
OSM, GTFS and what I came up with:
https://github.com/grote/osm2gtfs/issues/30#issuecomment-257162677

How would a native speaker declare one term each for 1. and one for 2.
that explains intuitively in human language the difference in concept?

Thanks,
Felix



On 30/10/16 21:27, Greg Troxel wrote:
> Felix Delattre  writes:
>
>> There are different concepts of routes in OpenStreetMap and GTFS.
>> Sometimes they are not existent or ambiguous.
> I am a native speaker of en_US.
>
>> 1. A general public transport service (e.g. No. 38):
>> In OSM: "route_master" in GTFS: "route"
> I find route_master to be an odd term, and very much computer jargon vs
> human language.
>
>> 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 this a bus route.  Around me, it would have a number, and a
> set of stops.   Then there would be a schedule for the bus route that
> says what time the bus starts from each end and the time for at least
> some of the intermediate stops.   So I find the use of the word route in
> OSM natural.  It also parallels the use of route for a road, which is a
> sequence of ways, but without timing.
>
>> 3. An actual tour a bus takes, on a certain time
>> In OSM" not existen; in GTFS: "trip"
> It makes sense to use "trip" in GTFS, and it makes sense that this is
> not in OSM because we don't represent that level of information.
>
>> Route: Is used for different concepts (I guess because of British and
>> American English)
> I don't think it's en_GB vs en_US.  I've recently driven in Scotland and
> about 10 years ago in Ireland, and didn't find route to mean something
> significantly differently.  In the US, we use it as part of the name of
> a numbered highway, e.g. "Route 2" is a state highway that goes for
> about 200 miles.  It is signed the whole way and you change road name
> often, but you follow that sequence of roads to get from Boston to the
> New York border, more or less.  Perhaps that isn't used that way in the
> UK, but the notion of "bus route" seemed similar to me.
>
>> Routemaster:  Is a very technical term. I thinks, it's not
>> understandable when looking at it naively (isn't this the bus driver?)
> Agreed.  This is a defined term that doesn't mean anything to native
> speakers without reading the definition.
>
> Absent a definition, I wouldn't expect it to mean the driver.   I would
> expect it to mean the official at the transit organization or bus
> company that has the authority to decide what streets that route will go
> on (and can change the set of stops).
>
>> It call them 1: Service Line; 2. Route Variant 3: Trip
>>
>> English native speakers, please help: Does this make sense to you? Would
>> you suggest other terms for the concepts to be even more understandable?
> Service line and variant don't give me the right idea.  But on really
> thinking I can see where you are coming from.
>
> My basic thoughts are to give the right impression and to align with
> GTFS.
>
> Your #1 I am not 100% sure what it is.  If it's essentially the string
> "Route 38" and doesn't contain information about where, then I would
> call it "route name".
>
> Your #2: I would use route to represent the set of stops and the choice
> of roads, and would expect this to be a pair for the two directions
> (usually; a route could be circular and not bidirectional).  I find it
> funny that GTFS doesn't have this, as the theory of putting databases in
> normal form would lead to representing the set of stops and then having
> sets of times.  However, I can see that this wouldn't quite work.  There
> are train routes near me where some trains skip some of the smaller
> stops.  So here I would expect the "route" to be a set of stops that
> might be made, and the "trip" to sometimes omit some stops.
>
> I do find "trip" to be pretty close to intuitive, although there is
> ambiguity about whether it is a scheduled trip that repeats on multiple
> days, or an actual single trip that happened.   That is not bothersome
> though.



_

Re: [Talk-transit] Naming concepts

2016-10-30 Thread Greg Troxel

Felix Delattre  writes:

> There are different concepts of routes in OpenStreetMap and GTFS.
> Sometimes they are not existent or ambiguous.

I am a native speaker of en_US.

> 1. A general public transport service (e.g. No. 38):
> In OSM: "route_master" in GTFS: "route"

I find route_master to be an odd term, and very much computer jargon vs
human language.

> 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 this a bus route.  Around me, it would have a number, and a
set of stops.   Then there would be a schedule for the bus route that
says what time the bus starts from each end and the time for at least
some of the intermediate stops.   So I find the use of the word route in
OSM natural.  It also parallels the use of route for a road, which is a
sequence of ways, but without timing.

> 3. An actual tour a bus takes, on a certain time
> In OSM" not existen; in GTFS: "trip"

It makes sense to use "trip" in GTFS, and it makes sense that this is
not in OSM because we don't represent that level of information.

> Route: Is used for different concepts (I guess because of British and
> American English)

I don't think it's en_GB vs en_US.  I've recently driven in Scotland and
about 10 years ago in Ireland, and didn't find route to mean something
significantly differently.  In the US, we use it as part of the name of
a numbered highway, e.g. "Route 2" is a state highway that goes for
about 200 miles.  It is signed the whole way and you change road name
often, but you follow that sequence of roads to get from Boston to the
New York border, more or less.  Perhaps that isn't used that way in the
UK, but the notion of "bus route" seemed similar to me.

> Routemaster:  Is a very technical term. I thinks, it's not
> understandable when looking at it naively (isn't this the bus driver?)

Agreed.  This is a defined term that doesn't mean anything to native
speakers without reading the definition.

Absent a definition, I wouldn't expect it to mean the driver.   I would
expect it to mean the official at the transit organization or bus
company that has the authority to decide what streets that route will go
on (and can change the set of stops).

> It call them 1: Service Line; 2. Route Variant 3: Trip
>
> English native speakers, please help: Does this make sense to you? Would
> you suggest other terms for the concepts to be even more understandable?

Service line and variant don't give me the right idea.  But on really
thinking I can see where you are coming from.

My basic thoughts are to give the right impression and to align with
GTFS.

Your #1 I am not 100% sure what it is.  If it's essentially the string
"Route 38" and doesn't contain information about where, then I would
call it "route name".

Your #2: I would use route to represent the set of stops and the choice
of roads, and would expect this to be a pair for the two directions
(usually; a route could be circular and not bidirectional).  I find it
funny that GTFS doesn't have this, as the theory of putting databases in
normal form would lead to representing the set of stops and then having
sets of times.  However, I can see that this wouldn't quite work.  There
are train routes near me where some trains skip some of the smaller
stops.  So here I would expect the "route" to be a set of stops that
might be made, and the "trip" to sometimes omit some stops.

I do find "trip" to be pretty close to intuitive, although there is
ambiguity about whether it is a scheduled trip that repeats on multiple
days, or an actual single trip that happened.   That is not bothersome
though.


signature.asc
Description: PGP signature
___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit


[Talk-transit] Naming concepts

2016-10-30 Thread Felix Delattre
Hello,

I'm currently coding on a osm2gtfs script
(https://github.com/grote/osm2gtfs) to make it work in a more generic
way for more than one city (for which it was created for initially). And
I like my code to be readable and understandable intuitively. Because we
are all no native English speakers (two Germans and one Costa Rican) I'd
like to ask for some feedback on naming issues:

There are different concepts of routes in OpenStreetMap and GTFS.
Sometimes they are not existent or ambiguous.

1. A general public transport service (e.g. No. 38):
In OSM: "route_master" in GTFS: "route"

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/

3. An actual tour a bus takes, on a certain time
In OSM" not existen; in GTFS: "trip"

Route: Is used for different concepts (I guess because of British and
American English)
Routemaster:  Is a very technical term. I thinks, it's not
understandable when looking at it naively (isn't this the bus driver?)

It call them 1: Service Line; 2. Route Variant 3: Trip

English native speakers, please help: Does this make sense to you? Would
you suggest other terms for the concepts to be even more understandable?

Thank you very much!

Regards,
Felix




___
Talk-transit mailing list
Talk-transit@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-transit