Ben Caradoc-Davies ha scritto: > On 15/06/10 13:27, [email protected] wrote: >> With regards to EPSG: 23038. > > The canonical source for EPSG codes is here: > http://epsg-registry.org/ > > This also lists 23038.
Right, it's also in the EPSG database, I must have mistyped the code when I searched for it: http://demo.opengeo.org/geoserver/web/?wicket:bookmarkablePage=:org.geoserver.web.demo.SRSDescriptionPage&code=EPSG:23038 Anyways, the basic issue remains. That function is not reliable in all versions of Oracle, and if it's returning 4326 as the mapping for 8311 it is simply wrong, as the right mapping is 4238 instead The only sane way I can imagine to get proper CoordinateReferenceSystem objects out of Oracle is to query all the various tables and build the CRS representation in memory by assembling all the required params. Which is going to take significant time to do as there is quite a variety of situations and params to consider. Once that is done you might still have to start adding aliases for all the projection params and projection names that Oracle is getting wrong. Or.. maybe it is possible to do just some light text processing and querying (we would be headed straight for hack-a-landia but anyways...), the 32632 wkt definition I cited in the previous mails could not be decoded due to its usage of wrong term in the projection name. The original one is: 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]] The following one could be parsed though (just changed the projection name): 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 ["Transverse Mercator"], PARAMETER ["Latitude_Of_Origin", 0], PARAMETER ["Central_Meridian", 9], PARAMETER ["Scale_Factor", .9996], PARAMETER ["False_Easting", 500000], PARAMETER ["False_Northing", 0], UNIT ["Meter", 1]] However it could still not be matched to an official EPSG code by CRS.lookupEPSGCode(crs, true) due to differences in the datum and spheroid names. Further massaging led to a representation that could be matched 1-1 with the official EPSG code (changed the datum and spheroid names to remove the PROJCS["WGS 84 / UTM zone 32N", GEOGCS [ "WGS 84", DATUM ["World Geodetic System 1984", SPHEROID ["WGS 84", 6378137, 298.257223563]], PRIMEM [ "Greenwich", 0.000000 ], UNIT ["Decimal Degree", 0.01745329251994328]], PROJECTION ["Transverse Mercator"], PARAMETER ["Latitude_Of_Origin", 0], PARAMETER ["Central_Meridian", 9], PARAMETER ["Scale_Factor", .9996], PARAMETER ["False_Easting", 500000], PARAMETER ["False_Northing", 0], UNIT ["Meter", 1]] Now, not sure this kind of text massaging is a good idea, but if you want to try that way it might be good to look into the WKTParser and make one that does not build a CRS, but acts as a filter instead (regexp might work too, but not sure you'd get enough control to make it work in general). 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 [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
