I now have a fix for this issue. Basically, where the envelope is being
computed, catch a TransformException, and in that case just return a
GeneralEnvelope object. All works well with this change.
Now how to I go about getting this fix considered for inclusion upstream?
Please let me know how/who to submit this to.
Thanks,
Judd
Index: main/src/main/java/org/geoserver/data/util/CoverageStoreUtils.java
IDEA additional info:
Subsystem: com.intellij.openapi.diff.impl.patch.CharsetEP
<+>UTF-8
===================================================================
--- main/src/main/java/org/geoserver/data/util/CoverageStoreUtils.java (date
1539803792000)
+++ main/src/main/java/org/geoserver/data/util/CoverageStoreUtils.java (date
1539803792000)
@@ -274,9 +274,13 @@
//
////
final CoordinateReferenceSystem targetCRS = DefaultGeographicCRS.WGS84;
- final GeneralEnvelope targetEnvelope;
+ GeneralEnvelope targetEnvelope;
if (!CRS.equalsIgnoreMetadata(sourceCRS, targetCRS)) {
- targetEnvelope = CRS.transform(envelope, targetCRS);
+ try {
+ targetEnvelope = CRS.transform(envelope, targetCRS);
+ } catch( TransformException e ) {
+ targetEnvelope = new GeneralEnvelope(envelope);
+ }
} else {
targetEnvelope = new GeneralEnvelope(envelope);
}
________________________________
From: Judd Taylor
Sent: Tuesday, October 16, 2018 3:42 PM
To: [email protected]
Subject: RE: Orthographic Coverage Layer
I have debugged through the code, and can confirm what is going on is as I
suspected.
When you hit the "publish" button on the add layer page, CatalogBuilder.java is
trying to define a lat/lon bounding box for this data. It calls
CoverageStoreUtils.getWGS84LonLatEnvelope(), and the envelop it is passing has
the wrong points selected.
The envelope has [(-6378136.9, -6378136.9),( 6378136.9, 6378136.9)]. These
limits (in meters) are not valid as points, as they fall outside the
orthographic sphere. Basically, it's assuming the projection is cylindrical,
and then trying to get the lat/lon bounding box by doing an inverse projection
on the bottom left and top right points.
As I said before, on a full disk orthographic projection, you need to take as
bounds 4 points, and go across the axes in a + shape. And even then if it's
oblique, there may be issues.
Here's what I'm going to try today:
1. Calculate the envelope max based on the following points: (xmin,0),
(xmax,0), (0,ymin), (0,ymax).
2. The the max/mins of those lat/lons returned.
3. Correct the max or min to 90/-90 if the projection is oblique full disk
depending on if the center latitude is in the northern or southern hemisphere.
This is because the top most point can be on the other side of the globe, and
thus south of the most northerly point included in the map.
This should work, I've used this before. The big question is where I need to
insert this logic into the code...
-Judd
________________________________
From: Judd Taylor
Sent: Thursday, October 11, 2018 9:14 AM
To: [email protected]
Subject: Orthographic Coverage Layer
I seem to be unable to add a WorldImage layer in a custom oblique orthographic
projection.
See the full stack trace below. But I think I know what the issue is:
Caused by: org.geotools.referencing.operation.projection.ProjectionException:
Point outside hemisphere of projection. at
org.geotools.referencing.operation.projection.ObliqueOrthographic.inverseTransformNormalized(ObliqueOrthographic.java:96)
at
org.geotools.referencing.operation.projection.MapProjection$Inverse.transform(MapProjection.java:1050)
at
org.geotools.referencing.operation.projection.MapProjection$Inverse.transform(MapProjection.java:1109)
at
org.geotools.referencing.operation.transform.AbstractMathTransform.transform(AbstractMathTransform.java:218)
at org.geotools.referencing.CRS.transform(CRS.java:1391) at
org.geotools.referencing.CRS.transform(CRS.java:1471) at
org.geotools.referencing.CRS.transform(CRS.java:1299) at
org.geoserver.data.util.CoverageStoreUtils.getWGS84LonLatEnvelope(CoverageStoreUtils.java:279)
at
org.geoserver.catalog.CatalogBuilder.buildCoverageInternal(CatalogBuilder.java:999)
at org.geoserver.catalog.CatalogBuilder.buildCoverage(CatalogBuilder.java:944)
at org.geoserver.catalog.CatalogBuilder.buildCoverage(CatalogBuilder.java:893)
at
org.geoserver.web.data.layer.NewLayerPage.buildLayerInfo(NewLayerPage.java:422)
... 112 more
It seems it's trying to compute an envelope by using an inverse projection, and
it's applying this to either all of the pixels in the image, or the corners.
The image contains a full hemisphere, so it has no valid corners, and a large
number of the pixels will return an invalid inverse projection.
I've used this same layer and projection in GeoTools in the old application,
but I can't get past the "add layer" screen in GeoServer.
So I think this is a bug. If it's trying to compute the geographic extents, it
should take a measurement across the central axes of the file (+ instead of
[]). If it's doing the inverse of every pixel in the image, it should probably
just ignore the errant pixels. Another thing to watch out for is the oblique
nature, where the top of the image can be further south than pixels below it.
I can provide the layer data for testing. Unfortunately, I haven't been able to
tinker myself on this, as for some reason the source won't build on my kubuntu
18 system.
I could use any advice for how to fix this, and offer any of my experience with
this as well.
If I should submit this as a bug, just let me know where. I would also be
interested in knowing if there are other method of communication on this issue
that are faster than Email (IRC, etc).
Thanks,
Judd
_______________________________________________
Geoserver-users mailing list
Please make sure you read the following two resources before posting to this
list:
- Earning your support instead of buying it, but Ian Turton:
http://www.ianturton.com/talks/foss4g.html#/
- The GeoServer user list posting guidelines:
http://geoserver.org/comm/userlist-guidelines.html
If you want to request a feature or an improvement, also see this:
https://github.com/geoserver/geoserver/wiki/Successfully-requesting-and-integrating-new-features-and-improvements-in-GeoServer
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-users
