GeoTools

GridCoverageRenderer fails to display coverages whose envelope touches the poles when reprojection to 900913 is required

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Fixed
  • Affects Version/s: 2.4.1, 2.5-M0
  • Fix Version/s: 2.4.2, 2.5-M1
  • Component/s: render
  • Labels:
    None

Description

Situation:

  • coverage whose envelope spans the whole globe (exactly, -180/180, -90/90)
  • coverage is in 4326
  • reprojection is requested to 900913

The result is the following exception: 

20 mar 16:21:01 WARN [geotools.rendering] - Latitude 90°00.0'S is too close to a pole.
org.geotools.referencing.operation.projection.ProjectionException: Latitude 90°00.0'S is too close to a pole.
	at org.geotools.referencing.operation.projection.Mercator$Spherical.transformNormalized(Mercator.java:212)
	at org.geotools.referencing.operation.projection.MapProjection.transform(MapProjection.java:784)
	at org.geotools.referencing.operation.projection.MapProjection.transform(MapProjection.java:825)
	at org.geotools.referencing.operation.transform.AbstractMathTransform.transform(AbstractMathTransform.java:217)
	at org.geotools.referencing.CRS.transform(CRS.java:983)
	at org.geotools.referencing.CRS.transform(CRS.java:929)
	at org.geotools.renderer.lite.gridcoverage2d.GridCoverageRenderer.paint(GridCoverageRenderer.java:354)
	at org.geotools.renderer.lite.StreamingRenderer.renderRaster(StreamingRenderer.java:1850)
	at org.geotools.renderer.lite.StreamingRenderer.processSymbolizers(StreamingRenderer.java:1709)
...

The issue is that the code is trying to reproject the whole native envelope to 900913, but rendering over
google maps does not require that (the map is actually cut at 85° or something like that).

Issue Links

is depended upon by

Bug - A problem which impairs or prevents the functions of the product. GEOS-1807 Coverages do not reproject properly betweeen EPSG:4326 and EPSG:900913

  • Major - Major loss of function.
  • Closed - The issue is considered finished, the resolution is correct. Issues which are not closed can be reopened.
relates to

Improvement - An improvement or enhancement to an existing feature or task. GEOT-1745 MapProjection: relax coordinate checks/make them configurable

  • Major - Major loss of function.
  • Reopened - This issue was once resolved, but the resolution was deemed incorrect. From here issues are either marked assigned or resolved.

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Simone Giannecchini added a comment -
can you put together an isolated test case aaime?
Show
Simone Giannecchini added a comment - can you put together an isolated test case aaime?
Hide
Permalink
Martin Desruisseaux added a comment - - edited
This is related to the example for the Mercator case given in a GEOT-1745 comment. This kind of check could be relaxed as well (in addition to the relaxes already done), but we need to make sure that the renderers are prepared to receive bounding boxes with infinite values.
Show
Martin Desruisseaux added a comment - - edited This is related to the example for the Mercator case given in a GEOT-1745 comment. This kind of check could be relaxed as well (in addition to the relaxes already done), but we need to make sure that the renderers are prepared to receive bounding boxes with infinite values.
Hide
Permalink
Andrea Aime added a comment -
Simone: is a sample data set + geoserver wms request enough of a test case?

