[pgrouting-dev] difference between st_convexhull and pgr_pointsAsPolygon

Hi list

I am doing some with the end results of a driving distance calculation, I can use either st_convexhull or pgr_pointsAsPolygon to turn the end results in to a polygon

Q. What is the advantage of using pgr_pointsAsPolygon instead of using st_convexhull?

regards

Dave.

On 4/13/2015 3:50 PM, Dave Potts wrote:

Hi list

I am doing some with the end results of a driving distance calculation,
I can use either st_convexhull or pgr_pointsAsPolygon to turn the end
results in to a polygon

Q. What is the advantage of using pgr_pointsAsPolygon instead of using
st_convexhull?

pgr_pointsAsPolygon should give you a concave hull with holes where as st_convexhull will only give you a convex hull. So it depends on your needs. For some problems convex hull might be good enough and would be faster.

-Steve

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Date: Mon, 13 Apr 2015 20:50:47 +0100
From: dave.potts@pinan.co.uk
To: pgrouting-dev@lists.osgeo.org
Subject: [pgrouting-dev] difference between st_convexhull and pgr_pointsAsPolygon

Hi list

I am doing some with the end results of a driving distance calculation,
I can use either st_convexhull or pgr_pointsAsPolygon to turn the end
results in to a polygon

Q. What is the advantage of using pgr_pointsAsPolygon instead of using
st_convexhull?

regards

Dave.


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

By inspecting pgRouting code, there is some checking taking place…
https://github.com/pgRouting/pgrouting/blob/develop/src/driving_distance/sql/routing_dd.sql#L77

But now that you are one it, does it give you different results?

Vicky.

Hi No Idea, just noted the two different ways of doing and wondered why there was an extra method in the pg route package to do something that you got by default from postgis.

···

On 14/04/15 02:23, Vicky Vergara wrote:

Date: Mon, 13 Apr 2015 20:50:47 +0100
From: dave.potts@pinan.co.uk
To: pgrouting-dev@lists.osgeo.org
Subject: [pgrouting-dev] difference between st_convexhull and pgr_pointsAsPolygon

Hi list

I am doing some with the end results of a driving distance calculation,
I can use either st_convexhull or pgr_pointsAsPolygon to turn the end
results in to a polygon

Q. What is the advantage of using pgr_pointsAsPolygon instead of using
st_convexhull?

regards

Dave.


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

By inspecting pgRouting code, there is some checking taking place…
https://github.com/pgRouting/pgrouting/blob/develop/src/driving_distance/sql/routing_dd.sql#L77

But now that you are one it, does it give you different results?

Vicky.

