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

[thomas bonfort]

On Mon, Nov 10, 2008 at 15:11, Daniel Morissette
<dmorissette at mapgears.com> wrote:
> thomas bonfort wrote:
>>
>> the original intent of this rfc was to have something a bit more
>> generic than directly adding arrowhead support, so this is getting a
>> bit unwieldy  :)
>>
>
> Ha! I know that feeling!
>
> Guys, let's keep in mind that the simplicity of MapServer used to be its
> main advantage? Did we forget that "MapServer is not a full-featured GIS
> system, nor does it aspire to be"?
>
> While it may sound cool to perform a
> centroid(convexhull(buffer([geom],0.5))) in a style at rendering time, that
> remains a purely theoretical example with no application in real life as far
> as I can tell... BTW, do we also expect that a feature rendered after such a
> complex operation should be clickable (queryable) as well and how do we plan
> on managing that if all those operations are done only at rendering time in
> the style object and not in the data source where the query happens?
>
> If anyone needs that kind of fancy operation, I think they can afford to
> load their data in PostGIS and do the spatial operations in there instead of
> bloating MapServer with stuff that's of no use for 99% of the users... that
> will also solve the queryability issue.

thanks Daniel for putting us back on the tracks :)

>
> I'd say keep it simple and manageable in the time that you have available,
> and plan the mapfile changes/keywords so that they can be extended in the
> future if possible... that's what you've done so far I think.
>
> The RFC and future docs should also discuss the impact of the use of
> geotransform on queries.

I hadn't considered the queries for this RFC, as the intent of it was
geared at styling. I guess that queries as a whole should be left
aside for as long as we stick to our "not a gis" motto.

as for the expression to be used, I'm wondering what syntax should be
used, with the long-term goal of being backwards-compatible if/when
nested expressions are added:

1) start(geometry) : "geometry" would be a reserved keyword
2) start([geometry]): this expresses that the geometry is an attribute
of the feature, but would collide with attribute binding
3) start() : will pose a problem for nested expressions, and for
passing options (eg buffer(5) ).

I'm in favor of no1, are there better possibilities ?

thomas