Anton, Daniel,
I have been fighting with the dijkstra results because we do not return things like the parent id of a path and we definitely do not return the correct edge ids.
So with some help from the boost users list and banging my head against the C++ wall, being only a C programmer :), I have some code that works for me.
http://pastebin.com/qa1caiXs
In dijkstra.h I also have defined the following structs:
typedef struct edge
{
int id;
int source;
int target;
float8 cost;
float8 rcost;
} edge_t;
typedef struct path_element
{
int vertex_id;
int parent_id;
int edge_id;
float8 cost;
} path_element_t;
You should be able to copy the appropriate parts of this file and update the driving distance code and the low level dijkstra code to return more correct and useful results. I'm using this code outside of the postgresql server, but it should not require any significant changes. Since I'm not developing code in the database, I will leave that as an exercise for you guys to work out and test.
Thanks,
-Steve
Hi Steve,
Thank you! But I also rely on Anton’s skills here.
Not to get lost in the mailing list archive, I copied the code and links to this Wiki page:
https://github.com/pgRouting/pgrouting/wiki/Revision-of-return-results
It’s part of the 2.0 plan. If you have more ideas or request, feel free to add them there:
https://github.com/pgRouting/pgrouting/wiki/2.0-Development-Plan
Daniel
2011/7/1 Stephen Woodbridge <woodbri@swoodbridge.com>
Anton, Daniel,
I have been fighting with the dijkstra results because we do not return things like the parent id of a path and we definitely do not return the correct edge ids.
So with some help from the boost users list and banging my head against the C++ wall, being only a C programmer :), I have some code that works for me.
http://pastebin.com/qa1caiXs
In dijkstra.h I also have defined the following structs:
typedef struct edge
{
int id;
int source;
int target;
float8 cost;
float8 rcost;
} edge_t;
typedef struct path_element
{
int vertex_id;
int parent_id;
int edge_id;
float8 cost;
} path_element_t;
You should be able to copy the appropriate parts of this file and update the driving distance code and the low level dijkstra code to return more correct and useful results. I’m using this code outside of the postgresql server, but it should not require any significant changes. Since I’m not developing code in the database, I will leave that as an exercise for you guys to work out and test.
Thanks,
-Steve
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de
Hi Steve,
Looks great to me!
Actually it looks like we don't need path_element.edge_id anymore or
we can replace it with your path_element.parent_id:
p = vertex(predecessors[*vi], graph);
pe.edge_id = graph[p].id;
Actually edge_id doesn't have much sense, we added it to unify outputs.
Great job! Thank you!
Anton.
On 7/1/11, Daniel Kastl <daniel@georepublic.de> wrote:
Hi Steve,
Thank you! But I also rely on Anton's skills here.
Not to get lost in the mailing list archive, I copied the code and links to
this Wiki page:
https://github.com/pgRouting/pgrouting/wiki/Revision-of-return-results
It's part of the 2.0 plan. If you have more ideas or request, feel free to
add them there:
https://github.com/pgRouting/pgrouting/wiki/2.0-Development-Plan
Daniel
2011/7/1 Stephen Woodbridge <woodbri@swoodbridge.com>
Anton, Daniel,
I have been fighting with the dijkstra results because we do not return
things like the parent id of a path and we definitely do not return the
correct edge ids.
So with some help from the boost users list and banging my head against
the
C++ wall, being only a C programmer :), I have some code that works for
me.
http://pastebin.com/qa1caiXs
In dijkstra.h I also have defined the following structs:
typedef struct edge
{
int id;
int source;
int target;
float8 cost;
float8 rcost;
} edge_t;
typedef struct path_element
{
int vertex_id;
int parent_id;
int edge_id;
float8 cost;
} path_element_t;
You should be able to copy the appropriate parts of this file and update
the driving distance code and the low level dijkstra code to return more
correct and useful results. I'm using this code outside of the postgresql
server, but it should not require any significant changes. Since I'm not
developing code in the database, I will leave that as an exercise for you
guys to work out and test.
Thanks,
-Steve
______________________________**_________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de
--
Georepublic UG (haftungsbeschränkt)
Salzmannstraße 44,
81739 München, Germany
Anton Patrushev
CTO
eMail: anton.patrushev@georepublic.de
Web: http://georepublic.de
Tel: +49 (089) 420 959 519
Sip: 1959519@sipgate.de
Commercial register: Amtsgericht München, HRB 181428
CEO: Daniel Kastl
On 7/1/2011 1:42 AM, Anton Patrushev wrote:
Hi Steve,
Looks great to me!
Actually it looks like we don't need path_element.edge_id anymore or
we can replace it with your path_element.parent_id:
p = vertex(predecessors[*vi], graph);
pe.edge_id = graph[p].id;
Actually edge_id doesn't have much sense, we added it to unify outputs.
I am finding the correct edge_id to be useful even though we have a way to retrieve it. We can obviously look it up after the fact from the node ids but that can be expensive if you have a look to look up.
For example if you wanted all the out bound edges of a path from a give start node you can get it by collecting the edge ids for that path and then issuing a query like:
select the_geom from streets
where gid in (<list of collected edge_ids>);
This is not ordered correctly and segments are not flipped for direction of travel, but you get the idea.
-Steve
Great job! Thank you!
Anton.
On 7/1/11, Daniel Kastl<daniel@georepublic.de> wrote:
Hi Steve,
Thank you! But I also rely on Anton's skills here.
Not to get lost in the mailing list archive, I copied the code and links to
this Wiki page:
https://github.com/pgRouting/pgrouting/wiki/Revision-of-return-results
It's part of the 2.0 plan. If you have more ideas or request, feel free to
add them there:
https://github.com/pgRouting/pgrouting/wiki/2.0-Development-Plan
Daniel
2011/7/1 Stephen Woodbridge<woodbri@swoodbridge.com>
Anton, Daniel,
I have been fighting with the dijkstra results because we do not return
things like the parent id of a path and we definitely do not return the
correct edge ids.
So with some help from the boost users list and banging my head against
the
C++ wall, being only a C programmer :), I have some code that works for
me.
http://pastebin.com/qa1caiXs
In dijkstra.h I also have defined the following structs:
typedef struct edge
{
int id;
int source;
int target;
float8 cost;
float8 rcost;
} edge_t;
typedef struct path_element
{
int vertex_id;
int parent_id;
int edge_id;
float8 cost;
} path_element_t;
You should be able to copy the appropriate parts of this file and update
the driving distance code and the low level dijkstra code to return more
correct and useful results. I'm using this code outside of the postgresql
server, but it should not require any significant changes. Since I'm not
developing code in the database, I will leave that as an exercise for you
guys to work out and test.
Thanks,
-Steve
______________________________**_________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/**mailman/listinfo/pgrouting-dev<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
--
Georepublic UG& Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de
Hi Daniel and Anton,
Thanks for the wiki page. I just replaced the code there with a newer version that is much cleaner and more readable. Seems like it should be faster also, but I have not run any tests. The changes get rid of a bunch of the template prototypes so it is more readable and more compact and it now uses std::copy to copy the results to the C path array.
I got a lot of help from Alex on the boost list. My knowledge of C++ is greatly lacking 
but I found that this exercise was extremely educational.
-Steve
On 7/1/2011 12:46 AM, Daniel Kastl wrote:
Hi Steve,
Thank you! But I also rely on Anton's skills here.
Not to get lost in the mailing list archive, I copied the code and links
to this Wiki page:
https://github.com/pgRouting/pgrouting/wiki/Revision-of-return-results
It's part of the 2.0 plan. If you have more ideas or request, feel free
to add them there:
https://github.com/pgRouting/pgrouting/wiki/2.0-Development-Plan
Daniel
2011/7/1 Stephen Woodbridge <woodbri@swoodbridge.com
<mailto:woodbri@swoodbridge.com>>
Anton, Daniel,
I have been fighting with the dijkstra results because we do not
return things like the parent id of a path and we definitely do not
return the correct edge ids.
So with some help from the boost users list and banging my head
against the C++ wall, being only a C programmer :), I have some code
that works for me.
http://pastebin.com/qa1caiXs
In dijkstra.h I also have defined the following structs:
typedef struct edge
{
int id;
int source;
int target;
float8 cost;
float8 rcost;
} edge_t;
typedef struct path_element
{
int vertex_id;
int parent_id;
int edge_id;
float8 cost;
} path_element_t;
You should be able to copy the appropriate parts of this file and
update the driving distance code and the low level dijkstra code to
return more correct and useful results. I'm using this code outside
of the postgresql server, but it should not require any significant
changes. Since I'm not developing code in the database, I will leave
that as an exercise for you guys to work out and test.
Thanks,
-Steve
______________________________ _________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
http://lists.osgeo.org/ mailman/listinfo/pgrouting-dev
<http://lists.osgeo.org/mailman/listinfo/pgrouting-dev>
--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>
_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev