Derrick is still waiting on a response to this Oracle problem:
In a nutshell, MDSYS.USER_SDO_GEOM_METADATA can have both EPSG codes and
Oracle SRIDs in the SRID column. This can cause the first attempt to
resolve the code to fail, and Derrick wants your suggestion as to the
correct behaviour, so he can craft a patch. See below.
Kind regards,
Ben.
-------- Original Message --------
Subject: [ExternalEmail] [Geotools-devel] Query -
org.geotools.referencing.factory.AbstractAuthorityFactory
Date: Mon, 17 May 2010 18:12:50 +0800
From: derrick.w...@csiro.au <derrick.w...@csiro.au>
To: geotools-devel@lists.sourceforge.net
<geotools-devel@lists.sourceforge.net>
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
--
Ben Caradoc-Davies <ben.caradoc-dav...@csiro.au>
Software Engineering Team Leader
CSIRO Earth Science and Resource Engineering
Australian Resources Research Centre
------------------------------------------------------------------------------
ThinkGeek and WIRED's GeekDad team up for the Ultimate
GeekDad Father's Day Giveaway. ONE MASSIVE PRIZE to the
lucky parental unit. See the prize list and enter to win:
http://p.sf.net/sfu/thinkgeek-promo
_______________________________________________
Geotools-devel mailing list
Geotools-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geotools-devel
