[pgrouting-dev] shortest_path_shooting_star

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,
-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


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,
-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


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