Ben Caradoc-Davies ha scritto:
> 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.
I did try to run the above on my Oracle XE and that did return null.
However I tried the example from an online documentation I've found:
(http://youngcow.net/doc/oracle10g/appdev.102/b14255/sdo_cs_ref.htm#CHDIEJHH)
SELECT SDO_CS.MAP_ORACLE_SRID_TO_EPSG(82361) FROM DUAL;
Btw, I did double check the contents of 8311 and they are definitely
_not_ equivalent to 4326.
The correct equivalent code for 8311 is EPSG:4283, defined as:
GEOGCS["GDA94",
DATUM["Geocentric Datum of Australia 1994",
SPHEROID["GRS 1980", 6378137.0, 298.257222101,
AUTHORITY["EPSG","7019"]],
TOWGS84[0.0, 0.0, 0.0, 0.0, 0.0, 0.0, 0.0],
AUTHORITY["EPSG","6283"]],
PRIMEM["Greenwich", 0.0, AUTHORITY["EPSG","8901"]],
UNIT["degree", 0.017453292519943295],
AXIS["Geodetic longitude", EAST],
AXIS["Geodetic latitude", NORTH],
AUTHORITY["EPSG","4283"]]
Compare the above with the 8311 definition in the Oracle db:
GEOGCS [ "Longitude / Latitude (GDA 94)", DATUM ["GDA 94", SPHEROID
["GRS 80", 6378137, 298.257222101]], PRIMEM [ "Greenwich", 0.000000 ],
UNIT ["Decimal Degree", 0.01745329251994330]]
See the spheroid? WGS84 uses a different one.
> 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?
So,
in the past we attempted to parse the Oracle WKT, but that failed
miserably for two reasons.
Oracle is not using a valid WKT syntax, they made their own variant.
We made the WKT parser lenient to the Oracle syntax just to discover
the second issue, which is that Oracle is also using invalid projection
names, e.g:
select SDO_CS.TO_OGC_SIMPLEFEATURE_SRS(wktext) FROM MDSYS.SDO_CS_SRS
where srid = 32632
PROJCS["WGS 84 / UTM zone 32N", GEOGCS [ "WGS 84", DATUM ["World
Geodetic System 1984 (EPSG ID 6326)", SPHEROID ["WGS 84 (EPSG ID 7030)",
6378137, 298.257223563]], PRIMEM [ "Greenwich", 0.000000 ], UNIT
["Decimal Degree", 0.01745329251994328]], PROJECTION ["UTM zone 32N
(EPSG OP 16032)"], PARAMETER ["Latitude_Of_Origin", 0], PARAMETER
["Central_Meridian", 9], PARAMETER ["Scale_Factor", .9996], PARAMETER
["False_Easting", 500000], PARAMETER ["False_Northing", 0], UNIT
["Meter", 1]]
where the projection name should simply be "Transverse Mercator".
I see no easy way to perform a mapping either.
I guess it should be possible to query all of the MDSYS tables
making up the definition of a SRS and building the CRS piecewise,
though that does not look like and easy solution.
Soo.. I don't see an easy solution. If you like we can try harder
using SDO_CS.MAP_ORACLE_SRID_TO_EPSG, though as I've reported
it does not work for me on the obvious case of the 4326 Oracle
alias...
Cheers
Andrea
--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.
------------------------------------------------------------------------------
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
