Martin,

Thanks for the response.

However, I do not believe -184/176 is the correct answer.  That longitude should be the east most longitude, and should be in the same ballpark as the original longitude (and looking at the projected raster geographically by inspection reveals this to be true)-- I believe the correct number should be somewhere between -110 and -120.

I have noticed that moving the latitude a bit to the east also creates this problem--so you may be correct in your reasons in why the calculation happens. 
I will try to move the -180/180 mark and see if that helps, although that will not be an acceptable solution for our product without a ton of ugly hacking (e.g. shifting the coordinates before the user sees them).

Martin Desruisseaux <[EMAIL PROTECTED]> wrote:
John Dorado a écrit :
> GeneralEnvelope ge = new GeneralEnvelope(2);
> ge.setRange(0, -150, -120);
> ge.setRange(1, 20, 70);
>
> returns a projected envelope of:
> [-160.817 12.508 , 176.101 72.81]
>
> [...snip...]
>
> GeneralEnvelope ge = new GeneralEnvelope(2);
> ge.setRange(0, -150, -120);
> ge.setRange(1, 30, 70);
> Projected envelope: [-178.617 23.017 , -110.253 72.81]

In the later case, the projected envelope is pretty close to -180° of longitude: -178.6°. I suspect
that in the former case, the referencing module actually computed -184° of longitude, and roolled it
to 176°, which is geometrically equivalent. If this is true and assuming that -184° is an accurate
answer, then Geotools referencing module is not really wrong. The problem is rather about how to
create a geometric shape crossing the -180° / +180° boundary. A workaround may be to define a
GeographicCRS with prime meridian over the Pacific Ocean instead of Greenwich, and define
ProjectedCRS using this shifted GeographicCRS (in Geotools, you should be able to select whatever
prime meridian you wish).

An other workaround would be to use longitudes in a [0..360°] range instead of [-180..180°] range.
But this is not yet implemented in Geotools 2.3 - all projection currently perform their computation
in the [-180..180°] range. However it could be added in some future Geotools version if there is a
demand for that.



> Is there no way to project a coverage that is close to the
> equator/poles/prime meridian?

Equator should not be a problem for most (but not all) projections. Pole work for some projections
only. It doesn't work for Mercator, but it can work for some other like Stereographic. This is
really projection-specific.

However, in the above case, I believe that the problem is rather a -180° / +180° border crossing
rather than an innacurate projection.

Martin.


Do you Yahoo!?
Get on board. You're invited to try the new Yahoo! Mail Beta.
-------------------------------------------------------------------------
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
_______________________________________________
Geotools-gt2-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-gt2-users

Reply via email to