[pgrouting-dev] Time dependent data and input format

Jay Mahadeokar jai.mahadeokar at gmail.com
Fri Jul 29 08:39:39 EDT 2011


On Fri, Jul 29, 2011 at 5:50 PM, Stephen Woodbridge <woodbri at swoodbridge.com
> wrote:

> On 7/29/2011 5:49 AM, Jay Mahadeokar wrote:
>
>> Hi all,
>>
>> I was looking at ways to optimise the tdsp implementation.
>>
>> Currently, if the time-interval is suppose 24, (24 hours) and the travel
>> time expected is around 60 hours, then the tdsp-wrapper query retrieves
>> total 60 intervals and the data is repeated for the 24 hour intervals.
>> (I hope what i am trying to say is clear).
>>
>> This is unnecessary space wastage. So, I edited the weight_map class to
>> accommodate a variables is_cyclic and the cycle_interval, which will
>> keep track of the cyclic nature of the data. So, actually only the 24
>> hour data will be fed to weight map and then it will be reused in cycles.
>>
>> Because of the good design, I guess this has scaled up really nice and
>> there is no need to modify actual core tdsp. Just the weight_map's
>> get_travel_time() function and the wrapper plsql function needed to be
>> altered.
>>
>
> This makes perfect sense and sounds like a great optimization.
>
>
>  Now, in the main query, I am thinking of adding one more boolean
>> variable - is_cyclic which will be enabled if the data is cyclic in
>> nature.  Should we keep this? Or we should assume that the data will be
>> always cyclic.
>> Any other views on the same are welcome.
>>
>
> I guess my questions are:
> How does this get set?
> What are the advantages of setting it?
> Is there a way to dynamically check if it is cyclic at the start and avoid
> having the app builder set it up?
>
>
Advantages of setting it:
If the data is not cyclic, then the whole data will be expected to reside in
database itself. So, if the upper bound of the time is reached then by
default, we can assume that the travel_time corresponding to the last
existing time window should be used for such cases.

If data is cyclic, then we need to start all over again.  These are the
cases, what I could think of.

How does this get set:
The tdsp query must have an additional parameter - is_cyclic which should be
used to set the is_cyclic flag of the weight_map.

Now, if data is cyclic, then the plsql function that retrieves the data
should be written in such a way that if interval is suppose 0 - 24, and
start time is 21, then  21->0 and 20->23. After that the cyclic flag will
indicate us to loop again.  The plsql function will be generally written by
app developer and he should take care of this. (I have already implemented
this in my code.)

If data is cyclic, he should pass the flag appropriately. If is_cyclic is
false, we can assume that if intervals are exhausted, we will keep using
time corresponding to last interval.

Is this reasonable?



> I suppose it is not a big deal for the app builder to set this flag since
> he will know if the data loaded is cyclic in nature. I assume you are only
> looking for some indication if there are cyclic entries in the data and not
> if this specific query has a cyclic nature which would be impossible to know
> without analyzing the start time and max time window, in which case we
> should figure that out automatically because the user making the request is
> not likely to know anything more than start, end and start time or end time.
>
> -Steve
>
-- 
Regards,
-Jay Mahadeokar
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/pgrouting-dev/attachments/20110729/23e3fd78/attachment-0001.html


More information about the pgrouting-dev mailing list