[mapserver-dev] PostGIS "curvepolygon" support

[thomas bonfort]

On Mon, Nov 8, 2010 at 17:51, Frank Warmerdam <warmerdam at pobox.com> wrote:
> Astrid Emde wrote:
>>
>> The main thing would be to get a sustainable solution with good
>> performance which bringsforward the mapServer project as maybe more and more
>> user will need this functionality.
>>
>> We have mixed data (linestrings mixed with compoundcurves and
>> circularstring and on the other hand polygons mixed with CURVEPOLYGONs) in
>> one feature table. At the moment we create a second geometry column where we
>> create with st_curvetoline(the_geom)  linestrings from our curves. We used
>> this function in the mapfile itself but the performance was too bad to do
>> the processing on every request.
>>
>> It would be good to define a MapServer LAYER from type LINESTRING or
>> POLYGON and display linestrings/compoundcurves/circularstring and
>> polygons/CURVEPOLYGONs.
>
> Astrid,
>
> In the case of approximating as lines, there would be no problem
> handling them using the existing LINE and POLYGON layers as they
> really would be a normal shapeObj by the time they come out of the
> mappostgis.c code.
>
>> Now about the "bigger job" to add arcs as a first class geometry type in
>> MapServer:
>> * what advantages would this bring?
>
> It offers two main advantages.
>
> 1) Speed: I believe (though I have not investigated) that the modern
> rendering engines (AGG and Cairo) would have API level support for
> curves and I believe it would generally be faster to render a curve
> as a curve rather than as a complex (dense) linestrings.

Yes, they have support for curves natively. I'm not at all certain
that using curves directly would have a significant speedup advantage.

>
> 2) Precision: Approximating arcs as lines will occasionally give
> small visible artifacts unless a very high approximation density is
> used.  Passing through as curves would avoid this.

As the renderers finally work on a raster grid, they inherently also
use an approximation scale. Using curves natively only means we are
transferring the approximation down to the renderers (at least for the
ones producing raster output. SVG or pdf renderers would embed the
curve directly if (as) those formats support curves natively)

>
>> * could we be able to handle both geometry types
>> linestrings/compoundcurves/circularstring and polygons/CURVEPOLYGONs within
>> one LAYER
>
> I believe so.
>
>> * what about the performance
>
> I think the performance would be best preserving the objects as
> arcs, though it is not clear to me whether the difference would
> be significant or not.
>
>> What do you think?
>
> Unfortunately, I think that adding support to the shapeObj, and the
> various rendering engines to handle arcs properly would be a huge
> job, and not really appropriate for this late date in the MapServer
> 6 release cycle.  In fact, I'm not even that confident that the
> benefits of handling things as curves would be worth the long term
> complication of mapserver internals.

agreed. we'd have to implement the transformation to a classic
shapeObj anyways for the renderers that don't natively support curves,
and also heavily modify other parts of the code to treat curves: I'm
thinking about the query code, and the text placement code for labels
on lines.

>
> So, I think for the time being we should stick with the approach
> of approximating curves as linestrings within the mappostgis code
> with the code to stroke the curves being made available to other
> backends as I believe Paul suggested.  This is similar to the
> approach I have taken within OGR.

I second this approach. In fine, supporting curves natively right down
to the renderer level has some very heavy implications throughout the
code, for benefits performance and quality-wise that are far from
evident. I should point out that this is only based on impression from
my point of view, and that if someone comes up with hard numbers
showing that there would be a real improvement by having native curves
I'd be glad to change my opinion.

best regards,

thomas

>
> From your reply to Paul:
>> At the moment we preprocess our data and create the strokes in the
>> database in a second geom_column. So we loose no performance as we
>> access the preprocessed data in our mapfiles. Solution b) will still do
>> the "stroke-processing" on-the-fly.
>
> Note that stroking curves to linestrings is not particularly expensive
> and doing it close to the rendering engine may have better performance
> that transporting dense linestrings out of the database.
>
>> Frank offered to implement a solution in GDAL/OGR so this would be for
>> CONNECTIONTYPE OGR and the solution you suggested would be for
>> CONNECTIONTYPE POSTGIS. Is this right?
>
> To be clear, I was suggesting to do this for CONNECTIONTYPE POSTGIS
> in mappostgis.c.  I might also pursue handling curves in the OGR
> PostGIS driver but I am not suggesting that mapserver uses ought
> to use the OGR approach for postgres as there is non-trivial
> overhead in the extra layers of translation.
>
> PS. stitching the mixtures of curves and linestrings together
> into complete polygon rings is a bit complicated and I hadn't
> considered it in my "couple hours" time estimate.
>
> Best regards,
> --
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>