Re: [Talk-transit] Public Transport Timetables

2018-11-08 Thread santamariense
> Perhaps it would be possible to
> start something like a new gtfs.openstreetmap.org (which would be similar
> to transit.land and transitfeeds.com, but with a focus of OpenStreetMap
> integration) for hosting GTFS feeds that could be integrated into OSM.
> That would allow for much easier integration and maintenance.


I do like that idea. Something like gtfs.openstreetmap.org would be very useful.

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


Re: [Talk-transit] Public Transport Timetables

2018-11-08 Thread Mike N

On 11/8/2018 5:12 PM, john whelan wrote:


The GTFS bus stop data is of varying quality.  Locally we have an 
automated system that calls out the bus stop names and generally the 
position in the GTFS file is accurate to within a meter.


Some other transit systems are not as accurate, and the GTFS location 
for a bus stop can be more than 100 meters out.


  The result of publishing OSM's information + timetables in GTFS 
format could be a better GTFS than the official GTFS.  But if the 
OSM-GTFS feed is not updated for whatever reason, then eventually it 
just becomes stale data.   OSM-GTFS consumers would need to be aware of 
that possibility.


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


Re: [Talk-transit] Public Transport Timetables

2018-11-08 Thread Kevin Dalley
There's real time GTFS and static GTFS files.

The static files have the current schedule, routes, bus stops, etc
contained in files. The files can be downloaded, but each transit agency
has its own location.

GO-Sync, from University of Southern Florida synchronizes some static
GTFS data with openstreetmamp, route and stop info. This is info which
is useful in openstreetmap since it is a natural part of a map.

https://github.com/CUTR-at-USF/gtfs-osm-sync

While static GTFS files contain schedule information GO-Sync does not
handle this information.

OSM might include information which GTFS does not include, such as the
existence of a bench at a stop.

The schedule might have frequency, but it often has the expected times
at each bus stop for a given run. That's a lot of information, and would
take some work to match up to OSM. It isn't impossible, but it is more
information than in the proposal.

There might be advantages to having this information in OSM. It's nice
to look up the expected schedule even when you don't have a network
connection. And you might not have a connection when you're underground
waiting for the next bus.

Real time GTFS has current, more or less real time, information  on the
location of the bus, including expected arrival time. You could find out
about the 10 minute delay in your bus. This couldn't be in the static
OSM map, though the location of the information could in OSM.


On 11/8/18 10:20 AM, Mike N wrote:
> On 11/8/2018 12:06 PM, Leif Rasmussen wrote:
>>
>> I think that creating a new GTFS server would be better than using
>> transit land or transitfeeds.com , because
>> OSM would have full control over what happened to the servers and
>> which licencing was used.
>>
>> Does anyone with experience in GTFS know how an integration like that
>> could work?  Also, is what I am imagining even possible?
> 
> 
>   I would tend to think that using the GTFS standard would be the best
> approach.  The only "duplication of effort" is that there is an
> optional? inclusion of the route geometries in the GTFS feed.
> 
>   In the one case I am familiar with - OpenTripPlanner, the local
> network build process could always download the GTFS from any source as
> part of the build process.   The only advantage I see for adding another
> feed source is to add the capability of publishing a GTFS from other
> than an official source.  This allows a public GTFS feed for a city
> which is otherwise too small to maintain an electronic schedule.
> 
> 
> ___
> Talk-transit mailing list
> Talk-transit@openstreetmap.org
> https://lists.openstreetmap.org/listinfo/talk-transit


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


Re: [Talk-transit] Public Transport Timetables

2018-11-08 Thread Mike N

On 11/8/2018 12:06 PM, Leif Rasmussen wrote:


I think that creating a new GTFS server would be better than using 
transit land or transitfeeds.com , because OSM 
would have full control over what happened to the servers and which 
licencing was used.


Does anyone with experience in GTFS know how an integration like that 
could work?  Also, is what I am imagining even possible?



  I would tend to think that using the GTFS standard would be the best 
approach.  The only "duplication of effort" is that there is an 
optional? inclusion of the route geometries in the GTFS feed.


  In the one case I am familiar with - OpenTripPlanner, the local 
network build process could always download the GTFS from any source as 
part of the build process.   The only advantage I see for adding another 
feed source is to add the capability of publishing a GTFS from other 
than an official source.  This allows a public GTFS feed for a city 
which is otherwise too small to maintain an electronic schedule.



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


Re: [Talk-transit] Public Transport Timetables

2018-11-08 Thread Leif Rasmussen
Integrating GTFS seems like a much better idea than adding actual schedules
to OpenStreetMap.  I had not considered this previously because I did not
understand how GTFS is used worldwide.  Perhaps it would be possible to
start something like a new gtfs.openstreetmap.org (which would be similar
to transit.land and transitfeeds.com, but with a focus of OpenStreetMap
integration) for hosting GTFS feeds that could be integrated into OSM.
That would allow for much easier integration and maintenance.

Copying what Google has done successfully seems like a better option than
creating a big, out of date mess.

I think that creating a new GTFS server would be better than using transit
land or transitfeeds.com, because OSM would have full control over what
happened to the servers and which licencing was used.

Does anyone with experience in GTFS know how an integration like that could
work?  Also, is what I am imagining even possible?

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