Hi all,
I have been investigating the Axis Order for Bounding Box specified in a WFS
spatial query for complex features and now I have managed to resolve some of
the issues I was having previously (previous emails).
Looking at the class org.geoserver.feature.ReprojectingFilterVistor class line
77 onwards:
public Object visit(BBOX filter, Object extraData) {
// if no srs is specified we can't transform anyways
String srs = filter.getSRS();
if (srs == null || "".equals(srs.trim()))
return super.visit(filter, extraData);
I was investigating why filter.getSRS() was returning null, and I have managed
to trace it back all the way to when the geoserver first starts and datastore
is being initialised.
Looking at org.geotools.jdbc.JDBCFeatureSrouce (line 297):
srid = dialect.getGeometrySRID(databaseSchema, tableName, name, cx);
The class attempts to obtain the srid from the database, and in a particular
instance, the srid returned was "8311".
Stepping through the code, the following exception is thrown:
org.opengis.referencing.NoSuchAuthorityCodeException: No code "EPSG:8311" from
authority "European Petroleum Survey Group" found for object of type
"IdentifiedObject".
Digging deeper, we get OracleDialect (line 491)
The StringBuffer builds the query to be made to the database, which on
debugging reveals:
SELECT SRID FROM MDSYS.USER_SDO_GEOM_METADATA WHERE
TABLE_NAME='GSML_MAPPEDFEATURE' AND COLUMN_NAME='SHAPE'
I had a look at the following view MDSYS.USER_SDO_GEOM_METADATA and there were
rows with valid EPSG codes, and others (like 8311) which were just plain srids
obtained from Geodetic Points.
I wasn't familiar with the SRID 8311, so I ran the following query "select
sdo_cs.map_oracle_srid_to_epsg (8311) from dual;". 8311 was just a srid to EPSG
4326.
The data belongs to the client, and I only have read access.
This leads to my question, should there be another check if we get the
following "NoSuchAuthorityCodeException", to see if the SRID can be converted
to a valid EPSG code?
Thank you for your time.
Regards,
Derrick
From: Wong, Derrick (CESRE, Kensington)
Sent: Wednesday, 5 May 2010 11:07 AM
To: 'Jody Garnett'
Cc: [email protected]
Subject: RE: [Geotools-devel] Geotool query - Differences in
SimpleFeaturePropertyAccessor and FeaturePropertyAccessorFactory
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]> <[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]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
------------------------------------------------------------------------------
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
