[mapserver-dev] ms rfc 48: adding a type keyword to the styleblock

[Steve Lime]

We might be able to extend the yacc grammar to accommodate geometry operations. I think we'd just need to
reference a shapeObj as a geoval in the mapparser.y. May make more sense to write a second grammar 
(mapgeoparser.y) but I think that's one good way to try it.

Steve

>>> On 11/6/2008 at 12:34 PM, in message
<d2b988930811061034p2e6a39f9k5bd5bd497f3197a at mail.gmail.com>, "thomas bonfort"
<thomas.bonfort at gmail.com> wrote:
> Tamas,
> 
> you're very right, adding only a single keyword is much better, and my
> impression is that there might be many other applications to the
> concept, so that's the way to go imo. It also solves the todos left in
> the rfc (buffer distance, and options for "vertices" keyword)
> I'll update the rfc accordingly.
> 
> Why do you want to add the "geom" argument to the expressions ?
> 
> as for the implementation, I don't feel upto writing a parser capable
> of understanding the more complex of your examples, but I guess that
> could be done in a second step while keeping the same global concept.
> 
> I'll also have a look at the implications and feasibility of adding
> the keyword to the layerobj.
> 
> thanks and cheers,
> 
> thomas
> 
> 
> On Thu, Nov 6, 2008 at 11:09, Tamas Szekeres <szekerest at gmail.com> wrote:
>> 2008/11/6 Steve Lime <Steve.Lime at dnr.state.mn.us>:
>>> When we first thought of style types it was limited to a couple simple 
> options
>>> (begin, end, labelpnt, bbox). Of course ideas grow and operations like 
> convex
>>> hulls or buffers sound doable. That immediately brings RFC 22 into my mind
>>> again. Tamas, how do you see this working with those ideas?
>>>
>>
>> Steve,
>>
>> This proposal provides a subset of what RFC 22 have been addressed.
>> However I like this idea because it's more lightweight, though it may
>> not support geometries from multiple features/layers in the
>> expressions and further options like feature caching regarding to the
>> queries is quite unrelated.
>>
>> Getting back to this idea, we could gain further improvements by
>> supporting the attribute bindings with these expressions, like for
>> example:
>>
>>  GEOMERTYEXPRESSION  "buffer(geom, [bufferattribute])"
>>
>> And again, I'd support adding this both to the STYLE and the LAYER sections.
>>
>> This member should also be exposed to the mapscript interface and it
>> would also be desirable to expose the transformation function as well
>> to be able to evaluate such expressions separately,like:
>>
>> shapeObj shape2 = layer.TransformGeometry(geoexpression, shape)
>>
>> Best regards,
>>
>> Tamas
>>
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org 
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev