Was just wondering if anyone has had any time to address the bug in the shortest_path_shooting_star algorithm where it ignores one way street designations?
–
Steve Horn
Was just wondering if anyone has had any time to address the bug in the shortest_path_shooting_star algorithm where it ignores one way street designations?
–
Steve Horn
Hi Steve,
I have not enough knowledge about Shooting Star algorithm and Boost Graph Library,
but I think that the bug occurred in “core / src / shooting_star_boost_wrapper.cpp” after 1.0.3 release(2008/09/04).
[History for core-src-shooting_star_boost_wrapper.cpp - pgRouting-pgrouting]
https://github.com/pgRouting/pgrouting/commits/master/core/src/shooting_star_boost_wrapper.cpp
And, old issue #190 may be related.
[#190 (First edge and last edge don’t respect the one way restriction) – pgRouting]
ftp://ftp.remotesensing.org/pgrouting/forum/pgrouting.postlbs.org/ticket/190.html
Isn’t there any person who have enough knowledge about Shooting Star argorithm and Boost Graph Library?
Regards,
2012/6/9 Steve Horn <steve@stevehorn.cc>
Was just wondering if anyone has had any time to address the bug in the shortest_path_shooting_star algorithm where it ignores one way street designations?
–
Steve Horn
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Hi all,
In all likelihood, we will abandon the shooting star code unless someone want to try and figure out the implementation and try to fix the code. Currently the TRSP code does everything that shooting star does, so there is not loss of functionality AND it is significantly faster something like 2+ times faster, and it does not have any bugs in it.
On thought I had was that we could wire in the TRSP algorithm to the Shooting Star function signature, but give that we would like to rationalize all the function APIs potentially in 2.0 if we can ever get the time to do that release, I'm not sure what the value of having two function signatures, trsp and shooting star both using the same code.
Anton was the last developer the tried to work on it and he is gone. We would be happy to take patches if someone can figure out the Boost code.
Thanks,
-Steve
On 6/8/2012 7:15 PM, Sanak wrote:
Hi Steve,
I have not enough knowledge about Shooting Star algorithm and Boost
Graph Library,
but I think that the bug occurred in "core / src /
shooting_star_boost_wrapper.cpp" after 1.0.3 release(2008/09/04).
[History for core-src-shooting_star_boost_wrapper.cpp - pgRouting-pgrouting]
https://github.com/pgRouting/pgrouting/commits/master/core/src/shooting_star_boost_wrapper.cpp
And, old issue #190 may be related.
[#190 (First edge and last edge don't respect the one way restriction) –
pgRouting]
ftp://ftp.remotesensing.org/pgrouting/forum/pgrouting.postlbs.org/ticket/190.html
Isn't there any person who have enough knowledge about Shooting Star
argorithm and Boost Graph Library?
Regards,
2012/6/9 Steve Horn <steve@stevehorn.cc <mailto:steve@stevehorn.cc>>Was just wondering if anyone has had any time to address the bug in
the shortest_path_shooting_star algorithm where it ignores one way
street designations?--
Steve Horn_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
Had no idea that the TRSP algo would do the trick.
I will give that a try!
On Saturday, June 9, 2012, Stephen Woodbridge wrote:
Hi all,
In all likelihood, we will abandon the shooting star code unless someone want to try and figure out the implementation and try to fix the code. Currently the TRSP code does everything that shooting star does, so there is not loss of functionality AND it is significantly faster something like 2+ times faster, and it does not have any bugs in it.
On thought I had was that we could wire in the TRSP algorithm to the Shooting Star function signature, but give that we would like to rationalize all the function APIs potentially in 2.0 if we can ever get the time to do that release, I’m not sure what the value of having two function signatures, trsp and shooting star both using the same code.
Anton was the last developer the tried to work on it and he is gone. We would be happy to take patches if someone can figure out the Boost code.
Thanks,
-SteveOn 6/8/2012 7:15 PM, Sanak wrote:
Hi Steve,
I have not enough knowledge about Shooting Star algorithm and Boost
Graph Library,
but I think that the bug occurred in “core / src /
shooting_star_boost_wrapper.cpp” after 1.0.3 release(2008/09/04).
[History for core-src-shooting_star_boost_wrapper.cpp - pgRouting-pgrouting]
https://github.com/pgRouting/pgrouting/commits/master/core/src/shooting_star_boost_wrapper.cpp
And, old issue #190 may be related.
[#190 (First edge and last edge don’t respect the one way restriction) –
pgRouting]
ftp://ftp.remotesensing.org/pgrouting/forum/pgrouting.postlbs.org/ticket/190.html
Isn’t there any person who have enough knowledge about Shooting Star
argorithm and Boost Graph Library?
Regards,
2012/6/9 Steve Horn <steve@stevehorn.cc mailto:steve@stevehorn.cc>Was just wondering if anyone has had any time to address the bug in
the shortest_path_shooting_star algorithm where it ignores one way
street designations?–
Steve Horn
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org mailto:pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
–
Steve Horn
On Saturday, June 9, 2012, Stephen Woodbridge wrote:
Hi all,
In all likelihood, we will abandon the shooting star code unless someone want to try and figure out the implementation and try to fix the code. Currently the TRSP code does everything that shooting star does, so there is not loss of functionality AND it is significantly faster something like 2+ times faster, and it does not have any bugs in it.
Hi Steve,
I agree that TRSP is a good alternative, and the only issue now is that it’s not part of the latest release and documentation isn’t on the website. What I like on Shooting Star is, that it routes from road link to road link instead of point to point. But it’s right that it should be fixed first.
I’m happy to add some TRSP documentation/tutorial to the pgRouting website. But it would help me if you could post a rough draft version or point me to the right email threads. I will then review it and bring it into a nice format. I also have a bit limited spare time right now.
On thought I had was that we could wire in the TRSP algorithm to the Shooting Star function signature, but give that we would like to rationalize all the function APIs potentially in 2.0 if we can ever get the time to do that release, I’m not sure what the value of having two function signatures, trsp and shooting star both using the same code.
I’m not sure this is a good idea or not, but in fact all shortest path algorithms do more or less the same. So one function might be better, called “PGR_shortest_path” for example, and the library either is smart enough to choose the algorithms depending on the passed parameters (if each algorithm has different ones) or the first parameter could specify the algorithm.
It’s difficult to concentrate on a new release without sponsorship or funding, I think. But you can be sure, that in case there is a project opportunity that would allow to work on a new release this would be high priority for Georepublic.
Personally (as I’m mainly using Ubuntu) I would like to wait a bit until Debian/Ubuntu GIS will have PostGIS 2.0 packaged. I guess that PostGIS 2.x and PostreSQL 9.1 will soon become a standard and pgRouting 2.0 would be better a PostgreSQL extension and make use of PostGIS concave hull function to be able to drop CGAL dependency.
Daniel
Anton was the last developer the tried to work on it and he is gone. We would be happy to take patches if someone can figure out the Boost code.
Thanks,
-SteveOn 6/8/2012 7:15 PM, Sanak wrote:
Hi Steve,
I have not enough knowledge about Shooting Star algorithm and Boost
Graph Library,
but I think that the bug occurred in “core / src /
shooting_star_boost_wrapper.cpp” after 1.0.3 release(2008/09/04).
[History for core-src-shooting_star_boost_wrapper.cpp - pgRouting-pgrouting]
https://github.com/pgRouting/pgrouting/commits/master/core/src/shooting_star_boost_wrapper.cpp
And, old issue #190 may be related.
[#190 (First edge and last edge don’t respect the one way restriction) –
pgRouting]
ftp://ftp.remotesensing.org/pgrouting/forum/pgrouting.postlbs.org/ticket/190.html
Isn’t there any person who have enough knowledge about Shooting Star
argorithm and Boost Graph Library?
Regards,
2012/6/9 Steve Horn <steve@stevehorn.cc mailto:steve@stevehorn.cc>Was just wondering if anyone has had any time to address the bug in
the shortest_path_shooting_star algorithm where it ignores one way
street designations?–
Steve Horn
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org mailto:pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev–
Steve Horn
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