Hi all, I know most you guys are busy with the release of the new version of Geotools, but I was wondering if someone can have a quick look at my issue?
Thank you for your time, Regards, Derrick -----Original Message----- From: derrick.w...@csiro.au [mailto:derrick.w...@csiro.au] Sent: Monday, 17 May 2010 6:13 PM To: geotools-devel@lists.sourceforge.net Subject: [ExternalEmail] [Geotools-devel] Query - org.geotools.referencing.factory.AbstractAuthorityFactory 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: geotools-devel@lists.sourceforge.net 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:jody.garn...@gmail.com] Sent: Monday, 3 May 2010 3:36 PM To: Wong, Derrick (CESRE, Kensington) Cc: geotools-devel@lists.sourceforge.net 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, <derrick.w...@csiro.au> <derrick.w...@csiro.au> 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 Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list Geotools-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/geotools-devel
