Andrea,
I completely understand… that fix was too easy.
But if the fix is going to be something projection specific, I feel like I need
to know better about what the purpose of this Envelope is to begin with. In the
cyllindrical case I can see the utility in having 2 points as a bound, but in
this (and other) circular cases I’m not sure how two points gives enough data
to be useful.
Based on a better definition of the Envelope, I think we can start making
decisions about what it needs to contain with respect to these circular
projections.
Thanks,
Judd
On Oct 22, 2018, at 1:52 AM, Andrea Aime
<[email protected]<mailto:[email protected]>> wrote:
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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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://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
