OSGeo.org › OSGeo Software and Data Projects › GeoTools, the java GIS toolkit › geotools-devel

Axis problems again with CRS.lookupEpsgCode

8 messages

Axis problems again with CRS.lookupEpsgCode

Reply Threaded

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Milton Jonathan

Re: Axis problems again with CRS.lookupEpsgCode

Reply Threaded

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
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

aaime

Re: Axis problems again with CRS.lookupEpsgCode

Reply Threaded

In reply to this post by Milton Jonathan

Milton Jonathan ha scritto:

Milton, I just tried your code on my computer and the lookup
returns back 29193 for me, no matter how I set the
axis order hints (or even if I set them at all).

Full program attached. What am I missing?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

import org.geotools.referencing.CRS;
import org.opengis.referencing.crs.CoordinateReferenceSystem;

public class WktDecoder {
public static void main(String[] args) throws Exception {
// uncomment either of these, makes no difference
// GeoTools.init(new Hints(Hints.FORCE_LONGITUDE_FIRST_AXIS_ORDER, Boolean.TRUE));
// System.setProperty("org.geotools.referencing.forceXY", "true");

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);
System.out.println(crs);
Integer srid = CRS.lookupEpsgCode(crs, true);
System.out.println("Lookup result: " + srid);

System.out.println(CRS.decode("EPSG:29193"));
}
}

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Milton Jonathan

Re: Axis problems again with CRS.lookupEpsgCode

Reply Threaded

Hey Andrea

Thanks a lot for the feedback. I wish to apologize for not sending a new
e-mail yesterday with what I was finding out.

