Hi again To make it a little more interesting: if I don't supply any AXIS information in the WKT, then CRS.parseWKT(wkt) creates those for me. But it creates it in the Longitude,Latitude order, which CRS.lookupEpsgCode does not understand.
(by the away, I AM using the epsg-hsql jar, of course..) So, what I am saying is that if I leave out the following lines from the DATUM definition: AXIS["Geodetic longitude", EAST], AXIS["Geodetic latitude", NORTH], Then the Parser creates those in that order, but the lookup query on the Hsql database seems to expect the opposite order for that same CRS and finds nothing. Weird.. I noted that this only happens for ProjectedCRS's. When I do that same with a normal GeographicCRS, the lookup code is able to switch the axis order and find out the correct code. This seems to have something to do with how IdentifiedObjectFinder.deriveEquivalent() works (which I am not yet familiar with) Anyway, still investigating what's going on, and appreciating any help.. Milton Milton Jonathan wrote: > Hi there > > Once again, the axis issue attacked me :P. I guess this may have > something to do with changes from 2.5.x to 2.6.x (has LONGITUDE_FIRST > become the default now?). > > The situation is like this: I have a (valid) WKT generated for a > Projected CRS with longitude first (it is a SouthAmericanDatum1969 with > a UTM projection). When I try to lookup its epsg code, it tries, tries, > and fails. But it fails due to the axis order of the DATUM (i.e., not > due to the projected part). > > To illustrate, here goes the code that fails: > > String wkt = "PROJCS[\"SAD69 / UTM zone 23S\"," + > "GEOGCS[\"SAD69\"," + > "DATUM[\"South American Datum 1969\"," + > "SPHEROID[\"GRS 1967 (SAD69)\", 6378160.0, 298.25, > AUTHORITY[\"EPSG\",\"7050\"]]," + > "TOWGS84[-66.87, 4.37, -38.52, 0.0, 0.0, 0.0, 0.0]," + > "AUTHORITY[\"EPSG\",\"6618\"]]," + > "PRIMEM[\"Greenwich\", 0.0, AUTHORITY[\"EPSG\",\"8901\"]]," + > "UNIT[\"degree\", 0.017453292519943295]," + > "AXIS[\"Geodetic longitude\", EAST]," + > "AXIS[\"Geodetic latitude\", NORTH]," + > "AUTHORITY[\"EPSG\",\"4618\"]]," + > "PROJECTION[\"Transverse Mercator\", AUTHORITY[\"EPSG\",\"9807\"]]," + > "PARAMETER[\"central_meridian\", -45.0]," + > "PARAMETER[\"latitude_of_origin\", 0.0]," + > "PARAMETER[\"scale_factor\", 0.9996]," + > "PARAMETER[\"false_easting\", 500000.0]," + > "PARAMETER[\"false_northing\", 10000000.0]," + > "UNIT[\"m\", 1.0]," + > "AXIS[\"Easting\", EAST]," + > "AXIS[\"Northing\", NORTH]]"; > > CoordinateReferenceSystem crs = CRS.parseWKT(wkt); > Integer srid = CRS.lookupEpsgCode(crs, true); > > > You may notice that all axes are in the (x,y) order. > > The failure occurs due to the axis definitions inside the DATUM tag. If > I change the WKT and put "Geodetic latitude" before "Geodetic longitude" > the lookup works, but like this it fails. And that's quite odd since > when I debug it I see it IS using the so-called LongitudeFirstFactory. > > Does anyone know why this is working this way? I was hoping that setting > the FORCE_LONGITUDE_FIRST hint and using everything with longitude first > would prevent me from getting this kind of failure.. (actually, it seems > to be using LongitudeFirstFactory by default now, so I guess the hint is > unnecessary these days) > > Any help appreciated! > > Cheers > Milton > -- Milton Jonathan Grupo GIS e Meio Ambiente Tecgraf/PUC-Rio Tel: +55-21-3527-2502 ------------------------------------------------------------------------------ _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
