Hi,<div><br></div><div><b>I am currently trying to implement apsp as follows: </b></div><div><div>CREATE OR REPLACE FUNCTION all_pairs_shortest_path(sql text, directed boolean, has_reverse_cost boolean)</div><div> RETURNS SETOF apsp_result</div>
<div> AS '$libdir/librouting'</div><div> LANGUAGE 'C' IMMUTABLE STRICT;</div></div><div><br></div><div>Now, I think my boost_apsp() function is working for small input data, and I want to test if the overall query is working. I have coded apsp.c accordingly.</div>
<div><br></div><div>I have modified /core/cMakeLists.txt so as to just build apsp and dijkstra for now: </div><div>"ADD_LIBRARY(routing SHARED dijkstra.c apsp.c boost_wrapper.cpp apsp_boost_wrapper.cpp)"</div><div>
<br></div><div>Here is the output after I run "cmake -DWITH_DD=ON", and then "make": </div><div><br></div><div><div>jay@jay-HP-Compaq-6720s:~/Desktop/pgRouting/pgRouting-pgrouting-7b07040$ make</div><div>
[ 50%] Built target routing_dd</div><div>Scanning dependencies of target routing</div><div>[ 62%] Building C object core/src/CMakeFiles/routing.dir/apsp.o</div><div>Linking CXX shared library ../../lib/librouting.so</div>
<div>[100%] Built target routing</div><div>jay@jay-HP-Compaq-6720s:~/Desktop/pgRouting/pgRouting-pgrouting-7b07040$ sudo make install</div><div>[sudo] password for jay: </div><div>[ 50%] Built target routing_dd</div><div>
[100%] Built target routing</div><div>Install the project...</div><div>-- Install configuration: ""</div><div>-- Installing: /usr/lib/postgresql/8.4/lib/librouting.so</div><div>-- Installing: /usr/share/postlbs/routing_core.sql</div>
<div>-- Up-to-date: /usr/share/postlbs/routing_core_wrappers.sql</div><div>-- Up-to-date: /usr/share/postlbs/routing_topology.sql</div><div>-- Up-to-date: /usr/share/postlbs/matching.sql</div><div>-- Installing: /usr/lib/postgresql/8.4/lib/librouting_dd.so</div>
<div>-- Installing: /usr/share/postlbs/routing_dd.sql</div><div>-- Installing: /usr/share/postlbs/routing_dd_wrappers.sql</div></div><div><br></div><div>I think there were no compilation errors while compiling apsp files. Now, when i log into postgres and query for shortest_path() on pgrouting-workshop database, I get the correct results.</div>
<div><br></div><div><b>But, query on all_pairs_shortest_path() gives this: </b>SELECT * from all_pairs_shortest_path('SELECT gid as id,source::integer,target::integer,length::double precision as cost from ways',false,false);</div>
<div><div>ERROR: function all_pairs_shortest_path(unknown, boolean, boolean) does not exist</div><div>LINE 1: SELECT * from all_pairs_shortest_path('SELECT gid as id,sour...</div><div>HINT: No function matches the given name and argument types. You might need to add explicit type casts.</div>
</div><div><br></div><div>I tried restarting the postgres server too.</div><div><br></div><div><b>Questions:</b></div><div><b><br></b></div><div>1. For testing the new function, am I following correct approach?</div><div>
<br></div><div>2. I will try to learn some git commands and upload my source code in the repository that I have forked here: <a href="https://github.com/jay-mahadeokar/pgrouting">https://github.com/jay-mahadeokar/pgrouting</a>, I guess it would be easier for you guys to provide help and see what is actually going on that way, right?</div>
<meta http-equiv="content-type" content="text/html; charset=utf-8"><div><br><div class="gmail_quote">On Fri, Dec 17, 2010 at 4:48 PM, Daniel Kastl <span dir="ltr"><<a href="mailto:daniel@georepublic.de">daniel@georepublic.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">Hi Jay,<div><br></div><div>Thank you for giving us some updates!</div><div>Anton traveled to freezing cold Siberia yesterday and it could take some days for him to defrost ;-)</div>
<div>So maybe it will a while until he can answer.</div>
<div><br></div><div>I will try to take a look the next days and see if I can give some advice, but probably it's better to hear Anton.</div><div><br></div><font color="#888888"><div>Daniel</div></font><div><div></div>
<div class="h5"><div><br></div><div><br></div><div><br><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br><b>Some Questions:</b><br><br>Now, I need to code apsp.c which will retrieve the edges / nodes from postgres database and call the above function. The result will be returned as apsp_result.<br>
<br>For dijkestra, we have the following query format: <br>
SELECT gid, source, target, cost FROM edge_table<br><br>For, apsp will the query format remain same? <br><br>Or do we take the vertices(in form of points) as input separately, in some other format? One application of this might be when a user will select a set of points on map and call apsp on those points. </blockquote>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br><br><br><div class="gmail_quote"><div><div></div><div>On Wed, Dec 8, 2010 at 2:12 PM, Daniel Kastl <span dir="ltr"><<a href="mailto:daniel@georepublic.de" target="_blank">daniel@georepublic.de</a>></span> wrote:<br>
</div></div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div><div></div><div>
<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<br></blockquote></div><div><div>For now, can we go ahead and implement the above algo in pgRouting? I am thinking of a warshall_wrapper class that would call the above function, and the actuall warshall apsp would return distances in form of rows, each row having three columns:</div>
<div>source, target, distance. (We will have nC2 such rows for now..)</div></div></div></blockquote><div><br></div></div><div>As Anton mentioned, this can get confusing sometimes. Too many sources and targets, can be the ones of an edge or of a route.</div>
<div>Any good idea how define names in an easy to understand and clear way is welcome. This is probably going to become more of an issue as more pgRouting grows.</div><div><br></div><div>@Anton: maybe we should somewhere define a dictionary of terms we use and what we use them for.</div>
<div>Other thing, I didn't really get your answer how to prevent mixing source/target ... was there a "not" missing? It wasn't clear to me </div><div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex">
<div class="gmail_quote"><div><br></div><div><div>Some queries:</div><div><br></div><div>1. I have not yet tried modifying the pgRouting source code, and compiling other files together with the existing ones. I am completely new to cmake and will try and learn how to work with that. From what I have understood, every new algorithm that we add to existing set will have a similar flow and similar files etc. Is there any doc which can guide as to what configuration changes would be needed for adding a new algo (For example we would usually add following files: algo.h, algo.cpp, algo.sql, algo_boost_wrapper.cpp etc). (I hope my query is clear)</div>
</div></div></blockquote><div><br></div></div><div>If I find some time I want to study the CMake manual, too, and see if we can make some improvements here and there. I think it was also new for Anton at the time of writing the files, so if you find some possible improvements, let me know.</div>
<div><br></div><div>There are no "coding standards" defined yet, which would be probably a good idea when more algorithm will be implemented in the future.</div><div>Same as above, if you have some idea, then you can share with us. We're open for criticism! Otherwise I believe it's sometimes better to have a couple of algorithms first and then see what could be "standardized" and define them based on our experience.</div>
<div><br></div><div>Btw., if you want to make use of GitHub, then you can create an account and fork the pgRouting repository: <a href="https://github.com/pgRouting/pgrouting" target="_blank">https://github.com/pgRouting/pgrouting</a></div>
<div>It will be then easy to apply your changes.</div><div><br></div><div>Anton, where will APSP go? To "core" or to "extras"?</div><div>Seeing the number of extensions grow, does this structure still work for us?</div>
<div>How do we define what is "core" and what is "extra"? </div><div>I think the initial main idea was to provide pgRouting without Gaul and CGAL dependencies.</div><div><div>
<br></div><div> </div><blockquote class="gmail_quote" style="margin:0pt 0pt 0pt 0.8ex;border-left:1px solid rgb(204, 204, 204);padding-left:1ex"><div class="gmail_quote"><div>
<div><br></div><div>2. Are there any sample test cases/scripts, which were used to test dijkstras algo (which can be useful here too)? </div></div></div></blockquote><div><br></div></div><div>I think that pgRouting should have unit tests ... but we don't have so far, which is not so good ;-)</div>
<div>Here is a ticket already: <a href="https://github.com/pgRouting/pgrouting/issues#issue/20" target="_blank">https://github.com/pgRouting/pgrouting/issues#issue/20</a></div><div>As usual it's a lack of time to work on this.</div>
<div>
<br></div><div>It's probably better to have some generic testing data than just take OSM data from the workshop, Anton.</div><div>OSM data won't allow us to test all possible functionality some functions provide.</div>
<div><br></div><font color="#888888"><div>Daniel</div><div><br></div><div><br></div></font></div><div><div></div><div><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></div><br></div></div><div>_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">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></blockquote></div><br><br clear="all"><br>-- <br>Regards,<br><font color="#888888">-Jay Mahadeokar<br><br>
</font><br>_______________________________________________<br>
pgrouting-dev mailing list<br>
<a href="mailto:pgrouting-dev@lists.osgeo.org" target="_blank">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></blockquote></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>
</div></div><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></blockquote></div><br><br clear="all"><br>-- <br>Regards,<br>-Jay Mahadeokar<br><br>
</div>