Hi Jay and Steve,<div><br></div><div><div class="gmail_quote"><div>Sorry that replies don't come that quickly.</div><div>Well, let me try to answer all in one email ;-)</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<br>
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.<br></blockquote><div><br></div><div>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.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><br>
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.<br></blockquote><div><br></div><div>+1 </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;">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
float cost := getEdgeCost(time, vehicle_type, node_from, node_to);<br>
<br>
or something like that. Where time could be NULL for some default<br>
behavior, or a value that would be used to figure out the cost.<br>
vehicle_type might be helpful if there are multiple costs to<br>
traverse a link based on say, car, carpool, bus, truck, walking,<br>
taxi, etc. This could also be used to implement the rules for bus<br>
and train lines.<br></div></div></blockquote></blockquote><div><br></div><div>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?</div>
<div>Well, probably changing "vehicle_type" to "speed" would make sense, right?</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
<br>
Sounds good. Again since the GSoc Application deadline looming on 8th<br>
April, can this be considered as a valid GSoc project? If yes, I would<br>
start writing down the proposal for the same. Would like to hear<br>
thoughts of Daniel or Anton on the same.<br></div></div></blockquote></blockquote><div><br></div><div>Everything that would be an improvement for pgRouting is a valid GSoC project. </div><div>If the project plan looks reasonable difficult and doable in the GSoC time frame, then that's fine.</div>
<div><br></div><div>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.</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;"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
*Questions*:<br>
<br>
1. @Daniel - Is this somewhat what you are interested in?<br></div></div></blockquote></blockquote><div><br></div><div>Yes (and I think I can also speak for Anton)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5">
2. Can this be considered as a GSoc project?<br></div></div></blockquote></blockquote><div><br></div><div>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. ;-)</div>
<div>What is a reasonable proposal depends on each applicant's skills. </div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div><div class="h5">
3. pgRouting mainly provides routing for postgres. So, do we<br>
assume the<br>
data pertaining the time-dependent values for each edge present<br>
in the<br>
postgres database? If yes we will need to finalise the format of the<br>
data stored right?<br>
4. Is there already a standard format for storing time-dependent<br>
edge<br>
weights data, or we should assume the function that returns the edge<br>
cost as black box and just code the time dependent functionality<br>
without<br>
worrying as to how the function actually gets the values from<br>
(database<br>
or somewhere else)<br></div></div></blockquote></blockquote><div><br></div><div>I think to find some answer to this question should be also seen part of the implementation.</div><div>I don't see a problem to start with some first approach and change it later if there seems to be a better one.</div>
<div><br></div><div>Jay, did I miss something?</div><div><br></div><div>Daniel </div><div><br></div><div><br></div></div>-- <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>