[
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)
