[pgrouting-users] Optimize routing - use new sew-devel-2_0 functions

Frederic_Bonifas · May 22, 2013, 9:25am

Hello,

I have begun using PgRouting 3 months ago for pedestrian routing. So I
don't use reverse_cost nor tun restrictions.

I have written my own wrapper in order to :
* set the start and end points as geographic points, the wrapper finds
the nearest edge, splits it in two parts and create a temporary vertex
(that will be used as start or stop vertex)
* compute the route with the "shortest_path" function
* output the route as a GeoJSON with additional information like the
total legnth of the route/

It works fine for what I want but it is slow, especially on big
graphs. I guess this is partially because of the use of the Dijkstra
algorithm. I would like to improve that.

With the recent developments around the sew-devel-2_0 branch, I would
like to use another routing algorithm. I am thinking of bidirectional
A*. To adapt my wrapper :
* would bidirectional A* be a good choice in my case ?
* is there a function in the sew-devel-2_0 branch to find the nearest
edge from a geographic point, split it in two parts and union this to
the graph for the routing ? I have looked here but I don't find this :
https://github.com/pgRouting/pgrouting/blob/sew-devel-2_0/src/common/sql/pgrouting_matching.sql
Otherwise, I will adapt my wrapper.
* is it good to output a GeoJSON in my wrapper as I do, or is there a
better way to go ?

Thanks a lot for your ideas

Best

--
Frédéric Bonifas
+33672652807 skype:fredericbonifas

Tao_Romera_Martinez · May 22, 2013, 9:33am

Hi Frederic,

I once developped something similar to what you're doing, but since the use is for pedestrian routes, do you really need to generate routes longer than 30 or 40 km? Within this range, our very modest server works out routes in 1 second or so.

I would be interested in knowing how to tackle your problem, though.

2013/05/22 18:25、Frédéric Bonifas <fredericbonifas@gmail.com> のメッセージ:

Hello,

I have begun using PgRouting 3 months ago for pedestrian routing. So I
don't use reverse_cost nor tun restrictions.

I have written my own wrapper in order to :
* set the start and end points as geographic points, the wrapper finds
the nearest edge, splits it in two parts and create a temporary vertex
(that will be used as start or stop vertex)
* compute the route with the "shortest_path" function
* output the route as a GeoJSON with additional information like the
total legnth of the route/

It works fine for what I want but it is slow, especially on big
graphs. I guess this is partially because of the use of the Dijkstra
algorithm. I would like to improve that.

With the recent developments around the sew-devel-2_0 branch, I would
like to use another routing algorithm. I am thinking of bidirectional
A*. To adapt my wrapper :
* would bidirectional A* be a good choice in my case ?
* is there a function in the sew-devel-2_0 branch to find the nearest
edge from a geographic point, split it in two parts and union this to
the graph for the routing ? I have looked here but I don't find this :
https://github.com/pgRouting/pgrouting/blob/sew-devel-2_0/src/common/sql/pgrouting_matching.sql
Otherwise, I will adapt my wrapper.
* is it good to output a GeoJSON in my wrapper as I do, or is there a
better way to go ?

Thanks a lot for your ideas

Best

--
Frédéric Bonifas
+33672652807 skype:fredericbonifas
_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

Frederic_Bonifas · May 22, 2013, 9:42am

I agree the the routes will be relatively short for pedestrian routing, but :
* if I understand correctly how Dijkstra works, the routing time will
mostly depend on the size of the graph, as the whole graph will be
visited before giving the shortest_route.
* the fastest it is, the more I like it
* I show to the user different possible routes (4) so the routing time
is multiplied by this factor.

2013/5/22 Tao Romera Martinez <taoromera@gmail.com>:

Hi Frederic,

I once developped something similar to what you're doing, but since the use is for pedestrian routes, do you really need to generate routes longer than 30 or 40 km? Within this range, our very modest server works out routes in 1 second or so.

I would be interested in knowing how to tackle your problem, though.

2013/05/22 18:25、Frédéric Bonifas <fredericbonifas@gmail.com> のメッセージ:

Hello,

I have begun using PgRouting 3 months ago for pedestrian routing. So I
don't use reverse_cost nor tun restrictions.

I have written my own wrapper in order to :
* set the start and end points as geographic points, the wrapper finds
the nearest edge, splits it in two parts and create a temporary vertex
(that will be used as start or stop vertex)
* compute the route with the "shortest_path" function
* output the route as a GeoJSON with additional information like the
total legnth of the route/

It works fine for what I want but it is slow, especially on big
graphs. I guess this is partially because of the use of the Dijkstra
algorithm. I would like to improve that.

With the recent developments around the sew-devel-2_0 branch, I would
like to use another routing algorithm. I am thinking of bidirectional
A*. To adapt my wrapper :
* would bidirectional A* be a good choice in my case ?
* is there a function in the sew-devel-2_0 branch to find the nearest
edge from a geographic point, split it in two parts and union this to
the graph for the routing ? I have looked here but I don't find this :
https://github.com/pgRouting/pgrouting/blob/sew-devel-2_0/src/common/sql/pgrouting_matching.sql
Otherwise, I will adapt my wrapper.
* is it good to output a GeoJSON in my wrapper as I do, or is there a
better way to go ?

Thanks a lot for your ideas

Best

--
Frédéric Bonifas
+33672652807 skype:fredericbonifas
_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Frédéric Bonifas
+33672652807 skype:fredericbonifas

dkastl · May 22, 2013, 10:27am

On Wed, May 22, 2013 at 6:42 PM, Frédéric Bonifas <fredericbonifas@gmail.com

wrote:

I agree the the routes will be relatively short for pedestrian routing,
but :
* if I understand correctly how Dijkstra works, the routing time will
mostly depend on the size of the graph, as the whole graph will be
visited before giving the shortest_route.
* the fastest it is, the more I like it
* I show to the user different possible routes (4) so the routing time
is multiplied by this factor.

Hi Frederic,

The algorithm doesn't make such big difference as you might expect.
What matters is the size of the network that you load for a routing
request, which depends on the length of the route and the road density.
For example a 40km route through Tokyo will load a huge amount of data, but
some sparse area in Canada 40km would not be an issue.

For your pedestrian routing, did you make sure that you don't load the
whole network table for every request?
The easiest way to limit the data you select is using a BBOX.

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

Frederic_Bonifas · May 22, 2013, 10:45am

Thank you for this, I don't use a bounding box for now.
According to this doc [1], the wrappers implementing a bbox
restrictions will be dropped. Is there a new built-in way to implement
bbox restriction in the sew-devel-2_0 branch or do I have to write
this in my wrapper ?

Best

1: https://docs.google.com/spreadsheet/ccc?key=0AiIg1pkkh_MRdGQzOEhyaXlndkN3eHdGNkpyQ0pMZFE#gid=0

2013/5/22 Daniel Kastl <daniel@georepublic.de>:

On Wed, May 22, 2013 at 6:42 PM, Frédéric Bonifas
<fredericbonifas@gmail.com> wrote:

I agree the the routes will be relatively short for pedestrian routing,
but :
* if I understand correctly how Dijkstra works, the routing time will
mostly depend on the size of the graph, as the whole graph will be
visited before giving the shortest_route.
* the fastest it is, the more I like it
* I show to the user different possible routes (4) so the routing time
is multiplied by this factor.

Hi Frederic,

