OGR/WKT

[Sean Gillies]

Hi Steve,

My $.02 ...

I'd prefer msShape* for the new C functions, to collect them into a  
conceptual "Shape" module.

As for mapscript: I've already implemented toString() methods for  
pointObj and rectObj which return a dictionary-ish string, so I think  
the WKT string should be produced instead by a toWKT() method.

Is there any chance you would be interested in writing unit tests for  
these new methods? Whether they know it or not, mapscript users have  
benefited from the tests that I, Howard, and Frank have written, and it  
would be good to continue them. If mapscript development were to switch  
back to being primarily Perl-focussed, Perl tests could be written.

Sean

On Aug 5, 2005, at 3:44 PM, Steve Lime wrote:

> Don't worry about being and a-hole. It's important to get the level of  
> =
> detail correct
> for future RFC's. Is the public API all you were looking for or  
> perhaps =
> more?
>
> Your description of the API is what I had in mind, but I'll have to  
> look =
> around the rest
> of the code to see how shapes are created. This API is works well with  
> =
> MapScript.
> Working with basic shapes should not be an issue since that's what we  
> do =
> all the=20
> time via MapScript. It's quite common to have shapes without  
> attributes. =
> The=20
> GEOS and OGR interfaces would be named similarly but with OGR and GEOS  
> =
> as=20
> prefixes, after the ms (e.g. msGEOSShapeToWKT).
>
> Steve
>
>>>> Frank Warmerdam <fwarmerdam at GMAIL.COM> 08/05/05 2:59 PM >>>
> On 8/5/05, Steve Lime <steve.lime at dnr.state.mn.us> wrote:
>> I've added a few more comments as well talking about:
>> =20
>>  - support for both reading AND writing
>>  - the addition of a "toString" method to shapeObj's in MapScript
>>  - leveraging both OGR and GEOS, with a public WKT API that wraps  
>> access =
> to those
>>  - adding "-wkt" as a option to the [shpxy ...] tag in MapServer  
>> query =
> templates
>
> Steve,
>
> I was still hoping to see the public API entry points that will
> go into mapprimitive.c defined explicitly.  I would assume something
> like:
>
>    shapeObj *msShapeFromWKT( const char * );
>
> and
>
>    char *msShapeToWKT( shapeObj * );=20
>
> Is that right? =20
>
> Also, I think you should be fairly specific in how such a function
> works.  For instance, mentioning that it initializes the attribute  
> list=20
> to an empty list and that the index, tileindex, classindex will be
> all zero, and text NULL.  I am wondering if there are any effects
> to be concerned about from that.
>
> Also, I have assumed in my above proposal that new shapeObj's
> would be allocated by the function but that is not actually how
> most shapeObj operators work now I think.  Instead most initialize
> an existing shapeObj.=20
>
>> Can we call for a vote at this point?
>
> As chair that is certainly within your perogitive.  In fact, I think  
> any
> proposer could do so at any point.=20
>
> At the risk of being a complete a--hole I will take the opportunity
> to vote -1 pending clarification of the public API. =20
> =20
>> (Also, where's the resting place for the RFC's. CVS or the website.  
>> If =
> CVS, then how
>> can the website be automatically updated?)
>
> There seems to be some ambiguity about which is primary and there
> is no automatic way to update both.  I would be happy enough to make
> the web site primary but to be honest these content management systems
> make me nervous.  I can just imagine a harddrive failure resulting the
> the material being gone forever and unrecoverable. =20
>
> Best regards,
> --=20
> --------------------------------------- 
> +-----------------------------------=
> ---
> I set the clouds in motion - turn up   | Frank Warmerdam,  
> warmerdam at pobox.c=
> om=20
> light and sound - activate the windows | http://pobox.com/~warmerdam=20
> and watch the world go round - Rush    | Geospatial Programmer for Rent
>