From: Håvard N. <hav...@ge...> - 2011-09-28 07:34:18
|
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 |