[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
[udig-devel] Re: The World's on its side! (projection issue)
|
dblasby@xxxxxxxxxxxxx a écrit :
When I load shapefiles into UDIG, I find that everything is flipped on
its side (so antarctica runs north-south on the left side of the map).
If I delete the .prj file and re-load, it works correctly.
The dataset came from ogr2ogr.
I'm assuming this is Geotools CRS & PROJ.4 disagreeing on what 4326
actually means.
I don't think that there is any disagreement between Proj.4 and
Geotools. The EPSG:4326 definition has no ambiguity about axis order.
Actually there is a disagreement between... Geotools and Geotools.
The officiel axis order for EPSG:4326 is (latitude,longitude). The .prj
file attached in the previous mail was correct: the AXIS clauses in this
WKT correctly appear in "Lat", "Long" order.
In Geotools, we currently have 4 epsg factories: epsg-wkt, epsg-access,
epsg-hsql and epsg-postgresql. All of them define EPSG:4326 axis in
(latitude,longitude) order as specified in the EPSG database, except
epsg-wkt which creates EPSG:4326 CRS with (longitude,latitude) axis
order. I believe that epsg-wkt is the factory used by udig, which may
explain the flipping.
Actually, epsg-wkt factory seems to rely on the default axis order
instead of providing explicit definitions for them. Because the WKT
specification said that the default order is (longitude,latitude), this
explain why axis order in epsg-wkt is (longitude,latitude).
Other than deleting all my .prj files (which I dont really want to do
since other products use them just fine) what can I do? Is there a
"like-everyone-else's 4326" mode?
I think Geotools needs to talk with Frank Warmerdam (the OGR/GDAL/PROJ.4
lead).
I don't think that we need to talk with Frank Warmerdam. As said above,
the EPSG:4326 definition is very clear. The epsg-wkt axis order problem
is known since March or April (approximatively), and this issue has been
mentionned some time on the Geotools mailing list. Other factories like
epsg-hsql should provide correct axis order.
A solution may be to migrate udig toward the use of an other epsg
factory (for example epsg-hsql). It would need some minor work on
Geotools side (just the port of AUTO factory, which currently live in
epsg-wkt), and maybe some work on udig side. The amount of work needed
on udig side depends on the way it handle CRS. If the udig renderer make
no assumption about axis order and always check them, then the migration
to an other epsg factory should be transparent.
If a migration toward an other epsg factory is not acceptable, a second
solution is to patch epsg-wkt. But it would need the same amount of work
on udig side.
Martin.
