<pre>Re-visiting this one. There were a couple of comments from folks.<br><br>From Thomas(1) - <br>
> My first comment concerns layer-level geomtransforms: as in that case<br>> you are treating coordinates that are not in pixel space, do you plan<br>> addressing the case where the user actually wants a pixel space<br>
> operation. e.g. buffer(geom,3px)."<br><br>This does bring up an interesting problem, units in general, especially<br>when combined with projections. The original proposal had a transformation<br>being done before anything else, including projection. Data stored in lat/lon<br>
would be problematic I'd think so in many ways I think it would make sense to<br>project first and then transform. Any opinion?<br><br>In any case we'd probably need some sort of a units designator as Thomas suggests,<br>
at least for an operator like buffer. Probably as a third argument.<br><br>Pixel units could prove to be problematic from a query perspective since many<br>queries operating outside an image context.<br>
> My second comment addresses the current OFFSET keyword. With this<br>> addition, I think it could be dropped and be replaced by a<br>> geomtransform, thoughts?<br><br>This could actually be done now if we wanted at the style-level. At the layer<br>
level this would be invoked like a buffer, that is, with optional units. We<br>could let an OFFSET in a style set a geomtransform behind the scenes although<br>that could get messy if one were already defined for a style.<br>
<br>From Thomas(2) -<br><br>> One more...<br>> It might be usefull to have the geomtransform at the class level also,<br>> so that it applies to styles and labels in one pass.<br><br>Agreed. I'm not sure if this would be applied in the context of a query or<br>
not. I'd lean towards yes.<br><br>From Brent - <br><br>> 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...<br><br>We currently do expand the MBR used to search a dataset for candidate shapes.<br>I believe things like style sizes and width are used. In the case of a buffer<br>operator I'm thinking it will be impossible to derive a value to use in all<br>
cases. For example, I could see users wanting to compute or set a buffer distance<br>based on attribute values. In this case there would be no way to know the full<br>range of values ahead of time. (Note: this is true now with attribute binding<br>
for SIZE and WIDTH style values- there's a chance we could miss features.)<br><br>I'm thinking we should give users the ability to explicitly set an expansion<br>value (in a layer's units). This would override any computed expansion. This<br>
would probably manifest itself as a processing option.<br><br>Steve<br><br><br>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 <br>> buffer and difference to layer/label-levels. I think there could be some pretty neat uses for such functionality. <br>
> Should be online shortly at:
>
> <a href="http://www.mapserver.org/development/rfc/ms-rfc-72.html" target="_blank">http://www.mapserver.org/development/<span class="il">rfc</span>/ms-<span class="il">rfc</span>-<span class="il">72</span>.html</a>
>
> Comments welcome...
>
> Steve
> _______________________________________________
> mapserver-dev mailing list
> <a href="mailto:mapserver-dev@lists.osgeo.org" target="_blank">mapserver-dev@lists.osgeo.org</a>
> <a href="http://lists.osgeo.org/mailman/listinfo/mapserver-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/mapserver-dev</a>
>
</pre>