Hi Judd, nope, that change cannot be accepted, the output of that code must be in WGS84, while it might work in your specific case, it can easily have side effects in other cases. Sorry!
Envelope reprojection among two generic CRSs is a complicated topic, has a number of heuristics and special cases for particular projections, the code doing it is in GeoTools around this area: https://github.com/geotools/geotools/blob/master/modules/library/referencing/src/main/java/org/geotools/referencing/CRS.java#L1528 Might not be exactly where it breaks, but likely a good place to add a breakpoint to start an investigation, if not reached you can check which methods call it and backtrack until you find a place where breakpoint is reached Code change contributions are welcomed under these guidelines: https://github.com/geotools/geotools/blob/master/CONTRIBUTING.md Regardless of whether you can make a fix, it's a good idea to create a bug report, possibly with a small test case reproducing the problem Cheers Andrea On Wed, Oct 17, 2018 at 9:38 PM Judd Taylor <[email protected]> wrote: > 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 > -- Regards, Andrea Aime == GeoServer Professional Services from the experts! Visit http://goo.gl/it488V for more information. == Ing. Andrea Aime @geowolf Technical Lead GeoSolutions S.A.S. Via di Montramito 3/A 55054 Massarosa (LU) phone: +39 0584 962313 fax: +39 0584 1660272 mob: +39 339 8844549 http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- *Con riferimento alla normativa sul trattamento dei dati personali (Reg. UE 2016/679 - Regolamento generale sulla protezione dei dati “GDPR”), si precisa che ogni circostanza inerente alla presente email (il suo contenuto, gli eventuali allegati, etc.) è un dato la cui conoscenza è riservata al/i solo/i destinatario/i indicati dallo scrivente. Se il messaggio Le è giunto per errore, è tenuta/o a cancellarlo, ogni altra operazione è illecita. Le sarei comunque grato se potesse darmene notizia. This email is intended only for the person or entity to which it is addressed and may contain information that is privileged, confidential or otherwise protected from disclosure. We remind that - as provided by European Regulation 2016/679 “GDPR” - copying, dissemination or use of this e-mail or the information herein by anyone other than the intended recipient is prohibited. If you have received this email by mistake, please notify us immediately by telephone or e-mail.*
_______________________________________________ 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
