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

[Tamas Szekeres]

2008/11/10 thomas bonfort <thomas.bonfort at gmail.com>:
> 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 ?
>

I'd vote to #1 as well.

Best regards,

Tamas