The algorithm doesn't make such big difference as you might expect.
What matters is the size of the network that you load for a routing request,
which depends on the length of the route and the road density.
For example a 40km route through Tokyo will load a huge amount of data, but
some sparse area in Canada 40km would not be an issue.

For your pedestrian routing, did you make sure that you don't load the whole
network table for every request?
The easiest way to limit the data you select is using a BBOX.

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Frédéric Bonifas
+33672652807 skype:fredericbonifas

Tao_Romera_Martinez · May 22, 2013, 10:49am

Frederic,

The time to generate a route is mostly spent in retrieving the ways
from the DB and passing them to the C function that performs the
Dikstra, as Stephen once pointed out in a private mail to me. With a
small graph, 80% of the time consumed by shortest_path goes to
retrieving the ways.
If you really need to improve the efficiency of 1 search in your
service, you could consider modifying the C code to reuse the ways
retrieved from the DB and generate a new route with different
parameters.

Tao

2013/5/22 Daniel Kastl <daniel@georepublic.de>:

On Wed, May 22, 2013 at 6:42 PM, Frédéric Bonifas
<fredericbonifas@gmail.com> wrote:

I agree the the routes will be relatively short for pedestrian routing,
but :
* if I understand correctly how Dijkstra works, the routing time will
mostly depend on the size of the graph, as the whole graph will be
visited before giving the shortest_route.
* the fastest it is, the more I like it
* I show to the user different possible routes (4) so the routing time
is multiplied by this factor.

Hi Frederic,

The algorithm doesn't make such big difference as you might expect.
What matters is the size of the network that you load for a routing request,
which depends on the length of the route and the road density.
For example a 40km route through Tokyo will load a huge amount of data, but
some sparse area in Canada 40km would not be an issue.

For your pedestrian routing, did you make sure that you don't load the whole
network table for every request?
The easiest way to limit the data you select is using a BBOX.

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Tao Romera Martínez

---------------------------------------------------------
Tel: 080-6805-0945
Address: Koganei-shi, Tokyo, Japan

Look for me on Facebook and LinkedIn
---------------------------------------------------------

Tao_Romera_Martinez · May 22, 2013, 10:55am

Oh, then use a bounding box. It will improve the speed of the query a lot.
Something like this:

SELECT * FROM shortest_path('
                SELECT gid as id,
                         source::integer,
                         target::integer,
                         length::double precision as cost
                        FROM japan WHERE japan.geom_way &&
ST_MakeEnvelope(139.675, 35.729, 139.705, 35.762);',
                5700, 6733, false, false);

Don't forget to create an index in the geom column:

CREATE INDEX my_idx ON japan USING GIST(geom);

Tao

2013/5/22 Tao Romera Martinez <taoromera@gmail.com>:

Frederic,

The time to generate a route is mostly spent in retrieving the ways
from the DB and passing them to the C function that performs the
Dikstra, as Stephen once pointed out in a private mail to me. With a
small graph, 80% of the time consumed by shortest_path goes to
retrieving the ways.
If you really need to improve the efficiency of 1 search in your
service, you could consider modifying the C code to reuse the ways
retrieved from the DB and generate a new route with different
parameters.

Tao

2013/5/22 Daniel Kastl <daniel@georepublic.de>:

On Wed, May 22, 2013 at 6:42 PM, Frédéric Bonifas
<fredericbonifas@gmail.com> wrote:

I agree the the routes will be relatively short for pedestrian routing,
but :
* if I understand correctly how Dijkstra works, the routing time will
mostly depend on the size of the graph, as the whole graph will be
visited before giving the shortest_route.
* the fastest it is, the more I like it
* I show to the user different possible routes (4) so the routing time
is multiplied by this factor.

Hi Frederic,

The algorithm doesn't make such big difference as you might expect.
What matters is the size of the network that you load for a routing request,
which depends on the length of the route and the road density.
For example a 40km route through Tokyo will load a huge amount of data, but
some sparse area in Canada 40km would not be an issue.

For your pedestrian routing, did you make sure that you don't load the whole
network table for every request?
The easiest way to limit the data you select is using a BBOX.

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Tao Romera Martínez

---------------------------------------------------------
Tel: 080-6805-0945
Address: Koganei-shi, Tokyo, Japan

Look for me on Facebook and LinkedIn
---------------------------------------------------------

--
Tao Romera Martínez

---------------------------------------------------------
Tel: 080-6805-0945
Address: Koganei-shi, Tokyo, Japan

Look for me on Facebook and LinkedIn
---------------------------------------------------------

Stephen_Woodbridge1 · May 22, 2013, 3:25pm

Basically the wrappers all did variations of the following pattern:

1. take the XY of the start and end point of the route
2. find the nearest edge or vertex to those points
3. compute a BBOX like the following
    japan.geom_way && ST_EXPAND(
       ST_SetSRID(
         ST_MakeLine(
              ST_MakePoint(start_x, start_y),
              ST_MakePoint(end_x, end_y)
         ),
         4326), -- set the SRID
       0.05) -- expand by this in SRID
4. run one of the shortest path queries.

Regarding which query to run:

Regardless of restrictions, the pgr_trsp() is a good function to use, because you and pass it and edge and a percent along the edge for bot the start and end points.

Then try algorithms in this order if performance is you goal:

pgr_bdastar - currently has a bug that we hope to fix before release
pgr_astar
pgr_bddijkstra - currently has bug
pgr_dijkstra

Hope this helps,
-Steve

On 5/22/2013 6:55 AM, Tao Romera Martinez wrote:

Oh, then use a bounding box. It will improve the speed of the query a lot.
Something like this:

SELECT * FROM shortest_path('
                 SELECT gid as id,
                          source::integer,
                          target::integer,
                          length::double precision as cost
                         FROM japan WHERE japan.geom_way &&
ST_MakeEnvelope(139.675, 35.729, 139.705, 35.762);',
                 5700, 6733, false, false);

Don't forget to create an index in the geom column:

CREATE INDEX my_idx ON japan USING GIST(geom);

Tao

2013/5/22 Tao Romera Martinez <taoromera@gmail.com>:

Frederic,

The time to generate a route is mostly spent in retrieving the ways
from the DB and passing them to the C function that performs the
Dikstra, as Stephen once pointed out in a private mail to me. With a
small graph, 80% of the time consumed by shortest_path goes to
retrieving the ways.
If you really need to improve the efficiency of 1 search in your
service, you could consider modifying the C code to reuse the ways
retrieved from the DB and generate a new route with different
parameters.

Tao

2013/5/22 Daniel Kastl <daniel@georepublic.de>:

On Wed, May 22, 2013 at 6:42 PM, Frédéric Bonifas
<fredericbonifas@gmail.com> wrote:

I agree the the routes will be relatively short for pedestrian routing,
but :
* if I understand correctly how Dijkstra works, the routing time will
mostly depend on the size of the graph, as the whole graph will be
visited before giving the shortest_route.
* the fastest it is, the more I like it
* I show to the user different possible routes (4) so the routing time
is multiplied by this factor.

Hi Frederic,

The algorithm doesn't make such big difference as you might expect.
What matters is the size of the network that you load for a routing request,
which depends on the length of the route and the road density.
For example a 40km route through Tokyo will load a huge amount of data, but
some sparse area in Canada 40km would not be an issue.

For your pedestrian routing, did you make sure that you don't load the whole
network table for every request?
The easiest way to limit the data you select is using a BBOX.

  Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Tao Romera Martínez

---------------------------------------------------------
Tel: 080-6805-0945
Address: Koganei-shi, Tokyo, Japan

Look for me on Facebook and LinkedIn
---------------------------------------------------------

Frederic_Bonifas · May 23, 2013, 12:52pm

Thank you very much for all your answers. Using a bounding-box does
indeed improve the performances.
I will stick to Dijkstra for now.

Best

Frédéric

2013/5/22 Stephen Woodbridge <woodbri@swoodbridge.com>:

Basically the wrappers all did variations of the following pattern:

1. take the XY of the start and end point of the route
2. find the nearest edge or vertex to those points
3. compute a BBOX like the following
   japan.geom_way && ST_EXPAND(
      ST_SetSRID(
        ST_MakeLine(
             ST_MakePoint(start_x, start_y),
             ST_MakePoint(end_x, end_y)
        ),
        4326), -- set the SRID
      0.05) -- expand by this in SRID
4. run one of the shortest path queries.

Regarding which query to run:

Regardless of restrictions, the pgr_trsp() is a good function to use,
because you and pass it and edge and a percent along the edge for bot the
start and end points.

Then try algorithms in this order if performance is you goal:

pgr_bdastar - currently has a bug that we hope to fix before release
pgr_astar
pgr_bddijkstra - currently has bug
pgr_dijkstra

Hope this helps,
  -Steve

On 5/22/2013 6:55 AM, Tao Romera Martinez wrote:

Oh, then use a bounding box. It will improve the speed of the query a lot.
Something like this:

SELECT * FROM shortest_path('
                 SELECT gid as id,
                          source::integer,
                          target::integer,
                          length::double precision as cost
                         FROM japan WHERE japan.geom_way &&
ST_MakeEnvelope(139.675, 35.729, 139.705, 35.762);',
                 5700, 6733, false, false);

Don't forget to create an index in the geom column:

CREATE INDEX my_idx ON japan USING GIST(geom);

Tao

2013/5/22 Tao Romera Martinez <taoromera@gmail.com>:

Frederic,

The time to generate a route is mostly spent in retrieving the ways
from the DB and passing them to the C function that performs the
Dikstra, as Stephen once pointed out in a private mail to me. With a
small graph, 80% of the time consumed by shortest_path goes to
retrieving the ways.
If you really need to improve the efficiency of 1 search in your
service, you could consider modifying the C code to reuse the ways
retrieved from the DB and generate a new route with different
parameters.

Tao

2013/5/22 Daniel Kastl <daniel@georepublic.de>:

On Wed, May 22, 2013 at 6:42 PM, Frédéric Bonifas
<fredericbonifas@gmail.com> wrote:

I agree the the routes will be relatively short for pedestrian routing,
but :
* if I understand correctly how Dijkstra works, the routing time will
mostly depend on the size of the graph, as the whole graph will be
visited before giving the shortest_route.
* the fastest it is, the more I like it
* I show to the user different possible routes (4) so the routing time
is multiplied by this factor.

Hi Frederic,

The algorithm doesn't make such big difference as you might expect.
What matters is the size of the network that you load for a routing
request,
which depends on the length of the route and the road density.
For example a 40km route through Tokyo will load a huge amount of data,
but
some sparse area in Canada 40km would not be an issue.

For your pedestrian routing, did you make sure that you don't load the
whole
network table for every request?
The easiest way to limit the data you select is using a BBOX.

  Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Tao Romera Martínez

---------------------------------------------------------
Tel: 080-6805-0945
Address: Koganei-shi, Tokyo, Japan

Look for me on Facebook and LinkedIn
---------------------------------------------------------

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Frédéric Bonifas
+33672652807 skype:fredericbonifas

Dave_Potts · May 25, 2013, 9:11am

Hi list

I want a play from the new version of the tsp code.

I have tried building it on Ubuntu 3.2.0-43-generic #68-Ubuntu SMP with postgres 9.1.9 using the syntax

cmake DebugFull .

I got the following errors[See Below]

Q. What should the build envronment be pgroute 2.0??

I have already upgraded my version of cmake 2.8.11

regards

Dave.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

src/pgroute/pgr2.0/pgrouting-sew-devel-2_0 failed with output:

fatal: Not a git repository (or any parent up to mount parent )

Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

Call Stack (most recent call first):
CMakeLists.txt:68 (GIT_WC_INFO)

CMake Warning at cmake/FindGit.cmake:144 (message):
   No remote origin set for git repository:
   /home/dp42/src/pgroute/pgr2.0/pgrouting-sew-devel-2_0
Call Stack (most recent call first):
   CMakeLists.txt:68 (GIT_WC_INFO)

-- POSTGRESQL_EXECUTABLE is /usr/lib/postgresql/9.1/bin/postgres
-- POSTGRESQL_PG_CONFIG is /usr/bin/pg_config
-- POSTGRESQL_INCLUDE_DIR: /usr/include/postgresql/9.1/server
-- POSTGRESQL_LIBRARIES: /usr/lib
-- Boost version: 1.48.0
Boost headers were found here: /usr/include
-- POSTGRESQL_VERSION_STRING is PostgreSQL 9.1.9
-- POSTGRESQL_VERSION is 9.1.9
-- Install directory for libraries is set to /usr/lib/postgresql/9.1/lib
-- Install directory for SQL files is set to /usr/share/postgresql/9.1/extension
-- LIBS_TO_INSTALL=
-- Configuring incomplete, errors occurred!

dkastl · May 25, 2013, 10:41am

On Sat, May 25, 2013 at 6:11 PM, Dave Potts <dave.potts@pinan.co.uk> wrote:

Hi list

I want a play from the new version of the tsp code.

I have tried building it on Ubuntu 3.2.0-43-generic #68-Ubuntu SMP with
postgres 9.1.9 using the syntax

cmake DebugFull .

I got the following errors[See Below]

Q. What should the build envronment be pgroute 2.0??

Hi Dave,

There seems to be a problem with the use of the Git module of CMake.
The check for Git is not something that must be included, but it's
convenient, because it allows to place the version information for example
in the documentation or some time into a function to retreive the pgRouting
version.

I have tested, that it works when you build from a Git repository with Git
installed.
And I think I have tested the case when Git is not installed and it's not a
Git repository.
In your case, do you build from a cloned repository?

I have already upgraded my version of cmake 2.8.11

The required version is checked and it will give an error when your version
is not new enough.

These are a few commands I'm using to build on Ubuntu:
https://gist.github.com/dkastl/5617030

Daniel

regards

Dave.

------------------------------**------------------------------**
------------------------------**------------------------------**
------------------------------**----------------------

src/pgroute/pgr2.0/pgrouting-**sew-devel-2_0 failed with output:

  fatal: Not a git repository (or any parent up to mount parent )

  Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_**FILESYSTEM not
set).

Call Stack (most recent call first):
  CMakeLists.txt:68 (GIT_WC_INFO)

