[mapserver-dev] PostGIS "curvepolygon" support

[Jeff McKenna]

Hello Astrid,

I would also like to be involved in this implementation, in terms of 
testing and documenting the changes for MapServer users (as I am often 
the first MapServer user to try to compile and implement many changes 
from the devs, I see my role as very important in the MapServer 
development process).

And I have no problem helping you use a portion of that budget :)

-Jeff

PS. Frank your free work is killing me, ha.


On 10-11-09 7:28 AM, Paul Ramsey wrote:
> On Tue, Nov 9, 2010 at 1:46 AM, Astrid Emde<astrid.emde at wheregroup.com>  wrote:
>> I would favorite the solution b) to make the functionality generally
>> available.
>>
>> But just a question - we always will have the process of stroking PostGIS
>> curves which will be a performance leak. Am I right?
>
> Yes, but as Frank noted, not a particularly big performance leak.
>
>> 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.
>>
>> 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?
>
> Nope, we both suggested doing it in CONNECTIONTYPE POSTGIS, which is
> the right place in this case, IMO.
>
> Best,
>
> Paul
>
>> Paul Ramsey schrieb:
>>>
>>> Astrid,
>>>
>>> It would make sense to generally handle the curvey types in the run,
>>> including the compoundcurve and circularstring as forms of mapserver
>>> LINE types. I think your thread suggestion is correct (perhaps?) in
>>> that it would be "simplest" to just paper over the curve types in the
>>> postgis driver. This is in fact what is happening (sort of) in the
>>> Oracle driver already.
>>>
>>> The papering-over could take two forms.
>>>
>>> (a) We could change the SQL being send to PostGIS to ensure that
>>> curves are stroked (turned into equivalent linestrings) on the
>>> database side.
>>> (b) Or we could extract the stroking routines that have already been
>>> written in the Oracle driver to a globally accessible area, genericize
>>> them a little, and use them to stroke PostGIS curves in the MapServer
>>> code.
>>>
>>> The advantage of (b) is that the stroking routines would then be
>>> generically available to any other driver that needs to stroke curves.
>>> It would be a little more work than hacking up the SQL generated by
>>> the PostGIS driver to get the server to do the work of stroking.
>>>
>>> Does anyone else have interest in this issue?
>>>
>>> Paul
>>>
>>> On Mon, Nov 8, 2010 at 11:06 PM, Astrid Emde<astrid.emde at wheregroup.com>
>>> wrote:
>>>
>>>>
>>>> Hello devs,
>>>>
>>>> there was a discussion going on about PostGIS "curvepolygon" support for
>>>> MapServer. At the moment polygons without curves are
>>>> drawn, the ones with curves not.
>>>>
>>>> Here is the discussion link:
>>>>
>>>>
>>>> http://osgeo-org.1803224.n2.nabble.com/PostGIS-curvepolygon-support-tt5372049.html
>>>>
>>>> One of our customers would like to sponsor this implementation and would
>>>> like to know how much this enhancement would cost. It would be good if
>>>> you
>>>> could handle polygons and curevepolygons in one MapServer layer from TYPE
>>>> POLYGON.
>>>>
>>>> In the thread there was also the discussion about a solution which is
>>>> implemented in the PostGIS driver ...
>>>>
>>>>
>>>>>
>>>>>   Curiously could this mean adding to the PostGIS driver a means of
>>>>>   going from curve to shapeObj? As opposed to adding a curve shape
>>>>>   type within MapServer.
>>>>>
>>>>
>>>> Could you please discuss a possible solution and estimate the costs? Who
>>>> would be the contact person concerning this enhancement?
>>>>
>>>> Maybe there are other MapServer users interested in this enhancement and
>>>> would also sponsor the implementation.
>>>>
>>>> --
>>>>
>>>> Best regards
>>>> Astrid Emde
>>>>
>>>> ----------------------------------
>>>>
>>>> Aufwind durch Wissen!
>>>>
>>>> Qualifizierte OpenSource-Schulungen
>>>> bei der www.foss-academy.eu
>>>>
>>>> ----------------------------------
>>>>
>>>> Astrid Emde
>>>> WhereGroup GmbH&  Co.KG
>>>> Siemensstraße 8
>>>> 53121 Bonn
>>>> Germany
>>>>
>>>> Fon: +49(0)228 90 90 38 - 19
>>>> Fax: +49(0)228 90 90 38 - 11
>>>>
>>>> astrid.emde at wheregroup.com
>>>> www.wheregroup.com
>>>>
>>>> Amtsgericht Bonn, HRA 6788
>>>> -------------------------------
>>>> Komplementärin:
>>>> WhereGroup Verwaltungs GmbH
>>>> vertreten durch:
>>>> Olaf Knopp, Peter Stamm
>>>> -------------------------------
>>>>
>>>> _______________________________________________
>>>> mapserver-dev mailing list
>>>> mapserver-dev at lists.osgeo.org
>>>> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>>>>
>>>>
>>
>>
>> --
>>
>> Mit freundlichen Grüßen
>>
>> Astrid Emde
>>
>> ----------------------------------
>>
>> Aufwind durch Wissen!
>>
>> Qualifizierte OpenSource-Schulungen
>> bei der www.foss-academy.eu
>>
>> ----------------------------------
>>
>> Astrid Emde
>> WhereGroup GmbH&  Co.KG
>> Siemensstraße 8
>> 53121 Bonn
>> Germany
>>
>> Fon: +49(0)228 90 90 38 - 19
>> Fax: +49(0)228 90 90 38 - 11
>>
>> astrid.emde at wheregroup.com
>> www.wheregroup.com
>>
>> Amtsgericht Bonn, HRA 6788
>> -------------------------------
>> Komplementärin:
>> WhereGroup Verwaltungs GmbH
>> vertreten durch:
>> Olaf Knopp, Peter Stamm
>> -------------------------------
>>
>> _______________________________________________
>> 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
>


-- 
Jeff McKenna
MapServer Consulting and Training Services
http://www.gatewaygeomatics.com/