[pgrouting-dev] postgis2 and driving distance

Mario_Basa · June 19, 2012, 9:11am

Hi,

It really is possible now to take away CGAL from pgRouting since st_concavehull of PostGIS 2 can create the same alpha shape. I have already managed to compile diriving-dist without CGAL installed by modifying the cmake files and drivedist.c.

I used this:

select st_concavehull(st_collect(
st_geomfromewkt(‘srid=4326;POINT(’||x1||’ ‘||y1||’)‘)),0.7) from jp_2po_4pgr,
driving_distance(‘SELECT id,source,target,cost,reverse_cost from jp_2po_4pgr
where st_contains(ST_GeomFromEWKT(’‘SRID=4326;POLYGON((139 35,139 36,140 36,140 35,139 35))’’),
the_geom) = true’,156598,0.07,false,false) where id = edge_id;

to create the drive time polygon in the attached screen dump. The performance isn’t so bad even with a 0.7 target percent parameter for the concave hull.

I am planning to clean up routing_dd.sql and routing_dd_wrapper.sql and start using the newer st_* postgis functions.

Will there be any objections if I move routing_dd into core instead of extra since it will now only use BOOST to compile.

Mario.

Screen Shot 2012-06-19 at 4.49.38 PM.png

dkastl · June 19, 2012, 10:10am

Hi Mario,

I think it’s a good idea to drop CGAL if possible … and you proofed that it is possible.
I guess that PostGIS 2.0 will soon become a standard, so if we now want to make a bigger cleanup and new release of pgRouting it’s OK to require PostGIS 2.0 in my opinion. There haven’t been many questions about driving distance on the lists, so I assume there are not so many users of this function either.

If you move it into “core” (which is a good idea), please don’t commit it into “master” branch for now.
I would propose to either make a different branch for that, that we can merge later, or use “devel-2_0” branch, which already contains code cleanup: https://github.com/pgrouting/pgrouting/tree/devel-2_0

Daniel

On Tue, Jun 19, 2012 at 11:11 AM, Mario Basa <mario.basa@gmail.com> wrote:

Hi,

It really is possible now to take away CGAL from pgRouting since st_concavehull of PostGIS 2 can create the same alpha shape. I have already managed to compile diriving-dist without CGAL installed by modifying the cmake files and drivedist.c.

I used this:

select st_concavehull(st_collect(
st_geomfromewkt(‘srid=4326;POINT(’||x1||’ ‘||y1||’)‘)),0.7) from jp_2po_4pgr,
driving_distance(‘SELECT id,source,target,cost,reverse_cost from jp_2po_4pgr
where st_contains(ST_GeomFromEWKT(’‘SRID=4326;POLYGON((139 35,139 36,140 36,140 35,139 35))’’),
the_geom) = true’,156598,0.07,false,false) where id = edge_id;

to create the drive time polygon in the attached screen dump. The performance isn’t so bad even with a 0.7 target percent parameter for the concave hull.

I am planning to clean up routing_dd.sql and routing_dd_wrapper.sql and start using the newer st_* postgis functions.

Will there be any objections if I move routing_dd into core instead of extra since it will now only use BOOST to compile.

Mario.

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

Mario_Basa · June 20, 2012, 3:40am

Daniel,

You might want to limit st_startpoint usage in your devel-2.0 wrapper sql files. According to documentation:

Changed: 2.0.0 no longer works with single geometry multilinestrings. In older versions of PostGIS – a single line multilinestring would work happily with this function and return the start point. In 2.0.0 it just returns NULL like any other multilinestring. The older behavior was an undocumented feature, but people who assumed they had their data stored as LINESTRING may experience these returning NULL in 2.0 now.

I used osm2po to create the Japan networks and am getting nulls when I use st_startpoint.

Mario.

On Tue, Jun 19, 2012 at 6:10 PM, Daniel Kastl <daniel@georepublic.de> wrote:

Hi Mario,

I think it’s a good idea to drop CGAL if possible … and you proofed that it is possible.
I guess that PostGIS 2.0 will soon become a standard, so if we now want to make a bigger cleanup and new release of pgRouting it’s OK to require PostGIS 2.0 in my opinion. There haven’t been many questions about driving distance on the lists, so I assume there are not so many users of this function either.