Martin: do you mean envelopes whose minx/maxx may be Double.POSITIVE_INFINITY and friends?
Show
Andrea Aime added a comment - Simone: is a sample data set + geoserver wms request enough of a test case? Martin: do you mean envelopes whose minx/maxx may be Double.POSITIVE_INFINITY and friends?
Hide
Permalink
Andrea Aime added a comment -
Simone, the grid coverage I already sent you (the world poultry density from FAO). As WMS you can adapt this one:
http://localhost:8080/geoserver/wms?exceptions=application/vnd.ogc.se_inimage&height=512&width=512&layers=topp:poultry&request=GetMap&srs=EPSG:900913&format=image/png&version=1.1.0&bbox=-2.001747083166E7,-2.001747083166E7,2.001747083166E7,2.001747083166E7
(it's a world wide request in 900913, that is, world wide as far as Google is concerned, so it does not really touch the poles, of course)
Show
Andrea Aime added a comment - Simone, the grid coverage I already sent you (the world poultry density from FAO). As WMS you can adapt this one: http://localhost:8080/geoserver/wms?exceptions=application/vnd.ogc.se_inimage&height=512&width=512&layers=topp:poultry&request=GetMap&srs=EPSG:900913&format=image/png&version=1.1.0&bbox=-2.001747083166E7,-2.001747083166E7,2.001747083166E7,2.001747083166E7 (it's a world wide request in 900913, that is, world wide as far as Google is concerned, so it does not really touch the poles, of course)
Hide
Permalink
Andrea Aime added a comment -
Hey Simone, I don't know exactly what changes you and Daniele made in the grid coverage renderer on trunk some time ago, but I've tried the request on trunk, and it works fine there (going to attach a screenshot).
So I'm wondering, can we backport the improved GridCoverageRenderer on 2.4.x as well?
Show
Andrea Aime added a comment - Hey Simone, I don't know exactly what changes you and Daniele made in the grid coverage renderer on trunk some time ago, but I've tried the request on trunk, and it works fine there (going to attach a screenshot). So I'm wondering, can we backport the improved GridCoverageRenderer on 2.4.x as well?
Hide
Permalink
Andrea Aime added a comment -
The reprojected poultry layer.
Show
Andrea Aime added a comment - The reprojected poultry layer.
Hide
Permalink
Andrea Aime added a comment -
Martin, about relaxing the reprojection checks in mercator (and lambert too) I looked around, the envelope reprojection methods are used almost everywhere, so the change would affect a lot of code. Yet, reprojection failures aren't recoverable usually, so worst case we'd move an exception in another point of the code if the user side is not ready to deal with infinite numbers. What do you think?
Show
Andrea Aime added a comment - Martin, about relaxing the reprojection checks in mercator (and lambert too) I looked around, the envelope reprojection methods are used almost everywhere, so the change would affect a lot of code. Yet, reprojection failures aren't recoverable usually, so worst case we'd move an exception in another point of the code if the user side is not ready to deal with infinite numbers. What do you think?
Hide
Permalink
Simone Giannecchini added a comment -
aaime, I have asked daniele to spent a couple of hours to backport to 2.4.x.
Show
Simone Giannecchini added a comment - aaime, I have asked daniele to spent a couple of hours to backport to 2.4.x.
Hide
Permalink
Martin Desruisseaux added a comment -
Oups! Missed the last discussion on this topic.

Yes relaxing the exception throw when too close to a pole whould means producing envelope with miny = Double.NEGATIVE_INFINITY and maxy = Double.NEGATIVE_INFINITY (or being close to that)...

I agree with Andrea's remark, that hidding an error occuring soon may just push the error futher in the code, making the bug harder to diagnotic. I'm usually a strong supporter of "check early, thrown an exception early" in case of error. Yet this particular case is a gray corner, because on a mathematic point of view an infinite value is not really an error if projected values near a pole really tend toward infinities...

I have not yet taken any action on this issue. I'm still unsure about which action would be best.
Show
Martin Desruisseaux added a comment - Oups! Missed the last discussion on this topic. Yes relaxing the exception throw when too close to a pole whould means producing envelope with miny = Double.NEGATIVE_INFINITY and maxy = Double.NEGATIVE_INFINITY (or being close to that)... I agree with Andrea's remark, that hidding an error occuring soon may just push the error futher in the code, making the bug harder to diagnotic. I'm usually a strong supporter of "check early, thrown an exception early" in case of error. Yet this particular case is a gray corner, because on a mathematic point of view an infinite value is not really an error if projected values near a pole really tend toward infinities... I have not yet taken any action on this issue. I'm still unsure about which action would be best.
Hide
Permalink
Andrea Aime added a comment -
A pragmatic solution would be to use Double.MAX_VALUE, that is, work in a sort of saturation logic. Thought this approach would be unsatisfactory from a mathematical point of view...
Show
Andrea Aime added a comment - A pragmatic solution would be to use Double.MAX_VALUE, that is, work in a sort of saturation logic. Thought this approach would be unsatisfactory from a mathematical point of view...
Hide
Permalink
Martin Desruisseaux added a comment -
I have no example in mind right now where Double.MAX_VALUE and Double.POSITIVE_INFINITY would change much... The result of operations like comparaisons, divisions, etc. would be very similar in both case (divising by MAX_VALUE would produces a number very close to zero, while divising by POSITIVE_INFINITY would produces exactly zero, etc.)

My concern was about use case like this one: a widget transforms a geographic envelope to Mercator, then blindly zoom out in order to get the whole envelope contained in the window. If the envelope tends toward infinity, most of the Earth surface would be crunshed in an tiny line in the middle, and pole would fill the whole remainding area.

One possible fix on user side would be to make some defensive clipping of the envelope. But how the user would know which clip to apply? Looking at the "Domain of Validity" metadata attached to CRS may help, but I'm not sure that many user would do... (and this metadata is still missing when x,y axis are swapped, as you pointed out in an other JIRA task).

In summary, throwing an exception in MapProjection protects some user from mistakes, but prevent other users to do their work when they know what they are doing (i.e. they clip the resulting envelope). Not throwing an exception would give more flexibility to power users, but requires more discipline for all users (keep in mind that you may needs to clip your resulting envelope).

A possible intermediate approach would be to provide a method in CRS utility class, said transform(envelope, targetCRS), which applies automatically the clip specified in "Domain of Validity" metadata, if presents.
Show
Martin Desruisseaux added a comment - I have no example in mind right now where Double.MAX_VALUE and Double.POSITIVE_INFINITY would change much... The result of operations like comparaisons, divisions, etc. would be very similar in both case (divising by MAX_VALUE would produces a number very close to zero, while divising by POSITIVE_INFINITY would produces exactly zero, etc.) My concern was about use case like this one: a widget transforms a geographic envelope to Mercator, then blindly zoom out in order to get the whole envelope contained in the window. If the envelope tends toward infinity, most of the Earth surface would be crunshed in an tiny line in the middle, and pole would fill the whole remainding area. One possible fix on user side would be to make some defensive clipping of the envelope. But how the user would know which clip to apply? Looking at the "Domain of Validity" metadata attached to CRS may help, but I'm not sure that many user would do... (and this metadata is still missing when x,y axis are swapped, as you pointed out in an other JIRA task). In summary, throwing an exception in MapProjection protects some user from mistakes, but prevent other users to do their work when they know what they are doing (i.e. they clip the resulting envelope). Not throwing an exception would give more flexibility to power users, but requires more discipline for all users (keep in mind that you may needs to clip your resulting envelope). A possible intermediate approach would be to provide a method in CRS utility class, said transform(envelope, targetCRS), which applies automatically the clip specified in "Domain of Validity" metadata, if presents.
Hide
Permalink
Andrea Aime added a comment -
Mass closing all issues that have been in "resolved" state for 2 months or more without any feedback or update
Show
Andrea Aime added a comment - Mass closing all issues that have been in "resolved" state for 2 months or more without any feedback or update

People

  • Assignee:
    Daniele Romagnoli
    Reporter:
    Andrea Aime
Vote (0)
Watch (1)

Dates

  • Created:
    Updated:
    Resolved: