| Re: [geowave-dev] Multiband geotiff problem |
|
Hi Rich and guys
Continuing testing this problem, i made another try using this usgs sample geotiff http://download.osgeo.org/geotiff/samples/usgs/o41078a5.tif
If i directly publish the geotiff file in geoserver using Geotiff Raster Data Source i get this preview (good) https://i.imgsafe.org/5024bce.png
But if i ingest this geotiff in geowave and then try to publish the layer using GeoWaveRasterFormat, i get this preview (bad), an error similar to the pictures in my previous email. https://i.imgsafe.org/51b12c0.png
I'm ingesting the data with this code
String coverageName = "o41078a5.tif"; final Map<String, String> metadata = new HashMap<String, String>(); RasterDataAdapter adapter = new RasterDataAdapter(coverageName, metadata, coverage, 256, true, new NoDataMergeStrategy()); PrimaryIndex index = new SpatialIndexBuilder().setAllTiers(true).createIndex();
try (IndexWriter indexWriter = geowaveDataStore.createIndexWriter(index, DataStoreUtils.DEFAULT_VISIBILITY)) {indexWriter.write(adapter, coverage); } catch (IOException e) {} Is this wrong in anyway?
Regards,
PS: Great to know that there will be multiband support in the future Rich! De: geowave-dev-bounces@xxxxxxxxxxxxxxxx <geowave-dev-bounces@xxxxxxxxxxxxxxxx> en nombre de Jose M <soloninguno@xxxxxxxxxxx>
Enviado: jueves, 05 de mayo de 2016 02:12 p.m. Para: geowave-dev@xxxxxxxxxxxxxxxx Asunto: Re: [geowave-dev] Multiband geotiff problem Hi Rich,
Thanks for looking at the problem having so little time.
I understand why you need the same CRS, and before showing what i'm seeing with your lenient suggestion, i need to give some more info. Yesterday i was trying to load this geotiff directly in geoserver and when trying to publish the layer discover that the crs was unknown (Native CRS UNKNOWN). But looking at the gdalinfo i saw that it was very similar to the EPSG:45555 (WRF_Lambert_Conformal_Conic
2), so i set this CRS in the "Declared SRS" to EPSG:4555. That make the layer work in geoserver http://postimg.org/image/lonzjf2bl/ So i thought that maybe i can use this crs to load the geotiff before saving it it in geowave, and in fact doing that made the ingest work, the "bursa wolf" issue disappear. This is how I load the geotiff Hints hints = new Hints();
hints.put(Hints.DEFAULT_COORDINATE_REFERENCE_SYSTEM, CRS.decode("EPSG:45555")); GridCoverage2D coverage = new GeoTiffReader(new File(rasterFileName), hint ).read(null); Nevetherless when publishing the layer through the GeoWaveRasterFormat (both native and declared srs are EPSG:4326 now) this is what i see http://postimg.org/image/axvrjzzb5/ So it's not looking good. Now, returning to your lenient suggestion, when adding this in RasterDataAdapter resampleHints.put(Hints.LENIENT_DATUM_SHIFT, Boolean.valueOf(true)); and loading the geotiff without the Hints.DEFAULT_COORDINATE_REFERENCE_SYSTEM GridCoverage2D coverage = new GeoTiffReader(new File(rasterFileName), null).read(null);
http://postimg.org/image/w1aa5hvup/It doesn't throw any "bursa wolf" error, but the image seems wrong too (but different than before) So i'm not sure looking at this pictures if geowave is ingesting right or not. Maybe is an issue of the GeoWaveRasterFormat adapter for geoserver?
Thanks,
De: geowave-dev-bounces@xxxxxxxxxxxxxxxx <geowave-dev-bounces@xxxxxxxxxxxxxxxx> en nombre de Rich Fecher <rfecher@xxxxxxxxx>
Enviado: jueves, 05 de mayo de 2016 12:08 p.m. Para: geowave-dev@xxxxxxxxxxxxxxxx Asunto: Re: [geowave-dev] Multiband geotiff problem Hi Jose,
I'm at a conference will be traveling back soon, but I checked out your geotiff ingest issue. I ran gdalinfo to see what CRS is picked up and it appears there is an "unknown" datum. Constructing a gridcoverage directly through geotools works without
any resampling. Without a well-defined datum, resampling is challenging. There is a hint you can provide to the resampling operation to be lenient, but essentially you have to use at your own risk. We need to index all data within the same table using a
common coordinate reference system - we choose EPSG:4326, but we will expose a parameter in 0.9.2 to make the CRS of the index configurable. In your case because the datum is unknown, we'd have to set the transformation to be lenient:
adding this line:
resampleHints.put(Hints.LENIENT_DATUM_SHIFT, Boolean.valueOf(true));
to this method:
will properly resample this file, although given that it is just being lenient with an unknown datum here is the bbox of that geotiff that it re-projected to:
min longitude=-41.12983544958792, max longitude=-22.92163541303102, min latitude=-67.82543644308618, max latitude=-48.178035892105775
While I think defaulting to lenient datum shift may or may not be what a user of our library expects, I think there should be some way to programmatically change the default resample hints so that you have a reasonable ability to force
operations to do what you want such as this case.
Rich
On Wed, May 4, 2016 at 7:11 PM, Jose M <soloninguno@xxxxxxxxxxx> wrote:
|
