[
http://jira.codehaus.org/browse/GEOT-1745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martin Desruisseaux reopened GEOT-1745:
---------------------------------------
Assignee: Martin Desruisseaux (was: Andrea Aime)
Reopening this issue, since the consequences of allowing the coordinates to go
beyong the [-PI ... PI] range are not well understood. For example the Lambert
projection performs the following calculation:
sin(lambda * n)
where n is some factor. Unfortunatly this is not the same than:
sin((lambda + 2*PI) * n) =
sin(lambda * n + (2*PI) * n) =
sin(lambda * n) * cos(2*PI * n) + cos(lambda * n) * sin(2*PI * n) =
sin(lambda * n) * cos(n) + cos(lambda * n) * sin(n)
This is yet more complicated if we want to get the n factor out of sin or cos
trigonometric function: http://en.wikipedia.org/wiki/Chebyshev_polynomials
So by allowing the longitude or latitude to goes out of their range, we are
really getting different result than what we would get by rolling back the
longitude (for example) in the -180 ... 180° range. I'm not sure which behavior
is the appropriate one...
> MapProjection: relax coordinate checks/make them configurable
> -------------------------------------------------------------
>
> Key: GEOT-1745
> URL: http://jira.codehaus.org/browse/GEOT-1745
> Project: GeoTools
> Issue Type: Improvement
> Components: core referencing
> Affects Versions: 2.4.2, 2.5-M1
> Reporter: Andrea Aime
> Assignee: Martin Desruisseaux
> Fix For: 2.4.2, 2.5-M1
>
>
> As reported in this mail thread:
> http://www.nabble.com/Relaxing-coordinate-checks-in-MapProjection--td16154359.html
> it would be very useful to relax the current bound checks on MapProjection
> (line ...) as they are breaking rendering in at least two applications
> depending on GeoTools (GeoServer and uDig).
> Implementation ideas:
> * add a new hint to ask for transform leniency
> * use the current "lenient transform" hint to act on bound checks as well
> The latter is probably the easiest way, but has backwards compatibility
> issues. At the moment the CRS.findMathTransform(from, to , lenient) javadoc
> states:
> {code}
> param lenient [EMAIL PROTECTED] true} if the coordinate operations should be
> created
> even when there is no information available for a datum shift.
> {code}
> Most datastore and rendering code sets lenient to true in order to get a best
> effort behaviour, so the change proposed above would be consistent with the
> current intended usage, but not fully with the javadoc (thought it can be
> argued that it doesn't say anything about exception being thrown either, so
> the current behaviour is not specified in the javadocs either?).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://jira.codehaus.org/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
-------------------------------------------------------------------------
This SF.net email is sponsored by the 2008 JavaOne(SM) Conference
Don't miss this year's exciting event. There's still time to save $100.
Use priority code J8TL2D2.
http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone
_______________________________________________
Geotools-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geotools-devel
