[pgrouting-dev] Re: Time dependent data and input format

I may be telling you something you already know (if so I apologize!),
but the Google Transit Feed Specification (GTFS) is a commonly used
format for providing time-dependent routing data:
http://code.google.com/transit/spec/transit_feed_specification.html

City-Go-Round has a (US-oriented) list of transit agencies that
provide such data: http://www.citygoround.org/agencies/

Thanks,
Jordan

On 4/30/2011 8:21 AM, Jordan Anderson wrote:

I may be telling you something you already know (if so I apologize!),
but the Google Transit Feed Specification (GTFS) is a commonly used
format for providing time-dependent routing data:
http://code.google.com/transit/spec/transit_feed_specification.html

City-Go-Round has a (US-oriented) list of transit agencies that
provide such data: http://www.citygoround.org/agencies/

Hi Jordan,

Thanks for this information. I was not aware of this standard or the agency list. These are great resources.

-Steve

2011/4/30 Stephen Woodbridge <woodbri@swoodbridge.com>

On 4/30/2011 8:21 AM, Jordan Anderson wrote:

I may be telling you something you already know (if so I apologize!),
but the Google Transit Feed Specification (GTFS) is a commonly used
format for providing time-dependent routing data:
http://code.google.com/transit/spec/transit_feed_specification.html

City-Go-Round has a (US-oriented) list of transit agencies that
provide such data: http://www.citygoround.org/agencies/

Hi Jordan,

Thanks for this information. I was not aware of this standard or the agency list. These are great resources.

-Steve

I thought GTFS was designed for public transportation. So it would be probably more suitable for Kishore.

When I looked at GTFS some time ago it seemed to be like a collection of CSV files. I was looking for some JSON-like or XML format that time. But thinking about it now it could be interesting to create tables in PostgreSQL according to GTFS.

Daniel


pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev


Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

On 4/30/2011 11:00 AM, Daniel Kastl wrote:

2011/4/30 Stephen Woodbridge <woodbri@swoodbridge.com
<mailto:woodbri@swoodbridge.com>>

    On 4/30/2011 8:21 AM, Jordan Anderson wrote:

        I may be telling you something you already know (if so I
        apologize!),
        but the Google Transit Feed Specification (GTFS) is a commonly used
        format for providing time-dependent routing data:
        http://code.google.com/transit/spec/transit_feed_specification.html

        City-Go-Round has a (US-oriented) list of transit agencies that
        provide such data: http://www.citygoround.org/agencies/

    Hi Jordan,

    Thanks for this information. I was not aware of this standard or the
    agency list. These are great resources.

    -Steve

I thought GTFS was designed for public transportation. So it would be
probably more suitable for Kishore.

When I looked at GTFS some time ago it seemed to be like a collection of
CSV files. I was looking for some JSON-like or XML format that time. But
thinking about it now it could be interesting to create tables in
PostgreSQL according to GTFS.

Daniel,

Correct, Kishore is doing the multi-modal rouuting, but it is also time dependent, so both Kishore and Jay will be developing time dependent algorithms.

Kishore is working on multi-modal routing and Jay is working on other time dependent routing both of these implementations have can be based on a common engine and an appropriate method to determine what edges are connected to the current edge at any given time or some time in the near future is in the case of a schedule and what the cost of the edge is.

So, I'm not sure how you and Anton want to deal with this. Some options that come to mind are:

1. let the two project continue independently
2. try to develop an interface that both projects will develop code to
3. let the two projects collaborate on the engine interface and pieces
4. some other ideas that someone might propose

I think that 1 and 2 are probably the best options because each student needs to be in control of there own destiny with regards to success or failure. If 2. is reasonable light weight, and they both implement their own version of that I do not see an huge issue with that other than the redundancy of effort.

Thoughts? Everyone.

-Steve