Cannot publish Orthographic full disk coverage layer

Description

Create a WorldImage store (see ortho_bg.png, and it's .prj and .wld files), and then try to publish a layer from it.

You get the following in the stack dump:

The problem is it's trying to inverse project points that are outside of the map. It's making assumptions that this projection obeys cyllindrical rules, and it can use the lower left and upper right corners to determine the lat/lon envelope. You can't do this for an orthographic projection, as those points are not valid.

The simple fix is the following patch:

What this does is look for a TransformException in the inverse envelope transform step, and if that's found, return a general envelope (like all of the other error conditions). So far this works for me, but some guidance would be appreciated before this is considered for mainstream.

Environment

None

Activity

Show:
Judd Taylor
October 17, 2018, 10:06 PM

Brad,

Would this not be considered a small fix, as defined by that doc? If not I can get registered, etc... just let me know.

Brad Hards
October 17, 2018, 10:31 PM

I think the test case is probably the main thing. If the test is extensive (new file, new test data), then you probably need the CLA thing.

Andrea Aime
November 1, 2018, 9:52 AM

Quoting from list:

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

Judd Taylor
November 1, 2018, 8:05 PM

Andrea, thanks for bringing this in from the list.

My contention is that this problem exists in GeoServer directly, not GeoTools. I've been doing the same thing in a GeoTools app for a very long time now without issue.

As I understand it, GeoServer is picking points and calling that collection of points an envelope. The points selected would be the lower left and the top right points on a cyllindrical map.

That selection of points fails miserably for an output map that is essentially a circle and has no "corners".

From my debugging so far, the inverse projection between the 2 systems works perfectly... it's just that the points selected are wrong for this map type.

The "circle" has a radius of ~6,500,000m, so valid data ranges could be described as +-6.5e6. However, the points (-6.5e6,-6.5e6) and (6.5e6,6.5e6) are not valid in this projection. But (-6.5e6,0) (6.5e6,0) (0,-6.5e6) (0,6.5e6) are good points for a circular map like this.

So I think the issue is that the point selection for what constitutes an envelope is not good as it is currently handled.

Changing point selection for an envelope will be no minor change, unfortunately, which is why my initial fix is just to return like in any other error condition when the inverse projection fails.

Judd Taylor
November 1, 2018, 8:07 PM

I also want to add that I am happy to contribute here, but I'm not comfortable making a huge change to the project on basically the first day. I would prefer to work hand in hand with those more experienced with GeoServer to solve this problem.

Assignee

Unassigned

Reporter

Judd Taylor

Triage

None

Fix versions

None

Affects versions

Priority

Medium
Configure