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

[Stephen Woodbridge]

On 4/30/2011 11:00 AM, Daniel Kastl wrote:
>
>
> 2011/4/30 Stephen Woodbridge <woodbri at swoodbridge.com
> <mailto:woodbri at 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