[mapserver-dev] RFC 72: Adding GEOMTRANSFORM to Layer/Label Objects

[Steve Lime]

Re-visiting this one. There were a couple of comments from folks.

>From Thomas(1) -

> My first comment concerns layer-level geomtransforms: as in that case
> you are treating coordinates that are not in pixel space, do you plan
> addressing the case where the user actually wants a pixel space
> operation. e.g. buffer(geom,3px)."

This does bring up an interesting problem, units in general, especially
when combined with projections. The original proposal had a transformation
being done before anything else, including projection. Data stored in lat/lon
would be problematic I'd think so in many ways I think it would make sense to
project first and then transform. Any opinion?

In any case we'd probably need some sort of a units designator as
Thomas suggests,
at least for an operator like buffer. Probably as a third argument.

Pixel units could prove to be problematic from a query perspective since many
queries operating outside an image context.

> My second comment addresses the current OFFSET keyword. With this
> addition, I think it could be dropped and be replaced by a
> geomtransform, thoughts?

This could actually be done now if we wanted at the style-level. At the layer
level this would be invoked like a buffer, that is, with optional units. We
could let an OFFSET in a style set a geomtransform behind the scenes although
that could get messy if one were already defined for a style.

>From Thomas(2) -

> One more...
> It might be usefull to have the geomtransform at the class level also,
> so that it applies to styles and labels in one pass.

Agreed. I'm not sure if this would be applied in the context of a query or
not. I'd lean towards yes.

>From Brent -

> Performance could be a problem when requesting features from a large
> datastore since the spatial filter needs to be applied to the buffered
> feature.  Perhaps expanding the MBR of the spatial fliter by the buffer
> value would be a solution...

We currently do expand the MBR used to search a dataset for candidate shapes.
I believe things like style sizes and width are used. In the case of a buffer
operator I'm thinking it will be impossible to derive a value to use in all
cases. For example, I could see users wanting to compute or set a
buffer distance
based on attribute values. In this case there would be no way to know the full
range of values ahead of time. (Note: this is true now with attribute binding
for SIZE and WIDTH style values- there's a chance we could miss features.)

I'm thinking we should give users the ability to explicitly set an expansion
value (in a layer's units). This would override any computed expansion. This
would probably manifest itself as a processing option.

Steve


On 6/29/2011 10:21 PM, Lime, Steve D (DNR) wrote:
> Hi All: I've started work on a proposal to extend logical expressions that include GEOS operators like
> buffer and difference to layer/label-levels. I think there could be some pretty neat uses for such functionality.
> Should be online shortly at:
>
>    http://www.mapserver.org/development/rfc/ms-rfc-72.html
>
> Comments welcome...
>
> Steve
> _______________________________________________
> mapserver-dev mailing list
> mapserver-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/mapserver-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/mapserver-dev/attachments/20110724/9dc091f3/attachment.html