CMake Warning at cmake/FindGit.cmake:144 (message):
  No remote origin set for git repository:
  /home/dp42/src/pgroute/pgr2.0/**pgrouting-sew-devel-2_0
Call Stack (most recent call first):
  CMakeLists.txt:68 (GIT_WC_INFO)

-- POSTGRESQL_EXECUTABLE is /usr/lib/postgresql/9.1/bin/**postgres
-- POSTGRESQL_PG_CONFIG is /usr/bin/pg_config
-- POSTGRESQL_INCLUDE_DIR: /usr/include/postgresql/9.1/**server
-- POSTGRESQL_LIBRARIES: /usr/lib
-- Boost version: 1.48.0
Boost headers were found here: /usr/include
-- POSTGRESQL_VERSION_STRING is PostgreSQL 9.1.9
-- POSTGRESQL_VERSION is 9.1.9
-- Install directory for libraries is set to /usr/lib/postgresql/9.1/lib
-- Install directory for SQL files is set to /usr/share/postgresql/9.1/**
extension
-- LIBS_TO_INSTALL=
-- Configuring incomplete, errors occurred!

______________________________**_________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.**org <Pgrouting-users@lists.osgeo.org>
http://lists.osgeo.org/**mailman/listinfo/pgrouting-**users<http://lists.osgeo.org/mailman/listinfo/pgrouting-users>

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

Dave_Potts · May 25, 2013, 12:53pm

Hi DAniel, WIll check out these tools, which version off Ubuntu are you on? I did’nt clone a copy, I just got it out as a zip file. Dave.

···

On 25/05/13 11:41, Daniel Kastl wrote:

On Sat, May 25, 2013 at 6:11 PM, Dave Potts <dave.potts@pinan.co.uk> wrote:

Hi list

I want a play from the new version of the tsp code.

I have tried building it on Ubuntu 3.2.0-43-generic #68-Ubuntu SMP with postgres 9.1.9 using the syntax

cmake DebugFull .

I got the following errors[See Below]

Q. What should the build envronment be pgroute 2.0??

Hi Dave,

There seems to be a problem with the use of the Git module of CMake.
The check for Git is not something that must be included, but it’s convenient, because it allows to place the version information for example in the documentation or some time into a function to retreive the pgRouting version.

I have tested, that it works when you build from a Git repository with Git installed.
And I think I have tested the case when Git is not installed and it’s not a Git repository.
In your case, do you build from a cloned repository?

I have already upgraded my version of cmake 2.8.11

The required version is checked and it will give an error when your version is not new enough.

These are a few commands I’m using to build on Ubuntu:
https://gist.github.com/dkastl/5617030

Daniel

regards

Dave.

src/pgroute/pgr2.0/pgrouting-sew-devel-2_0 failed with output:

fatal: Not a git repository (or any parent up to mount parent )

Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).

Call Stack (most recent call first):
CMakeLists.txt:68 (GIT_WC_INFO)

CMake Warning at cmake/FindGit.cmake:144 (message):
No remote origin set for git repository:
/home/dp42/src/pgroute/pgr2.0/pgrouting-sew-devel-2_0
Call Stack (most recent call first):
CMakeLists.txt:68 (GIT_WC_INFO)

– POSTGRESQL_EXECUTABLE is /usr/lib/postgresql/9.1/bin/postgres
– POSTGRESQL_PG_CONFIG is /usr/bin/pg_config
– POSTGRESQL_INCLUDE_DIR: /usr/include/postgresql/9.1/server
– POSTGRESQL_LIBRARIES: /usr/lib
– Boost version: 1.48.0
Boost headers were found here: /usr/include
– POSTGRESQL_VERSION_STRING is PostgreSQL 9.1.9
– POSTGRESQL_VERSION is 9.1.9
– Install directory for libraries is set to /usr/lib/postgresql/9.1/lib
– Install directory for SQL files is set to /usr/share/postgresql/9.1/extension
– LIBS_TO_INSTALL=
– Configuring incomplete, errors occurred!

Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

–
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de
_______________________________________________
Pgrouting-users mailing list
[Pgrouting-users@lists.osgeo.org](mailto:Pgrouting-users@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/pgrouting-users](http://lists.osgeo.org/mailman/listinfo/pgrouting-users)

Stephen_Woodbridge1 · May 25, 2013, 1:21pm

Hi Dave,

We don't test in the tarball environment. May be you can figure out the cmake stuff there. What is supposed to happen,

check if git exists or not (non fatal)
if git exists then
   if git repository get git hash
   else report non fatal message
else
   report non-fatal message

This is all done in this block:

# Find Git to collect version information
find_package(Git QUIET)
if(GIT_FOUND)
   message(STATUS "Found Git: ${GIT_EXECUTABLE}")
   GIT_WC_INFO(${PGROUTING_SOURCE_DIR} PGROUTING)
   set(PGROUTING_VERSION_REVISION_NAME "${PGROUTING_WC_REVISION_NAME}")
   set(PGROUTING_VERSION_REVISION_HASH "${PGROUTING_WC_REVISION_HASH}")
else()
   message(STATUS "Could NOT find GIT (optional)")
   set(PGROUTING_VERSION_REVISION_NAME "")
   set(PGROUTING_VERSION_REVISION_HASH "")
endif()

my guess is you have git and GIT_WC_INFO is fatal for not a repository.
The quick fix so you can continue is to replace the block above with

set(PGROUTING_VERSION_REVISION_NAME "")
set(PGROUTING_VERSION_REVISION_HASH "")

-Steve

On 5/25/2013 8:53 AM, Dave Potts wrote:

On 25/05/13 11:41, Daniel Kastl wrote:

On Sat, May 25, 2013 at 6:11 PM, Dave Potts <dave.potts@pinan.co.uk
<mailto:dave.potts@pinan.co.uk>> wrote:

    Hi list

    I want a play from the new version of the tsp code.

    I have tried building it on Ubuntu 3.2.0-43-generic #68-Ubuntu
    SMP with postgres 9.1.9 using the syntax

    cmake DebugFull .

    I got the following errors[See Below]

    Q. What should the build envronment be pgroute 2.0??

Hi Dave,

There seems to be a problem with the use of the Git module of CMake.
The check for Git is not something that must be included, but it's
convenient, because it allows to place the version information for
example in the documentation or some time into a function to retreive
the pgRouting version.

I have tested, that it works when you build from a Git repository with
Git installed.
And I think I have tested the case when Git is not installed and it's
not a Git repository.
In your case, do you build from a cloned repository?

    I have already upgraded my version of cmake 2.8.11

The required version is checked and it will give an error when your
version is not new enough.

These are a few commands I'm using to build on Ubuntu:
https://gist.github.com/dkastl/5617030

Hi DAniel,

WIll check out these tools, which version off Ubuntu are you on?

I did'nt clone a copy, I just got it out as a zip file.

Dave.

Daniel

    regards

    Dave.

    ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    src/pgroute/pgr2.0/pgrouting-sew-devel-2_0 failed with output:

      fatal: Not a git repository (or any parent up to mount parent )

      Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM
    not set).

    Call Stack (most recent call first):
      CMakeLists.txt:68 (GIT_WC_INFO)

    CMake Warning at cmake/FindGit.cmake:144 (message):
      No remote origin set for git repository:
      /home/dp42/src/pgroute/pgr2.0/pgrouting-sew-devel-2_0
    Call Stack (most recent call first):
      CMakeLists.txt:68 (GIT_WC_INFO)

    -- POSTGRESQL_EXECUTABLE is /usr/lib/postgresql/9.1/bin/postgres
    -- POSTGRESQL_PG_CONFIG is /usr/bin/pg_config
    -- POSTGRESQL_INCLUDE_DIR: /usr/include/postgresql/9.1/server
    -- POSTGRESQL_LIBRARIES: /usr/lib
    -- Boost version: 1.48.0
    Boost headers were found here: /usr/include
    -- POSTGRESQL_VERSION_STRING is PostgreSQL 9.1.9
    -- POSTGRESQL_VERSION is 9.1.9
    -- Install directory for libraries is set to
    /usr/lib/postgresql/9.1/lib
    -- Install directory for SQL files is set to
    /usr/share/postgresql/9.1/extension
    -- LIBS_TO_INSTALL=
    -- Configuring incomplete, errors occurred!

    _______________________________________________
    Pgrouting-users mailing list
    Pgrouting-users@lists.osgeo.org
    <mailto:Pgrouting-users@lists.osgeo.org>
    http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

Dave_Potts · May 25, 2013, 5:01pm

On 25/05/13 14:21, Stephen Woodbridge wrote:
hi

I tried Daniel suggestion ie
git clone git@github.com:pgRouting/pgrouting.git

and got
Cloning into 'pgrouting'...
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

not the error I was expecting

D.

Hi Dave,

We don't test in the tarball environment. May be you can figure out the cmake stuff there. What is supposed to happen,

check if git exists or not (non fatal)
if git exists then
  if git repository get git hash
  else report non fatal message
else
  report non-fatal message

This is all done in this block:

# Find Git to collect version information
find_package(Git QUIET)
if(GIT_FOUND)
  message(STATUS "Found Git: ${GIT_EXECUTABLE}")
  GIT_WC_INFO(${PGROUTING_SOURCE_DIR} PGROUTING)
  set(PGROUTING_VERSION_REVISION_NAME "${PGROUTING_WC_REVISION_NAME}")
  set(PGROUTING_VERSION_REVISION_HASH "${PGROUTING_WC_REVISION_HASH}")
else()
  message(STATUS "Could NOT find GIT (optional)")
  set(PGROUTING_VERSION_REVISION_NAME "")
  set(PGROUTING_VERSION_REVISION_HASH "")
endif()

my guess is you have git and GIT_WC_INFO is fatal for not a repository.
The quick fix so you can continue is to replace the block above with

  set(PGROUTING_VERSION_REVISION_NAME "")
  set(PGROUTING_VERSION_REVISION_HASH "")

-Steve

On 5/25/2013 8:53 AM, Dave Potts wrote:

On 25/05/13 11:41, Daniel Kastl wrote:

On Sat, May 25, 2013 at 6:11 PM, Dave Potts <dave.potts@pinan.co.uk
<mailto:dave.potts@pinan.co.uk>> wrote:

    Hi list

    I want a play from the new version of the tsp code.

    I have tried building it on Ubuntu 3.2.0-43-generic #68-Ubuntu
    SMP with postgres 9.1.9 using the syntax

    cmake DebugFull .

    I got the following errors[See Below]

    Q. What should the build envronment be pgroute 2.0??

Hi Dave,

There seems to be a problem with the use of the Git module of CMake.
The check for Git is not something that must be included, but it's
convenient, because it allows to place the version information for
example in the documentation or some time into a function to retreive
the pgRouting version.

I have tested, that it works when you build from a Git repository with
Git installed.
And I think I have tested the case when Git is not installed and it's
not a Git repository.
In your case, do you build from a cloned repository?

    I have already upgraded my version of cmake 2.8.11

The required version is checked and it will give an error when your
version is not new enough.

These are a few commands I'm using to build on Ubuntu:
https://gist.github.com/dkastl/5617030

Hi DAniel,

WIll check out these tools, which version off Ubuntu are you on?

I did'nt clone a copy, I just got it out as a zip file.

Dave.

Daniel

    regards

    Dave.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    src/pgroute/pgr2.0/pgrouting-sew-devel-2_0 failed with output:

      fatal: Not a git repository (or any parent up to mount parent )

      Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM
    not set).

    Call Stack (most recent call first):
      CMakeLists.txt:68 (GIT_WC_INFO)

    CMake Warning at cmake/FindGit.cmake:144 (message):
      No remote origin set for git repository:
      /home/dp42/src/pgroute/pgr2.0/pgrouting-sew-devel-2_0
    Call Stack (most recent call first):
      CMakeLists.txt:68 (GIT_WC_INFO)

    -- POSTGRESQL_EXECUTABLE is /usr/lib/postgresql/9.1/bin/postgres
    -- POSTGRESQL_PG_CONFIG is /usr/bin/pg_config
    -- POSTGRESQL_INCLUDE_DIR: /usr/include/postgresql/9.1/server
    -- POSTGRESQL_LIBRARIES: /usr/lib
    -- Boost version: 1.48.0
    Boost headers were found here: /usr/include
    -- POSTGRESQL_VERSION_STRING is PostgreSQL 9.1.9
    -- POSTGRESQL_VERSION is 9.1.9
    -- Install directory for libraries is set to
    /usr/lib/postgresql/9.1/lib
    -- Install directory for SQL files is set to
    /usr/share/postgresql/9.1/extension
    -- LIBS_TO_INSTALL=
    -- Configuring incomplete, errors occurred!

    _______________________________________________
    Pgrouting-users mailing list
    Pgrouting-users@lists.osgeo.org
    <mailto:Pgrouting-users@lists.osgeo.org>
    http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

Stephen_Woodbridge1 · May 25, 2013, 5:33pm

Sorry, Daniel posted the URL for those that have write privledges to the the repository. You can use the public one

git://github.com/pgRouting/pgrouting.git

or you can fork the repository if you have your won github account and make changes there and generate pull requests for us to pull your changes into the master respository.

https://github.com/pgRouting/pgrouting/tree/sew-devel-2_0

Notice the HTTP, SSH, Git Reead-Only buttons, by clicking on them you can see the different URLS that can be used.

git clone git://github.com/pgRouting/pgrouting.git
git checkout sew-devel-2_0
tools/doit
(cd build; sudo make install)
tools/test-runner.pl

is the standard way I build and test on Linux.

-Steve

On 5/25/2013 1:01 PM, Dave Potts wrote:

On 25/05/13 14:21, Stephen Woodbridge wrote:
hi

I tried Daniel suggestion ie
git clone git@github.com:pgRouting/pgrouting.git

and got
Cloning into 'pgrouting'...
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

not the error I was expecting

D.

Hi Dave,

We don't test in the tarball environment. May be you can figure out
the cmake stuff there. What is supposed to happen,

check if git exists or not (non fatal)
if git exists then
  if git repository get git hash
  else report non fatal message
else
  report non-fatal message

This is all done in this block:

# Find Git to collect version information
find_package(Git QUIET)
if(GIT_FOUND)
  message(STATUS "Found Git: ${GIT_EXECUTABLE}")
  GIT_WC_INFO(${PGROUTING_SOURCE_DIR} PGROUTING)
  set(PGROUTING_VERSION_REVISION_NAME "${PGROUTING_WC_REVISION_NAME}")
  set(PGROUTING_VERSION_REVISION_HASH "${PGROUTING_WC_REVISION_HASH}")
else()
  message(STATUS "Could NOT find GIT (optional)")
  set(PGROUTING_VERSION_REVISION_NAME "")
  set(PGROUTING_VERSION_REVISION_HASH "")
endif()

my guess is you have git and GIT_WC_INFO is fatal for not a repository.
The quick fix so you can continue is to replace the block above with

  set(PGROUTING_VERSION_REVISION_NAME "")
  set(PGROUTING_VERSION_REVISION_HASH "")

-Steve

On 5/25/2013 8:53 AM, Dave Potts wrote:

On 25/05/13 11:41, Daniel Kastl wrote:

On Sat, May 25, 2013 at 6:11 PM, Dave Potts <dave.potts@pinan.co.uk
<mailto:dave.potts@pinan.co.uk>> wrote:

    Hi list

    I want a play from the new version of the tsp code.

    I have tried building it on Ubuntu 3.2.0-43-generic #68-Ubuntu
    SMP with postgres 9.1.9 using the syntax

    cmake DebugFull .

    I got the following errors[See Below]

    Q. What should the build envronment be pgroute 2.0??

Hi Dave,

There seems to be a problem with the use of the Git module of CMake.
The check for Git is not something that must be included, but it's
convenient, because it allows to place the version information for
example in the documentation or some time into a function to retreive
the pgRouting version.

I have tested, that it works when you build from a Git repository with
Git installed.
And I think I have tested the case when Git is not installed and it's
not a Git repository.
In your case, do you build from a cloned repository?

    I have already upgraded my version of cmake 2.8.11

The required version is checked and it will give an error when your
version is not new enough.

These are a few commands I'm using to build on Ubuntu:
https://gist.github.com/dkastl/5617030

Hi DAniel,

WIll check out these tools, which version off Ubuntu are you on?

I did'nt clone a copy, I just got it out as a zip file.

Dave.

Daniel

    regards

    Dave.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    src/pgroute/pgr2.0/pgrouting-sew-devel-2_0 failed with output:

      fatal: Not a git repository (or any parent up to mount parent )

      Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM
    not set).

    Call Stack (most recent call first):
      CMakeLists.txt:68 (GIT_WC_INFO)

    CMake Warning at cmake/FindGit.cmake:144 (message):
      No remote origin set for git repository:
      /home/dp42/src/pgroute/pgr2.0/pgrouting-sew-devel-2_0
    Call Stack (most recent call first):
      CMakeLists.txt:68 (GIT_WC_INFO)

    -- POSTGRESQL_EXECUTABLE is /usr/lib/postgresql/9.1/bin/postgres
    -- POSTGRESQL_PG_CONFIG is /usr/bin/pg_config
    -- POSTGRESQL_INCLUDE_DIR: /usr/include/postgresql/9.1/server
    -- POSTGRESQL_LIBRARIES: /usr/lib
    -- Boost version: 1.48.0
    Boost headers were found here: /usr/include
    -- POSTGRESQL_VERSION_STRING is PostgreSQL 9.1.9
    -- POSTGRESQL_VERSION is 9.1.9
    -- Install directory for libraries is set to
    /usr/lib/postgresql/9.1/lib
    -- Install directory for SQL files is set to
    /usr/share/postgresql/9.1/extension
    -- LIBS_TO_INSTALL=
    -- Configuring incomplete, errors occurred!

    _______________________________________________
    Pgrouting-users mailing list
    Pgrouting-users@lists.osgeo.org
    <mailto:Pgrouting-users@lists.osgeo.org>
    http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

dkastl · May 25, 2013, 5:43pm

On Sun, May 26, 2013 at 2:33 AM, Stephen Woodbridge <woodbri@swoodbridge.com

wrote:

Sorry, Daniel posted the URL for those that have write privledges to the
the repository. You can use the public one

git://github.com/pgRouting/**pgrouting.git<http://github.com/pgRouting/pgrouting.git>

or you can fork the repository if you have your won github account and
make changes there and generate pull requests for us to pull your changes
into the master respository.

Oh, Steve is right.
This is because Git has different connection strings depending if you have
write access or not.
The link I posted in the GIST was just my personal list of commands as I'm
sometimes switching PC's

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

Dave_Potts · May 25, 2013, 5:48pm

On 25/05/13 18:33, Stephen Woodbridge wrote:
Hi Steve,

Thanks for the prompt help, in the end I hacked the makefile and did a normal make and compile a version.

I did try your build instructions
ie tools/doit and got an error about (missing: SPHINX_EXECUTABLE)

I am using cmake version 2.8.11

Dave.

----------------------------------------------------------------------------------
tools/doit
-- UNIX=1
-- WIN32=
-- POSTGRESQL_EXECUTABLE is /usr/lib/postgresql/9.1/bin/postgres
-- POSTGRESQL_PG_CONFIG is /usr/bin/pg_config
-- POSTGRESQL_INCLUDE_DIR: /usr/include/postgresql/9.1/server
-- POSTGRESQL_LIBRARIES: /usr/lib
-- Boost version: 1.48.0
Boost headers were found here: /usr/include
-- POSTGRESQL_VERSION_STRING is PostgreSQL 9.1.9
-- POSTGRESQL_VERSION is 9.1.9
-- Install directory for libraries is set to /usr/lib/postgresql/9.1/lib
-- Install directory for SQL files is set to /usr/share/postgresql/9.1/extension
CMake Error at /usr/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108 (message):
DEFAULT_MSG

    (missing: SPHINX_EXECUTABLE)
Call Stack (most recent call first):
/usr/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315 (_FPHSA_FAILURE_MESSAGE)
   cmake/FindSphinx.cmake:16 (find_package_handle_standard_args)
   doc/CMakeLists.txt:14 (find_package)

-- Configuring incomplete, errors occurred!
make: *** No targets specified and no makefile found. Stop.

Sorry, Daniel posted the URL for those that have write privledges to the the repository. You can use the public one

git://github.com/pgRouting/pgrouting.git

or you can fork the repository if you have your won github account and make changes there and generate pull requests for us to pull your changes into the master respository.

https://github.com/pgRouting/pgrouting/tree/sew-devel-2_0

Notice the HTTP, SSH, Git Reead-Only buttons, by clicking on them you can see the different URLS that can be used.

git clone git://github.com/pgRouting/pgrouting.git
git checkout sew-devel-2_0
tools/doit
(cd build; sudo make install)
tools/test-runner.pl

is the standard way I build and test on Linux.

-Steve

On 5/25/2013 1:01 PM, Dave Potts wrote:

On 25/05/13 14:21, Stephen Woodbridge wrote:
hi

I tried Daniel suggestion ie
git clone git@github.com:pgRouting/pgrouting.git

and got
Cloning into 'pgrouting'...
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

not the error I was expecting

D.

Hi Dave,

We don't test in the tarball environment. May be you can figure out
the cmake stuff there. What is supposed to happen,

check if git exists or not (non fatal)
if git exists then
  if git repository get git hash
  else report non fatal message
else
  report non-fatal message

This is all done in this block:

# Find Git to collect version information
find_package(Git QUIET)
if(GIT_FOUND)
  message(STATUS "Found Git: ${GIT_EXECUTABLE}")
  GIT_WC_INFO(${PGROUTING_SOURCE_DIR} PGROUTING)
  set(PGROUTING_VERSION_REVISION_NAME "${PGROUTING_WC_REVISION_NAME}")
  set(PGROUTING_VERSION_REVISION_HASH "${PGROUTING_WC_REVISION_HASH}")
else()
  message(STATUS "Could NOT find GIT (optional)")
  set(PGROUTING_VERSION_REVISION_NAME "")
  set(PGROUTING_VERSION_REVISION_HASH "")
endif()

my guess is you have git and GIT_WC_INFO is fatal for not a repository.
The quick fix so you can continue is to replace the block above with

  set(PGROUTING_VERSION_REVISION_NAME "")
  set(PGROUTING_VERSION_REVISION_HASH "")

-Steve

On 5/25/2013 8:53 AM, Dave Potts wrote:

On 25/05/13 11:41, Daniel Kastl wrote:

On Sat, May 25, 2013 at 6:11 PM, Dave Potts <dave.potts@pinan.co.uk
<mailto:dave.potts@pinan.co.uk>> wrote:

    Hi list

    I want a play from the new version of the tsp code.

    I have tried building it on Ubuntu 3.2.0-43-generic #68-Ubuntu
    SMP with postgres 9.1.9 using the syntax

    cmake DebugFull .

    I got the following errors[See Below]

    Q. What should the build envronment be pgroute 2.0??

Hi Dave,

There seems to be a problem with the use of the Git module of CMake.
The check for Git is not something that must be included, but it's
convenient, because it allows to place the version information for
example in the documentation or some time into a function to retreive
the pgRouting version.

I have tested, that it works when you build from a Git repository with
Git installed.
And I think I have tested the case when Git is not installed and it's
not a Git repository.
In your case, do you build from a cloned repository?

    I have already upgraded my version of cmake 2.8.11

The required version is checked and it will give an error when your
version is not new enough.

These are a few commands I'm using to build on Ubuntu:
https://gist.github.com/dkastl/5617030

Hi DAniel,

WIll check out these tools, which version off Ubuntu are you on?

I did'nt clone a copy, I just got it out as a zip file.

Dave.

Daniel

    regards

    Dave.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    src/pgroute/pgr2.0/pgrouting-sew-devel-2_0 failed with output:

      fatal: Not a git repository (or any parent up to mount parent )

      Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM
    not set).

    Call Stack (most recent call first):
      CMakeLists.txt:68 (GIT_WC_INFO)

    CMake Warning at cmake/FindGit.cmake:144 (message):
      No remote origin set for git repository:
/home/dp42/src/pgroute/pgr2.0/pgrouting-sew-devel-2_0
    Call Stack (most recent call first):
      CMakeLists.txt:68 (GIT_WC_INFO)

    -- POSTGRESQL_EXECUTABLE is /usr/lib/postgresql/9.1/bin/postgres
    -- POSTGRESQL_PG_CONFIG is /usr/bin/pg_config
    -- POSTGRESQL_INCLUDE_DIR: /usr/include/postgresql/9.1/server
    -- POSTGRESQL_LIBRARIES: /usr/lib
    -- Boost version: 1.48.0
    Boost headers were found here: /usr/include
    -- POSTGRESQL_VERSION_STRING is PostgreSQL 9.1.9
    -- POSTGRESQL_VERSION is 9.1.9
    -- Install directory for libraries is set to
    /usr/lib/postgresql/9.1/lib
    -- Install directory for SQL files is set to
    /usr/share/postgresql/9.1/extension
    -- LIBS_TO_INSTALL=
    -- Configuring incomplete, errors occurred!

    _______________________________________________
    Pgrouting-users mailing list
    Pgrouting-users@lists.osgeo.org
    <mailto:Pgrouting-users@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de <mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

Stephen_Woodbridge1 · May 25, 2013, 5:52pm

Hi Dave,

tools/doit is a trivial script:

#!/bin/sh
rm -rf build
mkdir build
cd build
cmake -DWITH_DOC=ON -DWITH_DD=ON ..
make

The sphinx error can be worked around by removing -DWITH_DOC=ON from the cmake line.

I just made the script because I have to run it a million times a day when I'm changing stuff and merging code.

-Steve

On 5/25/2013 1:48 PM, Dave Potts wrote:

On 25/05/13 18:33, Stephen Woodbridge wrote:
Hi Steve,

Thanks for the prompt help, in the end I hacked the makefile and did a
normal make and compile a version.

I did try your build instructions
ie tools/doit and got an error about (missing: SPHINX_EXECUTABLE)

I am using cmake version 2.8.11

Dave.

----------------------------------------------------------------------------------

  tools/doit
-- UNIX=1
-- WIN32=
-- POSTGRESQL_EXECUTABLE is /usr/lib/postgresql/9.1/bin/postgres
-- POSTGRESQL_PG_CONFIG is /usr/bin/pg_config
-- POSTGRESQL_INCLUDE_DIR: /usr/include/postgresql/9.1/server
-- POSTGRESQL_LIBRARIES: /usr/lib
-- Boost version: 1.48.0
Boost headers were found here: /usr/include
-- POSTGRESQL_VERSION_STRING is PostgreSQL 9.1.9
-- POSTGRESQL_VERSION is 9.1.9
-- Install directory for libraries is set to /usr/lib/postgresql/9.1/lib
-- Install directory for SQL files is set to
/usr/share/postgresql/9.1/extension
CMake Error at
/usr/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:108
(message):
   DEFAULT_MSG

    (missing: SPHINX_EXECUTABLE)
Call Stack (most recent call first):
/usr/local/share/cmake-2.8/Modules/FindPackageHandleStandardArgs.cmake:315
(_FPHSA_FAILURE_MESSAGE)
   cmake/FindSphinx.cmake:16 (find_package_handle_standard_args)
   doc/CMakeLists.txt:14 (find_package)

-- Configuring incomplete, errors occurred!
make: *** No targets specified and no makefile found. Stop.

Sorry, Daniel posted the URL for those that have write privledges to
the the repository. You can use the public one

git://github.com/pgRouting/pgrouting.git

or you can fork the repository if you have your won github account and
make changes there and generate pull requests for us to pull your
changes into the master respository.

https://github.com/pgRouting/pgrouting/tree/sew-devel-2_0

Notice the HTTP, SSH, Git Reead-Only buttons, by clicking on them you
can see the different URLS that can be used.

git clone git://github.com/pgRouting/pgrouting.git
git checkout sew-devel-2_0
tools/doit
(cd build; sudo make install)
tools/test-runner.pl

is the standard way I build and test on Linux.

-Steve

On 5/25/2013 1:01 PM, Dave Potts wrote:

On 25/05/13 14:21, Stephen Woodbridge wrote:
hi

I tried Daniel suggestion ie
git clone git@github.com:pgRouting/pgrouting.git

and got
Cloning into 'pgrouting'...
Permission denied (publickey).
fatal: The remote end hung up unexpectedly

not the error I was expecting

D.

Hi Dave,

We don't test in the tarball environment. May be you can figure out
the cmake stuff there. What is supposed to happen,

check if git exists or not (non fatal)
if git exists then
  if git repository get git hash
  else report non fatal message
else
  report non-fatal message

This is all done in this block:

# Find Git to collect version information
find_package(Git QUIET)
if(GIT_FOUND)
  message(STATUS "Found Git: ${GIT_EXECUTABLE}")
  GIT_WC_INFO(${PGROUTING_SOURCE_DIR} PGROUTING)
  set(PGROUTING_VERSION_REVISION_NAME "${PGROUTING_WC_REVISION_NAME}")
  set(PGROUTING_VERSION_REVISION_HASH "${PGROUTING_WC_REVISION_HASH}")
else()
  message(STATUS "Could NOT find GIT (optional)")
  set(PGROUTING_VERSION_REVISION_NAME "")
  set(PGROUTING_VERSION_REVISION_HASH "")
endif()

my guess is you have git and GIT_WC_INFO is fatal for not a repository.
The quick fix so you can continue is to replace the block above with

  set(PGROUTING_VERSION_REVISION_NAME "")
  set(PGROUTING_VERSION_REVISION_HASH "")

-Steve

On 5/25/2013 8:53 AM, Dave Potts wrote:

On 25/05/13 11:41, Daniel Kastl wrote:

On Sat, May 25, 2013 at 6:11 PM, Dave Potts <dave.potts@pinan.co.uk
<mailto:dave.potts@pinan.co.uk>> wrote:

    Hi list

    I want a play from the new version of the tsp code.

    I have tried building it on Ubuntu 3.2.0-43-generic #68-Ubuntu
    SMP with postgres 9.1.9 using the syntax

    cmake DebugFull .

    I got the following errors[See Below]

    Q. What should the build envronment be pgroute 2.0??

Hi Dave,

There seems to be a problem with the use of the Git module of CMake.
The check for Git is not something that must be included, but it's
convenient, because it allows to place the version information for
example in the documentation or some time into a function to retreive
the pgRouting version.

I have tested, that it works when you build from a Git repository
with
Git installed.
And I think I have tested the case when Git is not installed and it's
not a Git repository.
In your case, do you build from a cloned repository?

    I have already upgraded my version of cmake 2.8.11

The required version is checked and it will give an error when your
version is not new enough.

These are a few commands I'm using to build on Ubuntu:
https://gist.github.com/dkastl/5617030

Hi DAniel,

WIll check out these tools, which version off Ubuntu are you on?

I did'nt clone a copy, I just got it out as a zip file.

Dave.

Daniel

    regards

    Dave.

----------------------------------------------------------------------------------------------------------------------------------------------------------------------------

    src/pgroute/pgr2.0/pgrouting-sew-devel-2_0 failed with output:

      fatal: Not a git repository (or any parent up to mount parent )

      Stopping at filesystem boundary
(GIT_DISCOVERY_ACROSS_FILESYSTEM
    not set).

    Call Stack (most recent call first):
      CMakeLists.txt:68 (GIT_WC_INFO)

    CMake Warning at cmake/FindGit.cmake:144 (message):
      No remote origin set for git repository:
/home/dp42/src/pgroute/pgr2.0/pgrouting-sew-devel-2_0
    Call Stack (most recent call first):
      CMakeLists.txt:68 (GIT_WC_INFO)

    -- POSTGRESQL_EXECUTABLE is /usr/lib/postgresql/9.1/bin/postgres
    -- POSTGRESQL_PG_CONFIG is /usr/bin/pg_config
    -- POSTGRESQL_INCLUDE_DIR: /usr/include/postgresql/9.1/server
    -- POSTGRESQL_LIBRARIES: /usr/lib
    -- Boost version: 1.48.0
    Boost headers were found here: /usr/include
    -- POSTGRESQL_VERSION_STRING is PostgreSQL 9.1.9
    -- POSTGRESQL_VERSION is 9.1.9
    -- Install directory for libraries is set to
    /usr/lib/postgresql/9.1/lib
    -- Install directory for SQL files is set to
    /usr/share/postgresql/9.1/extension
    -- LIBS_TO_INSTALL=
    -- Configuring incomplete, errors occurred!

    _______________________________________________
    Pgrouting-users mailing list
    Pgrouting-users@lists.osgeo.org
    <mailto:Pgrouting-users@lists.osgeo.org>
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
<mailto:daniel.kastl@georepublic.de>
Web: http://georepublic.de/>

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

_______________________________________________
Pgrouting-users mailing list
Pgrouting-users@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-users

dkastl · May 25, 2013, 5:57pm

On Sun, May 26, 2013 at 2:48 AM, Dave Potts <dave.potts@pinan.co.uk> wrote:

On 25/05/13 18:33, Stephen Woodbridge wrote:
Hi Steve,

Thanks for the prompt help, in the end I hacked the makefile and did a
normal make and compile a version.

I did try your build instructions
ie tools/doit and got an error about (missing: SPHINX_EXECUTABLE)

I am using cmake version 2.8.11

Dave.

------------------------------**------------------------------**
----------------------
tools/doit
-- UNIX=1
-- WIN32=

-- POSTGRESQL_EXECUTABLE is /usr/lib/postgresql/9.1/bin/**postgres
-- POSTGRESQL_PG_CONFIG is /usr/bin/pg_config
-- POSTGRESQL_INCLUDE_DIR: /usr/include/postgresql/9.1/**server
-- POSTGRESQL_LIBRARIES: /usr/lib
-- Boost version: 1.48.0
Boost headers were found here: /usr/include
-- POSTGRESQL_VERSION_STRING is PostgreSQL 9.1.9
-- POSTGRESQL_VERSION is 9.1.9
-- Install directory for libraries is set to /usr/lib/postgresql/9.1/lib
-- Install directory for SQL files is set to /usr/share/postgresql/9.1/**
extension
CMake Error at /usr/local/share/cmake-2.8/**Modules/**
FindPackageHandleStandardArgs.**cmake:108 (message):
  DEFAULT_MSG

   (missing: SPHINX_EXECUTABLE)

Call Stack (most recent call first):
/usr/local/share/cmake-2.8/**Modules/**FindPackageHandleStandardArgs.**cmake:315
(_FPHSA_FAILURE_MESSAGE)
  cmake/FindSphinx.cmake:16 (find_package_handle_standard_**args)
  doc/CMakeLists.txt:14 (find_package)

-- Configuring incomplete, errors occurred!
make: *** No targets specified and no makefile found. Stop

It includes building the documentation.
If you don't need the documentation you can try like this:

# Clone the repository
git clone git://github.com/pgRouting/pgrouting.git && cd pgrouting

# Compile

sudo rm -Rf build && cmake -H. -Bbuild -DWITH_DD=ON && cd build && make && cd ..

# Build and replace package

sudo dpkg -r pgrouting && cd build && sudo checkinstall -y --nodoc
--pkgversion=2.0.0 --pkgname=pgrouting && cd ..

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de

dkastl · May 26, 2013, 6:24am

# Find Git to collect version information

find_package(Git QUIET)
if(GIT_FOUND)
  message(STATUS "Found Git: ${GIT_EXECUTABLE}")
  GIT_WC_INFO(${PGROUTING_**SOURCE_DIR} PGROUTING)
  set(PGROUTING_VERSION_**REVISION_NAME "${PGROUTING_WC_REVISION_NAME}**")
  set(PGROUTING_VERSION_**REVISION_HASH "${PGROUTING_WC_REVISION_HASH}**")
else()
  message(STATUS "Could NOT find GIT (optional)")
  set(PGROUTING_VERSION_**REVISION_NAME "")
  set(PGROUTING_VERSION_**REVISION_HASH "")
endif()

my guess is you have git and GIT_WC_INFO is fatal for not a repository.
The quick fix so you can continue is to replace the block above with

  set(PGROUTING_VERSION_**REVISION_NAME "")
  set(PGROUTING_VERSION_**REVISION_HASH "")

This should be fixed now for everyone downloading the source as ZIP or TAR.
I added that Cmake is looking for a folder named ".git". So if the folder
exists, but doesn't contain the necessary files, then it will still fail.
But let's assume that this is not a case we have to care about.

Thanks for reporting, Dave!

Daniel

--
Georepublic UG & Georepublic Japan
eMail: daniel.kastl@georepublic.de
Web: http://georepublic.de