[pgrouting-dev] Support for Time Constraints

[Daniel Kastl]

Hi Jay and Steve,

Sorry that replies don't come that quickly.
Well, let me try to answer all in one email ;-)


> Remember that they are currently based out of Japan and given the power
> problems and infrastructure issues they might have spotty access to the net.
>

We're still in Japan and have internet as before. Osaka wasn't/isn't
actually affected directly. But we're affected by some busy project.


>
> I think it is important that whatever you do, needs to be integrated with
> pgRouting and you need to make sure you allow for time for that.
>

+1



>>    float cost := getEdgeCost(time, vehicle_type, node_from, node_to);
>>
>>    or something like that. Where time could be NULL for some default
>>    behavior, or a value that would be used to figure out the cost.
>>    vehicle_type might be helpful if there are multiple costs to
>>    traverse a link based on say, car, carpool, bus, truck, walking,
>>    taxi, etc. This could also be used to implement the rules for bus
>>    and train lines.
>>
>
I think one of the difficulties with routing topic is that everyone (also
myself) immediately think about routing in terms of vehicle types. It's the
easiest example to explain pgRouting, but I think one premise of pgRouting
is that it should work for any kind of network. Let's say your network would
be the human nervous system. What is a vehicle there?
Well, probably changing "vehicle_type" to "speed" would make sense, right?



>
>> Sounds good. Again since the GSoc Application deadline looming on 8th
>> April, can this be considered as a valid GSoc project? If yes, I would
>> start writing down the proposal for the same. Would like to hear
>> thoughts of Daniel or Anton on the same.
>>
>
Everything that would be an improvement for pgRouting is a valid GSoC
project.
If the project plan looks reasonable difficult and doable in the GSoC time
frame, then that's fine.

In the past years I usually found it easy to see, which proposal was written
carefully and which one in a rush. Every mentor of the OSGeo organization of
GSoC will be able to take a look and give comments, so for pgRouting related
proposals it makes it easier for us to defend a nicely written proposal of
course.


        *Questions*:
>>
>>        1. @Daniel - Is this somewhat what you are interested in?
>>
>
Yes (and I think I can also speak for Anton)


>         2. Can this be considered as a GSoc project?
>>
>
I think so. As I probably mentioned already, it's important that there will
be some nice result to show later. So too ambitious proposals may make us
dreaming, but don't bring anything in the end when they fail. ;-)
What is a reasonable proposal depends on each applicant's skills.



>         3. pgRouting mainly provides routing for postgres. So, do we
>>        assume the
>>        data pertaining the time-dependent values for each edge present
>>        in the
>>        postgres database? If yes we will need to finalise the format of
>> the
>>        data stored right?
>>        4. Is there already a standard format for storing time-dependent
>>        edge
>>        weights data, or we should assume the function that returns the
>> edge
>>        cost as black box and just code the time dependent functionality
>>        without
>>        worrying as to how the function actually gets the values from
>>        (database
>>        or somewhere else)
>>
>
I think to find some answer to this question should be also seen part of the
implementation.
I don't see a problem to start with some first approach and change it later
if there seems to be a better one.

Jay, did I miss something?

Daniel


-- 
Georepublic UG & Georepublic Japan
eMail: daniel.kastl at georepublic.de
Web: http://georepublic.de
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20110331/e879550d/attachment.html