[jira] [Commented] (SIS-547) Mercator projection should wraparound longitude values

["Martin Desruisseaux (Jira)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/SIS-547?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17573034#comment-17573034 ] 

Martin Desruisseaux commented on SIS-547:
-----------------------------------------

Maybe we should revert this change? It causes regressions that are hard to fix when Mercator applies a wraparound. Consider the following envelope (in green):

!image-2022-07-29-17-16-59-619.png!

Before this change, the result of projecting above envelope to Mercator was the green rectangle below. After this change, the result became the red rectangle (the vertical offsets are only for making easier to distinguish the rectangles). Actually the result would be the small yellow rectangle if it was not for the additional sampling that {{Envelopes.transform(…)}} does (that method projects some points in the border centres in addition of corners).

!image-2022-07-29-17-21-47-669.png!

Because of the new wraparound, the left border of green rectangle moved to the right side after projection, very close to the right border of green envelope. The result is the yellow envelope. Because {{Envelopes.transform(…)}} uses some more points than only the corners, that envelope is expanded to the red one, but it still not the expected size.

The green envelope may seem invalid, but it is relatively easy to fix or normalize an envelope after its projection. By contrast it is much more difficult to get the correct envelope if wraparound was applied at the {{MathTransform}} level. More generally, wraparound is a difficult problem which can not be resolved at the point level. It often needs to be resolved at the geometry or raster levels. The problem is that {{MathTransform}} works on points only.

We may argue that wraparound at the point level is unavoidable with some map projection (Lambert Conformal, etc.) because the latitude is used in trigonometric expressions such as {{sin}} and {{{}cos{}}}, which do an implicit wraparound. But those map projections are not used for word-wide map as much as Mercator projection.

> Mercator projection should wraparound longitude values
> ------------------------------------------------------
>
>                 Key: SIS-547
>                 URL: https://issues.apache.org/jira/browse/SIS-547
>             Project: Spatial Information Systems
>          Issue Type: Improvement
>          Components: Referencing
>    Affects Versions: 0.6, 0.7, 0.8, 1.0, 1.1, 1.2
>            Reporter: Martin Desruisseaux
>            Assignee: Martin Desruisseaux
>            Priority: Major
>             Fix For: 1.3
>
>         Attachments: image-2022-07-29-17-16-59-619.png, image-2022-07-29-17-21-47-669.png
>
>
> When the central meridian has a value different than zero, user may expect a range of 180° on the east of central meridian to produce positive easting values and conversely on for 180° on the west of central meridian. This is currently not the case:
> {code:java}
> ProjectedCRS crs = (ProjectedCRS) CRS.forCode("EPSG:3994");
> MathTransform prj = crs.getConversionFromBase().getMathTransform();
> double[] coordinates = {-41, 100, -41, 179, -41, 181, -41, -179};
> prj.transform(coordinates, 0, coordinates, 0, 4);
> System.out.println(java.util.Arrays.toString(coordinates));
> {code}
> Output (reformatted for readability):
> {code:none}
>         0   -3767132
>   6646680   -3767132
>   6814950   -3767132
> -23473717   -3767132
> {code}
> Other map projection implementations rely on trigonometric functions for applying an implicit wraparound. For example in a call to {{sin(λ)}} the λ argument value is implicitly reduced to a range of -π … +π around the λ₀ (central meridian). But it does not happen in the particular case of the Mercator projection, since the Easting value is just a multiplication factor without trigonometric functions involved. So we have to do the wraparound ourselves.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)