Hi Jody,

Thank you for your quick response.  
In app-schema data access, you'd have a simple feature data store, which is 
mapped into the complex feature data access.
When filters are run, the complex attribute form (eg. Gml:name) would then be 
unmapped to the simple feature expression (ie. The column name or id expression 
mapped in the config file). The filters would then be applied on the simple 
features.

In my case however, the data access is not an app-schema one, and doesn't have 
simple features, therefore cannot be unmapped.
When I run filters on these features, I would get the attribute, instead of the 
raw value. 
Good point with multiplicity. While an AttributeImpl would have a value object, 
ComplexAttribute value would be a collection (as you can have multiple 
instances). However, they're not used that way, eg. Instead of having:
Gsml:specification/gsml:GeologicUnit[1]
Gsml:specification/gsml:GeologicUnit[2]

The way they're used is by having multiple instances of the multi-valued 
property, with a single value each, eg.
Gsml:specification[1]/gsml:GeologicUnit
Gsml:specification[2]/gsml:GeologicUnit

You can specify the index when querying, eg. 
> Query:
>   feature type: CGI_TermValue
>   filter: [ gml:name[2] = significant ]
>   [properties:  ALL ]

Therefore, my converter would only retrieve the first (and assumed only) value 
from the attribute. 
I don't know if multiplicity would ever be needed.. Perhaps we'll update that 
when required.
While you're at it, I submitted a patch and would appreciate it if you can take 
a look :)
http://jira.codehaus.org/browse/GEOT-2528

Cheers

Rini

-----Original Message-----
From: Jody Garnett [mailto:[email protected]] 
Sent: Wednesday, 3 June 2009 5:11 PM
To: Angreani, Rini (E&M, Kensington)
Cc: [email protected]
Subject: Re: [Geotools-devel] Filtering complex attribute value

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

Reply via email to