Hi Rini:
> Ideally, the filter should be unmapped first to its simple feature form, eg.
>
> Query:
> feature type: CGI_TermValue
> filter: [ gml:name = significant ]
> [properties: ALL ]
>
> Unmapped to this:
>
> Query:
> feature type: CGITermValue
> filter: [ strTrim([getID()]) = significant ]
> [properties: ALL ]
I do not understand the two forms; gml:name was always just a
convention - do you have a name attribute or not? I assume getID() is
accessing the feature id - that should be valid for simple feature or
rich feature.
> Then there's no problem. However, in my case, I don't have the simple
> features, as the complex features are adapted from a web service.
> So I have to filter the complex attribute directly.
The filter implementation (actually the expression implementation)
should be enough isolation for you. There are property accessors that
are able to rip data out of simple feature; rich feature; complex
attrbutes, java maps, java beans, and so on ... that should be all you
need for complex attribute support.
> The value returned is the value collection of the complex attribute, which
> when compared to the string value, would return false.
I see - evaluating is getting you an Attribute rather than a raw
value? Or a collection in this case to account for multiplicitly; we
have not really defined how filter / expression works when faced with
multiplicity - you could treat it as a collection; or do an AND on all
the members of the collection.
> In FilterAbstract, there's this hack:
>
> protected Object eval(org.opengis.filter.expression.Expression expression,
> Object object) {
> if( expression == null ) return null;
> Object value = expression.evaluate( object );
> //HACK as this method is used internally for filter
> //evaluation comparisons, etc, they work over the
> //contents (i.e. comparing an attexpresion with a literal)
> //so, lacking a better way of doing so, I'm putting this
> //check here
> if(value instanceof org.opengis.feature.Attribute){
> value = ((org.opengis.feature.Attribute)value).getValue();
> }
> return value;
> }
>
> I was tempted to modify this hack to get the complex attribute value, but it
> felt wrong.
> Instead, I added a new converter to retrieve the complex attribute value
> (only if the type has no attributes, ie. Simple content).
That sounds fine; this is for the case where you have both XML
attributes and XML elements I guess?
> I'm not sure if this is a good solution, but I can't think of anything else.
> Opinions?
You may consider reviewing the PropertyAccessor for complex
attributes; at worst we could consider an API change to determine if
one value or many is expected.
Have you thought about how to handle filters with multiplicity much
yet? Or is that the next problem.
Jody
------------------------------------------------------------------------------
OpenSolaris 2009.06 is a cutting edge operating system for enterprises
looking to deploy the next generation of Solaris that includes the latest
innovations from Sun and the OpenSource community. Download a copy and
enjoy capabilities such as Networking, Storage and Virtualization.
Go to: http://p.sf.net/sfu/opensolaris-get
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
