[pgrouting-dev] Time dependent data and input format
Stephen Woodbridge
woodbri at swoodbridge.com
Fri Jul 29 08:20:19 EDT 2011
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?
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
> On Thu, Jul 28, 2011 at 8:32 PM, Daniel Kastl <daniel at georepublic.de
> <mailto:daniel at georepublic.de>> wrote:
>
> If possible I would like to use the same for testing as PostGIS:
> http://trac.osgeo.org/postgis/wiki/DevWikiCUnit
> http://trac.osgeo.org/postgis/wiki/DevWikiMain#PatchSubmissionGuidelines
>
> Except there are good arguments to do it a different way.
>
> Daniel
>
>
>
>
>
> On Thu, Jul 28, 2011 at 6:53 PM, Kishore Kumar <justjkk at gmail.com
> <mailto:justjkk at gmail.com>> wrote:
>
> Hi,
>
> Updated the wiki page and added this:
>
> https://github.com/pgRouting/pgrouting/wiki/Automated-Testing-(Unit-Tests)#wiki-SQL_Testing
> <https://github.com/pgRouting/pgrouting/wiki/Automated-Testing-%28Unit-Tests%29#wiki-SQL_Testing>
>
> Looking for improvements in the workflow.
>
> Regards,
> J Kishore kumar.
>
> On Thu, Jul 28, 2011 at 2:52 PM, Jay Mahadeokar
> <jai.mahadeokar at gmail.com <mailto:jai.mahadeokar at gmail.com>> wrote:
> >
> >
> > On Thu, Jul 28, 2011 at 2:47 PM, Kishore Kumar
> <justjkk at gmail.com <mailto:justjkk at gmail.com>> wrote:
> >>
> >> Hi,
> >>
> >> The testing framework currently doesn't have a proper
> documentation
> >> except the somewhat readable python code. I am also not sure
> what
> >> level of documentation should suffice. Is the python testing
> framework
> >> going to stay or should we move to c?
> >>
> >
> > I am not sure about others, but I have not worked with python
> before. So, I
> > would love to go with C if given a choice!
> >
> >>
> >> Thanks & Regards,
> >> J Kishore kumar.
> >>
> >> On Tue, Jul 26, 2011 at 4:40 AM, Daniel Kastl
> <daniel at georepublic.de <mailto:daniel at georepublic.de>>
> >> wrote:
> >> >> Daniel, Anton, is there anything specific that I need to
> do with
> >> >> regards
> >> >> to the project, so that it can be bundled with the
> pgRouting 2.0?
> >> >> Currently
> >> >> I am using a modified CMake file[2], and not compiling
> the test
> >> >> framework.
> >> >> Till now, I have not worked with this testing framework
> designed by
> >> >> Kishore
> >> >> (right?) so should I read any docs that will get me
> introduced with it?
> >>
> >> > Sorry, the test framework I don't have a clear opinion
> yet. I think it's
> >> > Kishore's proposed testing but anyone is free to make
> suggestions how to
> >> > improve it.
> >> _______________________________________________
> >> pgrouting-dev mailing list
> >> pgrouting-dev at lists.osgeo.org
> <mailto:pgrouting-dev at lists.osgeo.org>
> >> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
> >
> >
> >
> > --
> > Regards,
> > -Jay Mahadeokar
> >
> >
> > _______________________________________________
> > pgrouting-dev mailing list
> > pgrouting-dev at lists.osgeo.org
> <mailto:pgrouting-dev at lists.osgeo.org>
> > http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
> >
> >
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
>
>
>
> --
> Georepublic UG & Georepublic Japan
> eMail: daniel.kastl at georepublic.de <mailto:daniel.kastl at georepublic.de>
> Web: http://georepublic.de <http://georepublic.de/>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org <mailto:pgrouting-dev at lists.osgeo.org>
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
>
>
>
>
> --
> Regards,
> -Jay Mahadeokar
>
>
>
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
More information about the pgrouting-dev
mailing list