Turns out that, yeah, when I came back the next morning, this exact WKT
was working (but not the real one I'm getting in my system here). I must
have messed something up when I tested it before sending the e-mail,
really sorry for that, guess I was too tired.

But don't be completely mad at me, there are real issues going on. I was
waiting to send an e-mail with those issues sorted out, but, anyway,
let's talk about what I think at this moment.

1. The main issue seems to be how some referencing object comparisons
are made. I noticed that AbstractDatum.equals() compares Datums using
the Datum name if "compareMetadata" is false. That's kind of OK in
principle, but it doesn't even check if there are Identifiers present.
So, try running the WKT below, where I just changed the line
"DATUM[\"South American Datum 1969\"," to "DATUM[\"SAD69\"," (and please
shoot me if it works, I just tested *exactly* that one). Note that the
Datum does have an identifier stating it to be EPSG:6618.

String wkt = "PROJCS[\"SAD69 / UTM zone 23S\"," +
"GEOGCS[\"SAD69\"," +
"DATUM[\"SAD69\"," +
"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]]";

So, this one is not found, which sounds odd to me because it would mean
that WKTs generated by 3rd parties must know the exact Datum name used
in this particular epsg database. If that's really how it works, well,
then I'll have to fix it by hand before making the lookup.

1b. This issue has other consequences. Since many such object
comparisons seem to ignore the EPSG code, I have the following problem:
a WKT was generated where the numbers were printed with only a certain
level of precision, making the WGS84 SPHEROID's inverse flattening turn
from 298.257223563 to 298.2572. Again, I agree that if no EPSG code is
given, then it is a different SPHEROID. But when the code IS given, the
comparison still ignores it and says they are different. So, if I get
the WKT for 32723 (WGS84 UTM 23S) and simply exchange the spheroid's
flattening as above, it does not work either:

String wkt = "PROJCS[\"WGS 84 / UTM zone 23S\"," +
"GEOGCS[\"WGS 84\"," +
"DATUM[\"World Geodetic System 1984\"," +
"SPHEROID[\"WGS 84\", 6378137.0, 298.2572, AUTHORITY[\"EPSG\",\"7030\"]]," +
"AUTHORITY[\"EPSG\",\"6326\"]]," +
"PRIMEM[\"Greenwich\", 0.0, AUTHORITY[\"EPSG\",\"8901\"]]," +
"UNIT[\"degree\", 0.017453292519943295]," +
"AXIS[\"Geodetic latitude\", NORTH]," +
"AXIS[\"Geodetic longitude\", EAST]," +
"AUTHORITY[\"EPSG\",\"4326\"]]," +
"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]]";

What do you think? Should it work this way? My personal opinion is that
the identifiers should be checked always when available..

2. A smaller different issue may be related to that forceXY property you
have in your code. I guess it turns out that now a ProjectedCRS such as
these which specify "AXIS[\"x\", EAST]" and "AXIS[\"y\", NORTH]" instead
of "Easting" and "Northing" don't work? It looked like that in the axis
comparison code in DefaultCoordinateSystemAxis.equals(). But I tried to
set the property and it still didn't work (see WKT below). Am I missing
something? By the way, why is this not a hint, but a system property?
Oh, just to let you know: this isn't so much of an issue for me right
now, it's just to know what works and what doesn't.

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[\"x\", EAST]," +
"AXIS[\"y\", NORTH]]";

*uff*, that's all for now then. Sorry for the long e-mail!

Cheers
Milton

Andrea Aime wrote:

> Milton Jonathan ha scritto:
>> 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);
>
> Milton, I just tried your code on my computer and the lookup
> returns back 29193 for me, no matter how I set the
> axis order hints (or even if I set them at all).
>
> Full program attached. What am I missing?
>
> Cheers
> Andrea
>
>

--

Milton Jonathan
Grupo GIS e Meio Ambiente
Tecgraf/PUC-Rio
Tel: +55-21-3527-2502

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

aaime

Re: Axis problems again with CRS.lookupEpsgCode

Reply Threaded

Milton Jonathan ha scritto:

> 1b. This issue has other consequences. Since many such object
> comparisons seem to ignore the EPSG code, I have the following problem:
> a WKT was generated where the numbers were printed with only a certain
> level of precision, making the WGS84 SPHEROID's inverse flattening turn
> from 298.257223563 to 298.2572. Again, I agree that if no EPSG code is
> given, then it is a different SPHEROID. But when the code IS given, the
> comparison still ignores it and says they are different. So, if I get
> the WKT for 32723 (WGS84 UTM 23S) and simply exchange the spheroid's
> flattening as above, it does not work either:
>
> String wkt = "PROJCS[\"WGS 84 / UTM zone 23S\"," +
> "GEOGCS[\"WGS 84\"," +
> "DATUM[\"World Geodetic System 1984\"," +
> "SPHEROID[\"WGS 84\", 6378137.0, 298.2572,
> AUTHORITY[\"EPSG\",\"7030\"]]," +
> "AUTHORITY[\"EPSG\",\"6326\"]]," +
> "PRIMEM[\"Greenwich\", 0.0, AUTHORITY[\"EPSG\",\"8901\"]]," +
> "UNIT[\"degree\", 0.017453292519943295]," +
> "AXIS[\"Geodetic latitude\", NORTH]," +
> "AXIS[\"Geodetic longitude\", EAST]," +
> "AUTHORITY[\"EPSG\",\"4326\"]]," +
> "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]]";
>
> What do you think? Should it work this way? My personal opinion is that
> the identifiers should be checked always when available..

Just checking the identifiers might lead to lookups returning a code
that's not at all equal to the one passed in, think about someone
passing down a WKT with difference TO_WGS84 parameters.

As for the datum name comparison, I also complained time ago,
I have vague memories of Martin telling me that if the name is
different, then it's a different datum. But I guess this could
be relaxed and just look for the ellipsoid params and the towgs84
params, if they are all equal we can assume the datum is the same.
I would like to hear other people opinion on this one thought.

>
> 2. A smaller different issue may be related to that forceXY property you
> have in your code. I guess it turns out that now a ProjectedCRS such as
> these which specify "AXIS[\"x\", EAST]" and "AXIS[\"y\", NORTH]" instead
> of "Easting" and "Northing" don't work?

> It looked like that in the axis
> comparison code in DefaultCoordinateSystemAxis.equals(). But I tried to
> set the property and it still didn't work (see WKT below). Am I missing
> something? By the way, why is this not a hint, but a system property?

Because we found out that only the system property works 100% of the
cases in GeoServer. See:
http://jira.codehaus.org/browse/GEOT-1704

> Oh, just to let you know: this isn't so much of an issue for me right
> now, it's just to know what works and what doesn't.
>
> 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[\"x\", EAST]," +
> "AXIS[\"y\", NORTH]]";

Yeah, axis names are considered relevant for the comparison.
It makes some sense, since the names are well known, you cannot
just make them up, and x/y are reserved for geocentric axis
as far as I remember. Do you have software producing x,y as
the axis names?

Cheers
Andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Milton Jonathan

Re: Axis problems again with CRS.lookupEpsgCode

Reply Threaded

Hello again, and thanks a lot for the fast feedback!

Well, in my really humble opinion, if the guy stated that the code is
EPSG:6618, then that is what he wants, regardless of any imprecisions in
the WKT. If he wanted something else, why put the code?

Looking at things from my perspective, I think it makes some (but
little) sense to enforce Datum names, if that is a standard, but I agree
that checking the parameters when the name differs makes a lot more sense.
But I really think that enforcing the numbers in a text file to have
exactly the same precision as in the EPSG database is kinda out of
control. In my particular case, the software that generates the WKT has
the flattening and computes its inverse to output the WKT, meaning that
all those numbers are floating points with a lot of digits after the
point. Since different CRSs have different official precisions, I think
there is no way one can guarantee that the WKT will work in GeoTools
unless each number is printed with a different precision according to
the official EPSG values. Kinda complicated, in my opinion..

>
> Because we found out that only the system property works 100% of the
> cases in GeoServer. See:
> http://jira.codehaus.org/browse/GEOT-1704

Hmm, actually it didn't work here. Don't know what's going on, but I can
live with the idea that "x" and "y" are too generic and not really equal
to "Easting" and "Northing". And it's not that relevant for my
particular needs anymore since we were able to change how those names
are generated.
In any case, the code I tried (and failed) is exactly the following:

---

System.setProperty("org.geotools.referencing.forceXY", "true");

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[\"x\", EAST]," +
"AXIS[\"y\", NORTH]]";

CoordinateReferenceSystem crs = CRS.parseWKT(wkt);
Integer srid = CRS.lookupEpsgCode(crs, true);

---

Anyway, I guess I'm more concerned about the first issue :)

Cheers
Milton

>
> Cheers
> Andrea
>

--

Milton Jonathan
Grupo GIS e Meio Ambiente
Tecgraf/PUC-Rio
Tel: +55-21-3527-2502

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

aaime

Re: Axis problems again with CRS.lookupEpsgCode

Reply Threaded

Milton Jonathan ha scritto:

> Hello again, and thanks a lot for the fast feedback!
>
> Well, in my really humble opinion, if the guy stated that the code is
> EPSG:6618, then that is what he wants, regardless of any imprecisions in
> the WKT. If he wanted something else, why put the code?
>
> Looking at things from my perspective, I think it makes some (but
> little) sense to enforce Datum names, if that is a standard, but I agree
> that checking the parameters when the name differs makes a lot more sense.
> But I really think that enforcing the numbers in a text file to have
> exactly the same precision as in the EPSG database is kinda out of
> control. In my particular case, the software that generates the WKT has
> the flattening and computes its inverse to output the WKT, meaning that
> all those numbers are floating points with a lot of digits after the
> point. Since different CRSs have different official precisions, I think
> there is no way one can guarantee that the WKT will work in GeoTools
> unless each number is printed with a different precision according to
> the official EPSG values. Kinda complicated, in my opinion..

What is the software that is generating correct EPSG ids without correct
parameter values? Please understand that a minor difference in the datum
parameters leads to many meters of error in reprojections.

I come in contact with a lot of .prj files but most of the time the
authority ids are missing or referencing another authority (ESRI),
whilst the params are usually true to the EPSG database.

Cheers
andrea

--
Andrea Aime
OpenGeo - http://opengeo.org
Expert service straight from the developers.

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel

Milton Jonathan

Re: Axis problems again with CRS.lookupEpsgCode

Reply Threaded

Hi again

The software from which the CRS is coming from is Terralib
(http://www.terralib.org/), for which we have developped a GeoTools
DataStore (we intend to release it to the GeoTools community as soon as
it is ready to go). The library is C++ by the way, we made the plugin
using JNI.

In reality, we ourselves are messing with Terralib's WKT generation to
fix it and put it up to par with EPSG standards, but the parameters come
from Terralib. Terralib does not have an EPSG database and works with a
set of known CRSs, for which it stores parameters. However, as I said in
a previous e-mail, it stores parameters in a different manner (e.g.,
flattening instead of inverse flattening). So, in the end it has these
numbers which ARE exact, but needs to write them to a text WKT file.
Unfortunately, if for instance it uses all possible digits and writes
down the exact number, then GeoTools won't like it, because the EPSG
official value only has a certain level of precision.

Yeah, one solution to the issue would be to mess around some more with
the Terralib code and compute the correct EPSG code for the CRS overall
(which it doesn't do right now), but I'm not entirely sure that is
always possible without having the EPSG database itself to look it up
considering all the CRS's parameters. If that's an easy task (I'm not so
familiar with how EPSG codes are generated), then I guess it would be
the right solution in my particular case. Is it?

However, in a general way, I still think it's odd that writing numbers
with a much-too-high precision makes the CRS unrecognizable. Thinking
about it, if the value comparison within GeoTools considered only the
level of precision defined in the EPSG database, then anyone could make
it work by writing the numbers with a high precision. I guess that kind
of change could be made to DefaultEllipsoid.equals() for this particular
case, but maybe some other comparisons would need to be updated too.

What do you think?

Thanks again
Milton

Andrea Aime wrote:

> Milton Jonathan ha scritto:
>> Hello again, and thanks a lot for the fast feedback!
>>
>> Well, in my really humble opinion, if the guy stated that the code is
>> EPSG:6618, then that is what he wants, regardless of any imprecisions
>> in the WKT. If he wanted something else, why put the code?
>>
>> Looking at things from my perspective, I think it makes some (but
>> little) sense to enforce Datum names, if that is a standard, but I
>> agree that checking the parameters when the name differs makes a lot
>> more sense.
>> But I really think that enforcing the numbers in a text file to have
>> exactly the same precision as in the EPSG database is kinda out of
>> control. In my particular case, the software that generates the WKT
>> has the flattening and computes its inverse to output the WKT, meaning
>> that all those numbers are floating points with a lot of digits after
>> the point. Since different CRSs have different official precisions, I
>> think there is no way one can guarantee that the WKT will work in
>> GeoTools unless each number is printed with a different precision
>> according to the official EPSG values. Kinda complicated, in my opinion..
>
> What is the software that is generating correct EPSG ids without correct
> parameter values? Please understand that a minor difference in the datum
> parameters leads to many meters of error in reprojections.
>
> I come in contact with a lot of .prj files but most of the time the
> authority ids are missing or referencing another authority (ESRI),
> whilst the params are usually true to the EPSG database.
>
> Cheers
> andrea
>
>

--

Milton Jonathan
Grupo GIS e Meio Ambiente
Tecgraf/PUC-Rio
Tel: +55-21-3527-2502

------------------------------------------------------------------------------
Enter the BlackBerry Developer Challenge
This is your chance to win up to $100,000 in prizes! For a limited time,
vendors submitting new applications to BlackBerry App World(TM) will have
the opportunity to enter the BlackBerry Developer Challenge. See full prize
details at: http://p.sf.net/sfu/Challenge
_______________________________________________
Geotools-devel mailing list
[hidden email]
https://lists.sourceforge.net/lists/listinfo/geotools-devel