On Mon, 2011-09-19 at 16:05 +0200, Andrea Aime wrote:

> 
> The requirement that a property used in the SLD has to be there seems
> obvious to me,
> it's like asking why a column has to be there if it's used in a sql query.
> The GeoTools code is written so that it should work if the attribute
> is known, but its
> value is null, but does not work if you don't follow the expected structure.
> This is done primarily to inform people about typos in their SLD (a
> very common error,
> people flooded us with complaints that GeoTools/GeoServer were not working
> just because they mistyped or used the wrong case in attribute names).


First of all - thank you for a quick response:)

I see your point, but sort of disagree. I guess it depends on how one
look at it. 

If you get a "filter hit" on a feature, it's obvious that the feature
should contain all properties used in that exact rule.
 But I really don't understand why the renderer complaints when this
rule contains properties which is missing 
in some other feature (not handled by this rule).


> 
> We don't have a way to deal with data whose structure varies between one 
> feature
> and the next at the moment.
> I guess we could add a flag to avoid those basic validity checks that are 
> making
> it throw an exception.
> 
> I don't have unstructured data handy though, patches welcomed :-)
> 
> Cheers
> Andrea
> 



A lot of what we're doing involves FeatureCollections where the features
has small variations in the properties. 
I ended up "normalizing" the feature collection by fetching all the
properties expected from the SLD, and then
create a new FeatureCollection where I make sure that every feature
contains *at least* the properties from the 
SLD (setting their values to empty strings or 0).  Then I send this new
FeatureCollection to the renderer. It's not
nice, but it works :)


Regards
Håvard




------------------------------------------------------------------------------
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Reply via email to