[postgis-users] Is CIRCULARLINESTRING ready for use?

[Mark Leslie]

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