From: Clifford H. <cli...@gm...> - 2017-08-12 07:58:39
|
I am seeing this in 15.4, but looking at the code in more recent tags, it appears the issue is still there (have not been able to actually execute the later versions however). The issue is when a subset is specified in a CRS that is different from the CRS that is reported by the coverage reader, and when the requested subset requires the use of the wrapping projection handler. The "wrapped" read envelopes are iterated through for individual reads at line 202 in GridCoverageReaderHelper, and these read envelopes have the correct geometry and CRS requested by the subset operation. The problem is that further down the line, in computeReadingGeometry() at line 388, a read envelope is created from these envelopes that uses the geometry from the subsetting envelope, but assigns it the CRS as returned by the reader instead of the CRS specified by the subset operation. This causes the readSingleCoverage method to incorrectly determine that the subsetting CRS and the coverage reader CRS are the same when they are not, which in turn causes the method to return null in many cases when no intersection is found. This seems to be causing requests that specify a subset that requires wrapping and is in a CRS that differs from the "native" coverage CRS to return no data. I am noticing this particularly in WMS requests when I specify EPSG:4326 subsets that exceed WGS 84 bounds (i.e. lon=150-210) against coverages that are not EPSG:4326 or CRS:84. I wanted to bounce this off devel before cluttering up JIRA with a false alarm. Thanks. -- Clifford M. Harms |