Hi Jody,

Thanks for your reply.

I had a further look into some other classes, and spotted a similar trend (e.g. 
org.geotools.filter.expression.FeaturePropertyAccessorFactory). Comparing them 
with similar classes written for Simple Features, I have made a  few changes 
and,  the axis ordering of the bbox in a WFS spatial query now behaves the same 
for Complex Features.

Once I am done testing and reviewing the changes, I will get Ben/Rini  to have 
a look at it.


Thank you once again.

Regards,

Derrick

From: Jody Garnett [mailto:[email protected]]
Sent: Monday, 3 May 2010 3:36 PM
To: Wong, Derrick (CESRE, Kensington)
Cc: [email protected]
Subject: Re: [Geotools-devel] Geotool query - Differences in 
SimpleFeaturePropertyAccessor and FeaturePropertyAccessorFactory

Hi Derrick!

Welcome to GeoTools development; one of the big tips is to jump on the IRC 
channel for "watercooler" style conversation; since you are hitting some deep 
issues it would be good to explore the problem with you.

The check of target == Geometry.class looks very ill advised (should use 
Geometry.class.isAssignableFrom( target ) for one).

I see no trouble removing the target test in the manner you described; the 
process is to submit a JIRA bug report (with a patch + test case if you want it 
acted on promptly). Chances are you know someone in your organisation who can 
apply the patch :-D

However we are into an interesting question: when no geometry is specified what 
is to be done?
- we would really really like to know the Geometry type so we can optimimze the 
rendering...
- so in the case of SimpleFeature we actually make that assumption..

However for the general case of "Feature" the cite tests were asking us to draw 
any and all geometries defined for the feature!
That is about all I remember of the discussion;  other then that look for aaime 
or jdeolive for the details (and IRC if you want to be efficient).

Jody


On 03/05/2010, at 1:24 PM, 
<[email protected]<mailto:[email protected]>> 
<[email protected]<mailto:[email protected]>> wrote:


Hi all,

I am a Software Engineer working on the Spatial Information Services Stack 
(SISS) project, focusing on some key issues we (CSIRO) are having with 
Geoserver within our use cases. I work closely with Ben Caradoc-Davies and Rini 
Angreani on a daily basis and will be looking forward to working you all.

I have been having a look at the Axis Order for Bounding Box specified in a WFS 
spatial query, and while writing some test cases, I have encountered the 
following problem which I am hoping someone can share some insight:

I have written a test class which extends 
org.geoserver.test.AbstractAppSchemaWfsTestSuport, when trying to obtain a 
org.w3c.dom.Document object by calling the method getAsDom(String path), if I 
specified the param "BBOX" in my WFS request, my Unit Test would fail 
(Exception attached) This only happens on complex features, which led me to the 
following 2 classes in particular.


org.geotools.filter.expression.SimpleFeaturePropertyAccessor line 67-68:


        //if ("".equals(xpath) && target == Geometry.class)
        if ("".equals(xpath))
            return DEFAULT_GEOMETRY_ACCESS;

I had a look into the repository and this change was made in geotools-trunk 
revision 26186. (jdeolive  10/07/2007 10:18:59 AM        GEOT-1372, feature 
model api changes in preparation for geoapi feature model implementation)

Comparing this with

org.geotools.filter.expression.FeaturePropertyAccessorFactory line 113-114:

   if ("".equals(xpath) && target == Geometry.class)
       return DEFAULT_GEOMETRY_ACCESS;


The method createPropertyAccessor for both classes are now different.  If I 
removed the check "target == Geometry.class", my unit test works, and I can see 
features in my Document object.

I am wondering if there will be any issues if I made both "if" statements 
similar.

Could someone kindly assist?

Thank you for your time.



Kind Regards,

Derrick Wong

------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[email protected]<mailto:[email protected]>
https://lists.sourceforge.net/lists/listinfo/geotools-devel

------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Reply via email to