OGR/WKT

[Steve Lime]

Regarding the API, I guess I'm torn. The GEOS stuff returns shapeObj like the code
Frank proposed - works well for MapScript-type use. May actually cause a problem
if GEOS processing is introduced inline within msLayerNextShape or msLayerGetShape.
That's another problem though (probably just need to copy the GEOS'd shapeObj
into the existing shapeObj and trash the original)...

The WKT processing will be used in two places:

  1-  MapScript, which actually prefers the shapeObj be created elsewhere from scratch

  2 - creating inline features via MapFiles or URLs, and creating the shapeObj in the WKT
       function should work fine. Code would be like:

  tempShape = msShapeFromWKT(yytext);
  insertFeatureList(list, shape);
  msFreeShape(shape);
  free(shape);

So, I'd propose using:

  shapeObj *msShapeFromWKT( const char * );
  char *msShapeToWKT( shapeObj * );

A longer term design goal then might be to move away from the existing shapeObj's way 
of doing things. Would touch a lot of code but would not be that hard to do, and would
merge the MapScript / MapServer C API worlds much better.

Steve

>>> Frank Warmerdam <fwarmerdam at GMAIL.COM> 08/05/05 2:59 PM >>>

... SNIP ...

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 * ); 

Is that right?  

Also, I think you should be fairly specific in how such a function
works.  For instance, mentioning that it initializes the attribute list 
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. 

.... SNIP ...