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