[pgrouting-dev] Support for Time Constraints

[Jay Mahadeokar]

On Thu, Mar 31, 2011 at 7:15 AM, Daniel Kastl <daniel at georepublic.de> wrote:

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


You have answered pretty much all the doubts for now. Thanks for the reply!
And best luck with your project. (I will keep pinging if any query comes up
:)  )



>
> Daniel
>
>
> --
> Georepublic UG & Georepublic Japan
> eMail: daniel.kastl at georepublic.de
> Web: http://georepublic.de
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
>


-- 
Regards,
-Jay Mahadeokar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20110331/d7d1619f/attachment-0001.html