If you move it into “core” (which is a good idea), please don’t commit it into “master” branch for now.
I would propose to either make a different branch for that, that we can merge later, or use “devel-2_0” branch, which already contains code cleanup: https://github.com/pgrouting/pgrouting/tree/devel-2_0

Daniel

On Tue, Jun 19, 2012 at 11:11 AM, Mario Basa <mario.basa@gmail.com> wrote:

Hi,

It really is possible now to take away CGAL from pgRouting since st_concavehull of PostGIS 2 can create the same alpha shape. I have already managed to compile diriving-dist without CGAL installed by modifying the cmake files and drivedist.c.

I used this:

select st_concavehull(st_collect(
st_geomfromewkt(‘srid=4326;POINT(’||x1||’ ‘||y1||’)‘)),0.7) from jp_2po_4pgr,
driving_distance(‘SELECT id,source,target,cost,reverse_cost from jp_2po_4pgr
where st_contains(ST_GeomFromEWKT(’‘SRID=4326;POLYGON((139 35,139 36,140 36,140 35,139 35))’’),
the_geom) = true’,156598,0.07,false,false) where id = edge_id;

to create the drive time polygon in the attached screen dump. The performance isn’t so bad even with a 0.7 target percent parameter for the concave hull.

I am planning to clean up routing_dd.sql and routing_dd_wrapper.sql and start using the newer st_* postgis functions.

Will there be any objections if I move routing_dd into core instead of extra since it will now only use BOOST to compile.

Mario.

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

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

dkastl · June 20, 2012, 6:37am

Hi Mario,

Thank you for this information!
Which files exactly do you mean with “wrapper sql files”?

So this means the line geometry MUST be LINESTRING from now? Or is there an alternative function to ST_startpoint?
Maybe it’s better that import tools like osm2po create a correct geometry type as MULTILINESTRING doesn’t make sense really for a routing network anyway.

In the past it just didn’t matter if you had LINESTRING or MULTILINESTRING, right?
I will create a ticket for this.

Daniel

On Wed, Jun 20, 2012 at 5:40 AM, Mario Basa <mario.basa@gmail.com> wrote:

Daniel,

You might want to limit st_startpoint usage in your devel-2.0 wrapper sql files. According to documentation:

Changed: 2.0.0 no longer works with single geometry multilinestrings. In older versions of PostGIS – a single line multilinestring would work happily with this function and return the start point. In 2.0.0 it just returns NULL like any other multilinestring. The older behavior was an undocumented feature, but people who assumed they had their data stored as LINESTRING may experience these returning NULL in 2.0 now.

I used osm2po to create the Japan networks and am getting nulls when I use st_startpoint.

Mario.

On Tue, Jun 19, 2012 at 6:10 PM, Daniel Kastl <daniel@georepublic.de> wrote:

Hi Mario,

I think it’s a good idea to drop CGAL if possible … and you proofed that it is possible.
I guess that PostGIS 2.0 will soon become a standard, so if we now want to make a bigger cleanup and new release of pgRouting it’s OK to require PostGIS 2.0 in my opinion. There haven’t been many questions about driving distance on the lists, so I assume there are not so many users of this function either.

If you move it into “core” (which is a good idea), please don’t commit it into “master” branch for now.
I would propose to either make a different branch for that, that we can merge later, or use “devel-2_0” branch, which already contains code cleanup: https://github.com/pgrouting/pgrouting/tree/devel-2_0

Daniel

On Tue, Jun 19, 2012 at 11:11 AM, Mario Basa <mario.basa@gmail.com> wrote:

Hi,

It really is possible now to take away CGAL from pgRouting since st_concavehull of PostGIS 2 can create the same alpha shape. I have already managed to compile diriving-dist without CGAL installed by modifying the cmake files and drivedist.c.

I used this:

select st_concavehull(st_collect(
st_geomfromewkt(‘srid=4326;POINT(’||x1||’ ‘||y1||’)‘)),0.7) from jp_2po_4pgr,
driving_distance(‘SELECT id,source,target,cost,reverse_cost from jp_2po_4pgr
where st_contains(ST_GeomFromEWKT(’‘SRID=4326;POLYGON((139 35,139 36,140 36,140 35,139 35))’’),
the_geom) = true’,156598,0.07,false,false) where id = edge_id;

