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

[Steve Lime]

> I don't think you can just have a function that returns a modified
> shapeobj, as the processing of the transformation is already done
> inside the drawshape function (if I understand correctly, you meant
> calling the transfromation function *before* passing over to
> drawShape).

No, I was thinking of calling in drawShape. You almost have to don't you?
Since transformations happen within a style you'd have to transform
as you process the styles which is in the drawShape function. Actually you
could cache them there if necessary. I can see a situation where you'd
draw a polygon with several styles and then it's bbox with another all
in the same layer. Those shapes would have all have to exist within
drawShape.

Later, if we implement the geometrytransform at the layer level then you'd 
transform *before* calling drawShape.

Steve

>>> "thomas bonfort" <thomas.bonfort at gmail.com> 12/03/08 3:59 AM >>>
Hi, thanks for the feedback Steve,

>
>I have these suggestions:
>
> - we only support simple transformations (as proposed with the original TYPE keyword)
>
> That should ease initial implementation since you'd only have to do so simple string
> compares and no evaluation. If that code can be in it's own function, something like
> msProcessGeometryTransform() and we support the syntax in the RFC then there's
> plenty of room for expansion. That function could return a shapeObj to be used in place
> of the source shapeObj.

I don't think you can just have a function that returns a modified
shapeobj, as the processing of the transformation is already done
inside the drawshape function (if I understand correctly, you meant
calling the transfromation function *before* passing over to
drawShape).
Plus in this case, what is important is to conserve the proper
orientation for the rendered point, by using the surrounding points.
This would mean having to hack in the angle into the corresponding
styleObj.

>
>  - syntax should use [geom] instead of plain geom in keeping with expression syntax
ok

>
>   - how about a labelpoint transform?
that could easily be added by extending the geomtransform parser

>
>   Kinda like centroid but uses the label point code to create the point (as a shapeObj). This
>   might allow us to ditch ANNOTATION layers eventually. There are implementation issues
>   with replacing ANNOTATION though so I'd just look at it as another way to create a point
>   from a shapeObj for now.
>
>   One thing that's missing, but I don't know how to address is multiple styles that would
>   share the same GEOMETRYTRANSFORM. Seems a shame to have to compute it for
>   every style that needs it. Perhaps that's too much for this RFC as what's proposed would
>   be pretty sweet.
maybe that could be added by adding a shapeObj cache member in the
styleObj. the transformations themselves are pretty lightweight so I'd
also say this is rather low priority for now.


I've updated rfc48 (now here
http://trac.osgeo.org/mapserver/browser/trunk/docs/development/rfc/ms-rfc-48.txt)
to add the two following modifications:
 * the styleObj will be modified to support ANGLE AUTO (necessary so
start/end and vertices transforms can orient the resulting marker
along the line direction). This should probably be used later on to
remove the current behavior that uses a negative GAP to specify the
same behavior for marker symbols.
 * for line layers, styles with a geomtransform cannot use the caching
mechanism that's in place. They will be drawn in the first pass, along
with the first style of the corresponding class.

I'd like to call for vote on this rfc tomorrow, so please chime in
before that if you have any comments.

thanks,
thomas