>
> The negative feedback was based on intent of the change; which had some
>> open unresolved issues (we do not know if it is possible with out some
>> thinking).
>>
>
> Not being standard was cited as one of the reasons against it. Read the
> mail again.
I am fine being a superset of the standard (ie more representative) I do not
want to be less representative.
>
> Sounds like Andrea and I are going to work through that and either accept
>> the change; or rollback the symbolizer to just be PropertyName. What we have
>> right now is inconsistent and that does nobody any good.
>>
>
> But now it is a String, so there is nothing to roll back (unless
> you want to turn that from String to PropertyName). Look in the
> GeoApi Symbolizer interface:
>
> String getGeometryPropertyName();
>
> If we go on with the change that will need to be changed to Expression.
> Another possible solution is to add a method:
>
> Expression getGeometryExpression()
>
> only in the GeoTools implementations.
This would be in keeping with what was done for expression; I have already
committed a method (in commented out form) to the Symbolizer interface in
order to talk about this possibility.
I would like at a minimum to see the use of PropertyName here; Expression
would be even better so we could use Expression.NIL rather than null.
Opening the door to Function has a host of consequences that I would like to
go through and determine if it is a good idea.
The uses we have thought of so far seem to be catered to by the SE 1.1
changes; and there is a good argument for staying the course with this
design (ie add to the symbolizers rather than preprocess the geometry) - the
argument being that the renderer is in a better position to perform the
right query taking into account the steps that will be applied to the
geometry (say an offset expressed in meters). The downside is that this
approach is not very open ended.
It also strikes me that we could set up a chain of FeatureSource to express
the idea of processing the geometry (this would explicitly process the
bounds; and the geometry) and be a nice separation of concerns from the
rendering process.
The difficulty here is of course how to express that in an SLD document (and
if that is even a good idea). There is precedence for hacking data into an
SLD document; both inline GML and the definition of new layers based on
external WFS resources has been ventured (and even placed into the standard)
previously. This discussion we are having offers a similar motivation to the
reason for those ideas.
In anycase that is a bunch of background; the idea of adding a Function is
nice open ended and makes sense; it *does* describe up front what will be
done to the geometry; in a format that is much more accessible then defining
some kind of FeatureSource chain.
If I was implementing this (I know we talked about processing the bounds and
stuff) - I may even implement this as a FeatureSource chain; similar to how
the getView method is implemented.
Code that is not ready to deal with the new method will just get a null
> property name, which
> is valid, and will lead the renderer to use the default geometry.
Yep; this is as I have documented it for Expression; and what I have
proposed to the geoapi list. However talking this over with you is what I
would like to make the decision based on.
Jody
------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