_______________________________________________
pgrouting-dev mailing list
[pgrouting-dev@lists.osgeo.org](mailto:pgrouting-dev@lists.osgeo.org)
[http://lists.osgeo.org/mailman/listinfo/pgrouting-dev](http://lists.osgeo.org/mailman/listinfo/pgrouting-dev)

On 4/15/2015 1:09 AM, Dave Potts wrote:

On 14/04/15 02:23, Vicky Vergara wrote:

> Date: Mon, 13 Apr 2015 20:50:47 +0100
> From: dave.potts@pinan.co.uk
> To: pgrouting-dev@lists.osgeo.org
> Subject: [pgrouting-dev] difference between st_convexhull and
pgr_pointsAsPolygon
>
> Hi list
>
> I am doing some with the end results of a driving distance calculation,
> I can use either st_convexhull or pgr_pointsAsPolygon to turn the end
> results in to a polygon
>
> Q. What is the advantage of using pgr_pointsAsPolygon instead of using
> st_convexhull?
>
> regards
>
> Dave.
> _______________________________________________
> pgrouting-dev mailing list
> pgrouting-dev@lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/pgrouting-dev

By inspecting pgRouting code, there is some checking taking place...
https://github.com/pgRouting/pgrouting/blob/develop/src/driving_distance/sql/routing_dd.sql#L77

But now that you are one it, does it give you different results?

Hi

No Idea, just noted the two different ways of doing and wondered why
there was an extra method in the pg route package to do something that
you got by default from postgis.

This is probably because driving distance was written some years ago before these functions were available in postgis. My thought has been to drop the CGAL dependency and implement the contouring in postgis, but I have not gotten around to that yet.

Dropping the CGAL dependency is somewhat less important these days because I believe that postgis now has a dependency on that for some part of the raster code. It used to be a pain for users build with that, but it has gotten better package support now that it is getting used in other GIS packages.

-Steve

Vicky.

_______________________________________________
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

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Dropping the CGAL dependency is somewhat less important these days

because I believe that postgis now has a dependency on that for some part of
the raster code. It used to be a pain for users build with

that, but it has gotten better package support now that it is getting used

in other GIS packages.

The CGAL dependency in PostGIS is not for raster but the SFCGAL extension to
PostGIS for 3D support. It will probably get much more traction in PostGIS
2.2., but right now I don't think in PostGIS 2.1 any shipped distributions
are building with SFCGAL support. So probably at least a concern for
PostGIS 2.1 and below.

Thanks,
Regina

On 4/15/2015 10:33 AM, Paragon Corporation wrote:

  Dropping the CGAL dependency is somewhat less important these days

because I believe that postgis now has a dependency on that for some part of
the raster code. It used to be a pain for users build with

that, but it has gotten better package support now that it is getting used

in other GIS packages.

The CGAL dependency in PostGIS is not for raster but the SFCGAL extension to
PostGIS for 3D support. It will probably get much more traction in PostGIS
2.2., but right now I don't think in PostGIS 2.1 any shipped distributions
are building with SFCGAL support. So probably at least a concern for
PostGIS 2.1 and below.

Regina,

Thanks, I remember it was for something that was coming but just was sure what.

Anyway, being able to get the points out of driving distance and then generating the contour lines using just postgis would be an interesting example and if the performance is reasonable then it might be a good replacement or alternative to the existing code and just use postgis instead for creating the isochrone contours.

-Steve

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

Hi list,

I think that removing "Alpha Shape" function from pgRouting,
then moving it to SFCGAL extension may be good for modularity.
(I don't know well about SFCGAL and its PostGIS binding,
but will it be "SFCGAL::algorithm::alphaShape" and "ST_AlphaShape" ?)

In my understanding, PostGIS "ST_ConcaveHull" algorithm is a bit different from
CGAL "Alpha Shape" function, so adding "ST_AlphaShape" (or "ST_Isochrone" ?)
will be necessary in that case.

=====
[ST_ConcaveHull]
ST_ConcaveHull
[CGAL 4.6 - 2D Alpha Shapes: User Manual]
CGAL 5.6 - 2D Alpha Shapes: User Manual

Also, porting osrm-isochrone to PostGIS itself may be an another possibility.

2015-04-10 4:44 GMT+09:00 Stephen Woodbridge <woodbri@swoodbridge.com>:

FYI. Here is a driving distance tools based on NodeJs that is part of
mapbox.

GitHub - mapbox/osrm-isochrone: Generate drivetime isochrones from OpenStreetMap data using OSRM

Just my idea.

Regards,

2015-04-15 23:34 GMT+09:00 Stephen Woodbridge <woodbri@swoodbridge.com>:

On 4/15/2015 10:33 AM, Paragon Corporation wrote:

  Dropping the CGAL dependency is somewhat less important these days

because I believe that postgis now has a dependency on that for some part
of
the raster code. It used to be a pain for users build with

that, but it has gotten better package support now that it is getting
used

in other GIS packages.

The CGAL dependency in PostGIS is not for raster but the SFCGAL extension
to
PostGIS for 3D support. It will probably get much more traction in
PostGIS
2.2., but right now I don't think in PostGIS 2.1 any shipped
distributions
are building with SFCGAL support. So probably at least a concern for
PostGIS 2.1 and below.

Regina,

Thanks, I remember it was for something that was coming but just was sure
what.

Anyway, being able to get the points out of driving distance and then
generating the contour lines using just postgis would be an interesting
example and if the performance is reasonable then it might be a good
replacement or alternative to the existing code and just use postgis instead
for creating the isochrone contours.

-Steve

---
This email has been checked for viruses by Avast antivirus software.
http://www.avast.com

_______________________________________________
pgrouting-dev mailing list
pgrouting-dev@lists.osgeo.org
pgrouting-dev Info Page

--
Ko Nagase (長瀬 興)
Georepublic Japan
mail: nagase@georepublic.co.jp
web: http://georepublic.co.jp