to create the drive time polygon in the attached screen dump. The performance isn’t so bad even with a 0.7 target percent parameter for the concave hull.

I am planning to clean up routing_dd.sql and routing_dd_wrapper.sql and start using the newer st_* postgis functions.

Will there be any objections if I move routing_dd into core instead of extra since it will now only use BOOST to compile.

Mario.

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

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

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

Mario_Basa · June 20, 2012, 8:19am

Daniel,

They are all over the place. I am currently cleaning up matching.sql
in core since the routine_dd_wrapper.sql functions uses it.

Doing things like changing:

'select getsrid(the_geom) as srid from '||tbl||' where gid = (select
min(gid) from '||tbl||')'

to

'select st_srid(the_geom) as srid from '||tbl||' limit 1'

Actually I find this inconsistent since some sql files get the srid
via the above method while others it gets it from the geometry_column
metadata table. Either or is fine though except the latter assumes a
'the_geom' geometry column.

osm2po names its geometry column as 'geom_way' so there is a renaming
that has to be done.

I will try if it is possible to typecast a multilinestring into a
linestring so that st_startpoint will work.

Mario.

On Wed, Jun 20, 2012 at 2:37 PM, Daniel Kastl <daniel@georepublic.de> wrote:

Hi Mario,

Thank you for this information!
Which files exactly do you mean with "wrapper sql files"?

So this means the line geometry MUST be LINESTRING from now? Or is there an alternative function to ST_startpoint?
Maybe it's better that import tools like osm2po create a correct geometry type as MULTILINESTRING doesn't make sense really for a routing network anyway.

In the past it just didn't matter if you had LINESTRING or MULTILINESTRING, right?
I will create a ticket for this.

Daniel

On Wed, Jun 20, 2012 at 5:40 AM, Mario Basa <mario.basa@gmail.com> wrote:

Daniel,

You might want to limit st_startpoint usage in your devel-2.0 wrapper sql files. According to documentation:

Changed: 2.0.0 no longer works with single geometry multilinestrings. In older versions of PostGIS -- a single line multilinestring would work happily with this function and return the start point. In 2.0.0 it just returns NULL like any other multilinestring. The older behavior was an undocumented feature, but people who assumed they had their data stored as LINESTRING may experience these returning NULL in 2.0 now.

I used osm2po to create the Japan networks and am getting nulls when I use st_startpoint.

Mario.

On Tue, Jun 19, 2012 at 6:10 PM, Daniel Kastl <daniel@georepublic.de> wrote:

Hi Mario,

I think it's a good idea to drop CGAL if possible ... and you proofed that it is possible.
I guess that PostGIS 2.0 will soon become a standard, so if we now want to make a bigger cleanup and new release of pgRouting it's OK to require PostGIS 2.0 in my opinion. There haven't been many questions about driving distance on the lists, so I assume there are not so many users of this function either.

If you move it into "core" (which is a good idea), please don't commit it into "master" branch for now.
I would propose to either make a different branch for that, that we can merge later, or use "devel-2_0" branch, which already contains code cleanup: https://github.com/pgrouting/pgrouting/tree/devel-2_0

Daniel

On Tue, Jun 19, 2012 at 11:11 AM, Mario Basa <mario.basa@gmail.com> wrote:

Hi,

It really is possible now to take away CGAL from pgRouting since st_concavehull of PostGIS 2 can create the same alpha shape. I have already managed to compile diriving-dist without CGAL installed by modifying the cmake files and drivedist.c.

I used this:

select st_concavehull(st_collect(
st_geomfromewkt('srid=4326;POINT('||x1||' '||y1||')')),0.7) from jp_2po_4pgr,
driving_distance('SELECT id,source,target,cost,reverse_cost from jp_2po_4pgr
where st_contains(ST_GeomFromEWKT(''SRID=4326;POLYGON((139 35,139 36,140 36,140 35,139 35))''),
the_geom) = true',156598,0.07,false,false) where id = edge_id;

to create the drive time polygon in the attached screen dump. The performance isn't so bad even with a 0.7 target percent parameter for the concave hull.

I am planning to clean up routing_dd.sql and routing_dd_wrapper.sql and start using the newer st_* postgis functions.

Will there be any objections if I move routing_dd into core instead of extra since it will now only use BOOST to compile.

Mario.

_______________________________________________
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

_______________________________________________
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

--
Georepublic UG & Georepublic Japan
eMail: 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

dkastl · June 20, 2012, 8:36am

Hi Mario,

I think there is a lot to cleanup. But if you start with devel-2_0 branch probably some work has been done already.
The MULTILINESTRING probably come from pgDijkstra already. I think MULTILINESTRING is the default geometry type when you run shp2pgsql.

I sent your previous post to the list also to Carsten, the author of osm2po, and he will care about it, he said. It’s better (and also correct IMO) to require LINESTRING as geometry type. PostGIS 2.0 also provides topology functions. It’s better to be more strict with this geometry stuff.
I’m not sure how difficult it is to change the geometry type of a geometry column, but for a routing network we can (must) assume that all features are LINESTRING. Maybe we can provide a function or script to transform MULTILINESTRING routing tables to LINESTRING.

Actually I find this inconsistent since some sql files get the srid
via the above method while others it gets it from the geometry_column
metadata table. Either or is fine though except the latter assumes a
‘the_geom’ geometry column.

I don’t know which is better …

osm2po names its geometry column as ‘geom_way’ so there is a renaming
that has to be done.

You can just modify the “PgRoutingWriter” plugin:
https://github.com/pgRouting/pgrouting-contrib/blob/master/plugin-osm2po/PgRoutingWriter.java

Usually I renamed the columns as I need them with a VIEW.

Btw, if you’re already looking through the source files, another issues that might not be consistent, is support for “schema”.
When I installed PostGIS 2.0 recently I saw that there is a “topology” schema that contains all functions. So it’s very easy to maintain, drop and update. I like it and it could be nice to have a “pgrouting” schema as well.
Then we don’t need something like this: https://github.com/pgRouting/pgrouting/pull/40

Daniel

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

Stephen_Woodbridge1 · June 20, 2012, 3:15pm

You should be able write a simple wrapper for st_startpoint like:

create or replace function pgr_startpoint(line geometry)
returns geometry as
$body$
declare
   pnt geometry;
begin
   if geometrytype(line) = 'LINESTRING' then
     pnt := st_startpoint(line);
   elsif geometrytype(line) = 'MULTILINESTRING' then
     pnt := st_startpoint(st_geometryn(line,1));
   else
     return null;
   end if;
   return pnt;
end;
$body$
   language plpgsql stable;

I think we need to support MULTILINESTRING because the shapefile loader creates then by default. I understand that "real" MULTILINESTRING objects may not make sense but we can also just state the ALL MULTILINESTRING objects will be treated as those it is a valid contiguous path from start point to end point and that it is the users responsibility for model the graph correctly if they have a different interpertation of what a MULTILINESTRING means in their models.

-Steve

On 6/20/2012 2:37 AM, Daniel Kastl wrote:

Hi Mario,

Thank you for this information!
Which files exactly do you mean with "wrapper sql files"?

So this means the line geometry MUST be LINESTRING from now? Or is there
an alternative function to ST_startpoint?
Maybe it's better that import tools like osm2po create a correct
geometry type as MULTILINESTRING doesn't make sense really for a routing
network anyway.

  In the past it just didn't matter if you had LINESTRING or
MULTILINESTRING, right?
I will create a ticket for this.

Daniel

On Wed, Jun 20, 2012 at 5:40 AM, Mario Basa <mario.basa@gmail.com
<mailto:mario.basa@gmail.com>> wrote:

    Daniel,

    You might want to limit st_startpoint usage in your devel-2.0
    wrapper sql files. According to documentation:

    Changed: 2.0.0 no longer works with single geometry
    multilinestrings. In older versions of PostGIS -- a single line
    multilinestring would work happily with this function and return the
    start point. In 2.0.0 it just returns NULL like any other
    multilinestring. The older behavior was an undocumented feature, but
    people who assumed they had their data stored as LINESTRING may
    experience these returning NULL in 2.0 now.

    I used osm2po to create the Japan networks and am getting nulls when
    I use st_startpoint.

    Mario.

    On Tue, Jun 19, 2012 at 6:10 PM, Daniel Kastl <daniel@georepublic.de
    <mailto:daniel@georepublic.de>> wrote:

        Hi Mario,

        I think it's a good idea to drop CGAL if possible ... and you
        proofed that it is possible.
        I guess that PostGIS 2.0 will soon become a standard, so if we
        now want to make a bigger cleanup and new release of pgRouting
        it's OK to require PostGIS 2.0 in my opinion. There haven't been
        many questions about driving distance on the lists, so I assume
        there are not so many users of this function either.

        If you move it into "core" (which is a good idea), please don't
        commit it into "master" branch for now.
        I would propose to either make a different branch for that, that
        we can merge later, or use "devel-2_0" branch, which already
        contains code cleanup:
        https://github.com/pgrouting/pgrouting/tree/devel-2_0

        Daniel

        On Tue, Jun 19, 2012 at 11:11 AM, Mario Basa
        <mario.basa@gmail.com <mailto:mario.basa@gmail.com>> wrote:

            Hi,

            It really is possible now to take away CGAL from pgRouting
            since st_concavehull of PostGIS 2 can create the same alpha
            shape. I have already managed to compile diriving-dist
            without CGAL installed by modifying the cmake files and
            drivedist.c.

            I used this:

            select st_concavehull(st_collect(
               st_geomfromewkt('srid=4326;POINT('||x1||'
            '||y1||')')),0.7) from jp_2po_4pgr,
               driving_distance('SELECT
            id,source,target,cost,reverse_cost from jp_2po_4pgr
               where
            st_contains(ST_GeomFromEWKT(''SRID=4326;POLYGON((139 35,139
            36,140 36,140 35,139 35))''),
               the_geom) = true',156598,0.07,false,false) where id =
            edge_id;

            to create the drive time polygon in the attached screen
            dump. The performance isn't so bad even with a 0.7 target
            percent parameter for the concave hull.

            I am planning to clean up routing_dd.sql and
            routing_dd_wrapper.sql and start using the newer st_*
            postgis functions.

            Will there be any objections if I move routing_dd into core
            instead of extra since it will now only use BOOST to compile.

            Mario.

            _______________________________________________
            pgrouting-dev mailing list
            pgrouting-dev@lists.osgeo.org
            <mailto:pgrouting-dev@lists.osgeo.org>
            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 <mailto:pgrouting-dev@lists.osgeo.org>
        http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

    _______________________________________________
    pgrouting-dev mailing list
    pgrouting-dev@lists.osgeo.org <mailto:pgrouting-dev@lists.osgeo.org>
    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

Mario_Basa · June 21, 2012, 8:38am

cool. thanks Steve.

Mario.

On Wed, Jun 20, 2012 at 11:15 PM, Stephen Woodbridge
<woodbri@swoodbridge.com> wrote:

You should be able write a simple wrapper for st_startpoint like:

create or replace function pgr_startpoint(line geometry)
returns geometry as
$body$
declare
pnt geometry;
begin
if geometrytype(line) = 'LINESTRING' then
pnt := st_startpoint(line);
elsif geometrytype(line) = 'MULTILINESTRING' then
pnt := st_startpoint(st_geometryn(line,1));
else
return null;
end if;
return pnt;
end;
$body$
language plpgsql stable;

I think we need to support MULTILINESTRING because the shapefile loader
creates then by default. I understand that "real" MULTILINESTRING objects
may not make sense but we can also just state the ALL MULTILINESTRING
objects will be treated as those it is a valid contiguous path from start
point to end point and that it is the users responsibility for model the
graph correctly if they have a different interpertation of what a
MULTILINESTRING means in their models.

-Steve

On 6/20/2012 2:37 AM, Daniel Kastl wrote:
Hi Mario,

Thank you for this information!
Which files exactly do you mean with "wrapper sql files"?

So this means the line geometry MUST be LINESTRING from now? Or is there
an alternative function to ST_startpoint?
Maybe it's better that import tools like osm2po create a correct
geometry type as MULTILINESTRING doesn't make sense really for a routing
network anyway.

In the past it just didn't matter if you had LINESTRING or
MULTILINESTRING, right?
I will create a ticket for this.

Daniel

On Wed, Jun 20, 2012 at 5:40 AM, Mario Basa <mario.basa@gmail.com
<mailto:mario.basa@gmail.com>> wrote:

Daniel,

You might want to limit st_startpoint usage in your devel-2.0
wrapper sql files. According to documentation:

Changed: 2.0.0 no longer works with single geometry
multilinestrings. In older versions of PostGIS -- a single line
multilinestring would work happily with this function and return the
start point. In 2.0.0 it just returns NULL like any other
multilinestring. The older behavior was an undocumented feature, but
people who assumed they had their data stored as LINESTRING may
experience these returning NULL in 2.0 now.

I used osm2po to create the Japan networks and am getting nulls when
I use st_startpoint.

Mario.

On Tue, Jun 19, 2012 at 6:10 PM, Daniel Kastl <daniel@georepublic.de
<mailto:daniel@georepublic.de>> wrote:
   Hi Mario,

   I think it&#39;s a good idea to drop CGAL if possible \.\.\. and you
   proofed that it is possible\.
   I guess that PostGIS 2\.0 will soon become a standard, so if we
   now want to make a bigger cleanup and new release of pgRouting
   it&#39;s OK to require PostGIS 2\.0 in my opinion\. There haven&#39;t been
   many questions about driving distance on the lists, so I assume
   there are not so many users of this function either\.

   If you move it into &quot;core&quot; $which is a good idea$, please don&#39;t
   commit it into &quot;master&quot; branch for now\.
   I would propose to either make a different branch for that, that
   we can merge later, or use &quot;devel\-2\_0&quot; branch, which already
   contains code cleanup:
   https://github.com/pgrouting/pgrouting/tree/devel-2_0

   Daniel

   On Tue, Jun 19, 2012 at 11:11 AM, Mario Basa
   &lt;mario\.basa@gmail\.com &lt;mailto:mario.basa@gmail.com&gt;&gt; wrote:

       Hi,

       It really is possible now to take away CGAL from pgRouting
       since st\_concavehull of PostGIS 2 can create the same alpha
       shape\. I have already managed to compile diriving\-dist
       without CGAL installed by modifying the cmake files and
       drivedist\.c\.

       I used this:

       select st\_concavehull$st\_collect\(
          st\_geomfromewkt\(&#39;srid=4326;POINT\(&#39;||x1||&#39;
       &#39;||y1||&#39;$&#39;\)\),0\.7\) from jp\_2po\_4pgr,
          driving\_distance$&#39;SELECT
       id,source,target,cost,reverse\_cost from jp\_2po\_4pgr
          where
       st\_contains\(ST\_GeomFromEWKT\(&#39;&#39;SRID=4326;POLYGON\(\(139 35,139
       36,140 36,140 35,139 35$\)&#39;&#39;\),
          the\_geom\) = true&#39;,156598,0\.07,false,false\) where id =
       edge\_id;

       to create the drive time polygon in the attached screen
       dump\. The performance isn&#39;t so bad even with a 0\.7 target
       percent parameter for the concave hull\.

       I am planning to clean up routing\_dd\.sql and
       routing\_dd\_wrapper\.sql and start using the newer st\_\*
       postgis functions\.

       Will there be any objections if I move routing\_dd into core
       instead of extra since it will now only use BOOST to compile\.

       Mario\.

       \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
       pgrouting\-dev mailing list
       pgrouting\-dev@lists\.osgeo\.org
       &lt;mailto:pgrouting-dev@lists.osgeo.org&gt;

       http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

   \-\-
   Georepublic UG &amp; Georepublic Japan
   eMail: daniel\.kastl@georepublic\.de
   &lt;mailto:daniel.kastl@georepublic.de&gt;
   Web: http://georepublic.de/&gt;

   \_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_\_
   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 <mailto:pgrouting-dev@lists.osgeo.org>

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
_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/pgrouting-dev