MS RFC 22a: Feature cache for long running processes and query processing (update)

[Steve Lime]

There aren't geoprocessing capabilities (other than a few distance and intersection detection
functions necessary to support queries) elsewhere besides GEOS. The bufferPolyline function
is cartoline only and should be used elsewhere. The file mapscript/swiginc/shape.i contains all
those operators and you can see where I felt comfortable falling back on non-GEOS code.

I would support a 'fromWKT' capability and let it output shapeObj's. Within layer processing everything
is a shapeObj already.

Steve

>>> On 6/26/2007 at 6:17 PM, in message
<f3b73b7d0706261617j316f3698qdc1ce00ab765dd9e at mail.gmail.com>, Tamas Szekeres
<szekerest at GMAIL.COM> wrote:
> 2007/6/26, Steve Lime <Steve.Lime at dnr.state.mn.us>:
>> Re: 2), yes, I like the idea of geometry expressions. The expression syntax 
> probably could
>> be extended to operate on a shape (e.g. buffer(centroid(this), 10)). Don't 
> know how well
>> that fits with the nested layer concept though. It would probably make more 
> sense as a
>> single layer parameter, e.g.:
>>
>>  GEOPROCESS 'buffer(centroid(this), 10)'
>>
> 
> Steve,
> 
> Since I'm also impressed by the idea I'll be trying to implement a
> simple evaluator for the geometry expressions. May I consider we'll
> either restrict to the geometry objects to shapeObj-s or introduce a
> shapefrompoint style type converters in addition? However I'm not
> totally sure how the existing buffer operation works with the point
> shapes.
> 
> I'm also confused about the various implementations of the same
> operations along with mapserver (like msGEOSBuffer, bufferPolyline)
> which ones should be used in a particular case?
> 
> Best regards,
> 
> Tamas