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
