[mapserver-dev] PostGIS "curvepolygon" support

[AxuMagic3496]

I confess that I do not know much about MapServer beside using it to show
maps. I have not been able to also help with any programming as of yet, I am
too preoccupied with other stuff at the moment to learn the internals of
MapServer save knowing how to use a map file and all the wonderful things it
allows one to do. So I am giving my opinion as one who is uninitiated.

I think Thomas is correct that having curves natively does not mean that we
avoid fitting a curve at some level. We use pixels to draw an image and I do
not know if there is way to draw a curve with it unless some sort of
approximation is made.

I am a civil engineer by training and experience of many years as a
transportation engineer my heart is moved when I see perfect geometric data.
A beautiful arc between two long tangents (with perhaps a spiral at each end
to ease the forces around the arc) has always been greatest delight. I
always enjoyed my CoGo (Coordinate Geometry) to work with objects such as
curves and straight lines exclusively. It is compact to store the data as
tangent and arc, true to the geometry of the object. While computing the
geometry that is the way it should be done and stored, but when drawing it
on the map, I had to do the unthinkable act of approximating the data. So, I
ask how many things are true arcs on the physical world (that includes
computer graphics, I think it has become physical already.)? Have we been
able to construct perfect arcs? Do we not still use approximation even when
we put our designs on the ground?

I think making the code as easy to read and modify with simpler objects may
be best. If it would take too much reengineering to modify MapServer, I
think that effort may spent elsewhere. Let the Engineers keep that
information whether an object is an arc of such radius. As long as the curve
fitting is done appropriately it should suffice to keep the details in an
attribute table.

What do you think?

Maaza

-----Original Message-----
From: mapserver-dev-bounces at lists.osgeo.org
[mailto:mapserver-dev-bounces at lists.osgeo.org] On Behalf Of thomas bonfort
Sent: Saturday, November 20, 2010 4:27 AM
To: Frank Warmerdam
Cc: mapserver-dev at lists.osgeo.org
Subject: Re: [mapserver-dev] PostGIS "curvepolygon" support

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