Hi Jay and Steve,<div><br></div><div>We always get long email chains here ;-)</div><div>So I will also take Jay's initial email to answer.</div><div><br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>1. What should be the input format for time dependent data?<br><br></blockquote><div><br></div><div>As Steve said, the additional information is "time". The rest should be same as with other shortest path algorithm.</div>
<div><br></div><div>For Darp algorithm that also cares about schedules, Anton took "timestamp" as format, which can be "with timezone" or "without timezone". Anton, maybe you can share some obstacles you had with timestamp format.</div>
<div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">2. What are the options to obtain real world time dependent data? If it is not freely available, then what are the alternatives to test our code? (randomly generated time dependent data would be rather inadequate) <br>
</blockquote><div><br></div><div>I know that in Japan they collect so called "VICS" data with time dependent information. There night be a possibility to get sample data, but it's probably better to use resources Steve mentioned, because the documentation would be in English then.</div>
<div>Of course if you collect such kind of data in India and know how to get some, that would be great.</div><div><br></div><div>I think we should prefer data that is free to use. For pgRouting users it usually helps a lot to be able to download some sample application with data, and I guess we couldn't offer this if we use Navteq data.</div>
<div><br></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br><br>According to Stephen: <br><ul><li>It is better to assume data to be present in a simpler model that is easy to work.</li>
<li>It is better to have 5 simple to work with tables than 1-2 complex ones. </li><li>We can then provides data loaders that will convert the data from different format into our designed model.</li></ul></blockquote><div>
</div><div>I agree with Steve. You can make complex tables with table joins and views later. </div><div>Also we can define the structure and require users to load the data. Someone then may want to write a Navteq data loader, but we don't need to design our model according to Navteq.</div>
<div><br></div><div>Daniel </div><div><font color="#888888">
</font><br>_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org">pgrouting-dev@lists.osgeo.org</a><br>
<a href="http://lists.osgeo.org/mailman/listinfo/pgrouting-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/pgrouting-dev</a><br>
<br></div></div><br><br clear="all"><br>-- <br><span style="font-family:arial, sans-serif;font-size:13px;border-collapse:collapse">Georepublic UG & Georepublic Japan<br>eMail: <a href="mailto:daniel.kastl@georepublic.de" style="color:rgb(66, 99, 171)" target="_blank">daniel.kastl@georepublic.de</a><br>
Web: <a href="http://georepublic.de/" style="color:rgb(66, 99, 171)" target="_blank">http://georepublic.de</a></span><br>
</div>