[postgis-users] Is CIRCULARLINESTRING ready for use?
Markus Schneider
I am interested in the SQL-MM Part 3 geometries, especially CIRCULARSTRING.
Playing a bit around I noticed the following:
- Storing and retrieving of CIRCULARSTRING instances seems to work fine
- Spatial predicates (I tested ST_Intersects) don't seem to be supported yet
- Index based queries (&&) seem to work
My questions:
1. Do you think that it is already feasible to use PostGIS for an
application that stores large quantities of geometries(that sometimes
contain arcs (circular linestrings)? Do you consider these functions stable?
2. Is there a plan or an assumption when support for spatial predicates
(especially intersects) will become available?
3. Will the && operator (the spatial index) produce reliable results for
all configurations of CIRCULARSTRING? I suppose that this is not
completely trivial, as it is probably not enough to just store the bbox
of all arc points in the index, is it? Do you consider the && operator
for arcs ready?
Best regards and thanks in advance,
--
Markus Schneider
l a t / l o n GmbH
Aennchenstrasse 19 53177 Bonn, Germany
phone ++49 +228 18496-0 fax ++49 +228 18496-29
http://www.lat-lon.de http://www.deegree.org
_______________________________________________
postgis-users mailing list
postgi...@postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users
Mark Leslie
supported curved geometries should scale to large numbers perfectly
well, but not all the SQL-MM geometries are currently supported. In
particular, PostGIS was choking when I attempted to implement curved
polygons. Index support is complete, but I don't recall any heavy
testing to ensure it's solid. It does manage to calculate a fairly
tight bounding box based on the curvature of the segment, not just the
defining points, so I would consider it ready for substantial testing.
If only we had a volunteer with a large number of circular string
geometries ;)
I've been struggling to get the time to at least draw up a plan for
completing this work, but my time is currently not my own.
As for the spatial predicates, these are very unlikely to be implemented
before the curve support is complete and fairly heavily tested. It
would also likely involve prototyping in JTS, or maybe one of the JTS
extensions that are emerging for this very purpose, before porting to
GEOS. As it stands, these functions should error out 'gracefully'.
Mark Leslie
Markus Schneider wrote:
> Hello,
>
> I am interested in the SQL-MM Part 3 geometries, especially CIRCULARSTRING.
>
> Playing a bit around I noticed the following:
>
> - Storing and retrieving of CIRCULARSTRING instances seems to work fine
> - Spatial predicates (I tested ST_Intersects) don't seem to be supported yet
> - Index based queries (&&) seem to work
>
> My questions:
>
> 1. Do you think that it is already feasible to use PostGIS for an
> application that stores large quantities of geometries(that sometimes
> contain arcs (circular linestrings)? Do you consider these functions stable?
> 2. Is there a plan or an assumption when support for spatial predicates
> (especially intersects) will become available?
> 3. Will the && operator (the spatial index) produce reliable results for
> all configurations of CIRCULARSTRING? I suppose that this is not
> completely trivial, as it is probably not enough to just store the bbox
> of all arc points in the index, is it? Do you consider the && operator
> for arcs ready?
>
> Best regards and thanks in advance,
>
>
_______________________________________________
Markus Schneider
Mark Leslie wrote:
> Support for CIRCULARSTRING is there. Loading and retrieving of the
> supported curved geometries should scale to large numbers perfectly
> well, but not all the SQL-MM geometries are currently supported. In
> particular, PostGIS was choking when I attempted to implement curved
> polygons. Index support is complete, but I don't recall any heavy
> testing to ensure it's solid. It does manage to calculate a fairly
> tight bounding box based on the curvature of the segment, not just the
> defining points, so I would consider it ready for substantial testing.
> If only we had a volunteer with a large number of circular string
> geometries ;)
I cannot guarantee this yet, but maybe we can use the datasets in our project
for testing. But I still have to wait for a decision whether we want to go into
this direction or whether we just keep our current approach which stores curves
as linearized line strings
Best regards,
--
Markus Schneider
l a t / l o n GmbH
Aennchenstrasse 19 53177 Bonn, Germany
phone ++49 +228 18496-0 fax ++49 +228 18496-29
http://www.lat-lon.de http://www.deegree.org
Bruce Rindahl
> Support for CIRCULARSTRING is there. Loading and retrieving of the
> supported curved geometries should scale to large numbers perfectly
> well, but not all the SQL-MM geometries are currently supported. In
> particular, PostGIS was choking when I attempted to implement curved
> polygons. Index support is complete, but I don't recall any heavy
> testing to ensure it's solid. It does manage to calculate a fairly
> tight bounding box based on the curvature of the segment, not just the
> defining points, so I would consider it ready for substantial
> testing. If only we had a volunteer with a large number of circular
> string geometries ;)
http://en.wikipedia.org/wiki/Twelve-Mile_Circle
I also have numerous parcels with circular arcs for testing but you must
tell me what the syntax is. The documentation gives CIRCULARSTRING(0 0,
1 1, 1 0) but does not tell you what the points 0 0 , 1 1 and 1 0
mean. Three point arc? Start, end, center? Let me know and I will
send you lots of shapes.
See:
http://postgis.refractions.net/pipermail/postgis-devel/2007-September/002778.html
I don't think this post was ever answered.
Finally I have to question the support of circularstrings if we don't
support ellipses. The circle of Delaware is an ellipse in every
projection except geodetic (?). We can't correctly project a
circularstring to anything and maintain the spatial relationship. For
example in SVG there is no circle command in paths - only ellipses. A
circular arc is defined as an ellipse with both radii the same.
Comments??
Bruce
Frank Warmerdam
> I also have numerous parcels with circular arcs for testing but you must
> tell me what the syntax is. The documentation gives CIRCULARSTRING(0 0,
> 1 1, 1 0) but does not tell you what the points 0 0 , 1 1 and 1 0
> mean. Three point arc? Start, end, center? Let me know and I will
> send you lots of shapes.
Bruce,
Start, End and any other point on the arc that isn't the start or end.
Note necessarily the center. In the case of a circle the start and
end are the same, but the intermediate point *is* required to be the
arc center (ie. the opposite side of the circle).
> Finally I have to question the support of circularstrings if we don't
> support ellipses. The circle of Delaware is an ellipse in every
> projection except geodetic (?). We can't correctly project a
> circularstring to anything and maintain the spatial relationship. For
> example in SVG there is no circle command in paths - only ellipses. A
> circular arc is defined as an ellipse with both radii the same.
://postgis.refractions.net/mailman/listinfo/postgis-users
I too am dubious about the use of a circular arc segment instead of
an elliptical arc segment. However, in this regard PostGIS is just
tracking OGC and ISO standards, so take the argument to them.
Best regards,
--
---------------------------------------+--------------------------------------
I set the clouds in motion - turn up | Frank Warmerdam, warm...@pobox.com
light and sound - activate the windows | http://pobox.com/~warmerdam
and watch the world go round - Rush | President OSGeo, http://osgeo.org
Mark Leslie
somewhat embarrassed. I'll answer it here for posterity.
1) CIRCULARSTRING(0 0, 1 1, 1 0)
Frank defined this well, quoted here for completeness.
Start, End and any other point on the arc that isn't the start or end.
Note necessarily the center. In the case of a circle the start and
end are the same, but the intermediate point *is* required to be the
arc center (ie. the opposite side of the circle).
I will add the a circular string need not define only one circular arc. In the case of multiple arcs
in a string, the last point of the preceding arc is the first point of the succeeding arc. An example
would be CIRCULARSTRING(0 0, 1 1, 1 0, 4 3, 9 8) This means that a valid circular string must have an
odd number of points greater than 1 ( n > 1 && n % 2 == 1)
2) COMPOUNDCURVE(CIRCULARSTRING(0 0, 1 1, 1 0),(1 0, 0 1))
A compound curve is a single, continuous curve that has both curved (circular) segments and
linear segments. That means that in addition to having well-formed components, the end point
every component except the last must be coincident with the start point of the following component.
3) CURVEPOLYGON(CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0),(1 1, 3 3, 3 1,
1 1))
A curved polygon is just like a polygon, with an outer ring and zero or more inner rings. The difference
is a ring can take the form of a circular string, linear string or compound string. This is where PostGIS
currently falls down. The way we internally represent a compound string causes problems when embedding
within curve polygons.
4) MULTICURVE((0 0, 5 5),CIRCULARSTRING(4 0, 4 4, 8 4))
This is a collection of curves, which can include linear strings, circular string or compound strings.
5) MULTISURFACE(CURVEPOLYGON(CIRCULARSTRING(0 0, 4 0, 4 4, 0 4, 0 0),(1
1, 3 3, 3 1, 1 1)),((10 10, 14 12, 11 10, 10 10),(11 11, 11.5 11, 11
11.5, 11 11)))
This is a collection of polygons, which can include curve polygons or linear polygons.
--
Mark Leslie
Geospatial Software Architect
LISAsoft
-------------------------------------------------------------
Ph: +61 2 8570 5000 Fax: +61 2 8570 5099 Mob: +61
Suite 112, Jones Bay Wharf 19-21 Pirrama Rd Pyrmont NSW 2009
-------------------------------------------------------------
LISAsoft is part of the A2end Group of Companies
http://www.ardec.com.au
http://www.lisasoft.com
http://www.terrapages.com