Wrong GCPs reported on MODIS L2 HDF5 products
|Reported by:||Even Rouault||Owned by:||Even Rouault|
[12:13] <kalxas> hi EvenR, are you aware of an issue with MODIS L2 netcdf files? [12:14] <kalxas> long seems to be off by 1 decimal [12:15] <kalxas> while gdalinfo seems to be getting a correct center of the image, opening in QGIS moves the long by a factor of 10 [12:16] <EvenR> kalxas: hi. the extent of gdalinfo is correct, but the placement in QGIS not ? [12:21] <kalxas> EvenR, correct [12:21] <EvenR> kalxas: is there a geolocation array reported in the gdalinfo output ? [12:21] <kalxas> another example: http://gis.stackexchange.com/questions/204594/modis-l2-oc-sst-netcdf4-via-array-to-geotiff-distortion-problem-with-pyth [12:21] <sigq> Title: gdal - MODIS L2 (OC,SST...) netCDF4 via array to Geotiff - distortion problem with Python - Geographic Information Systems Stack Exchange (at gis.stackexchange.com) [12:21] * kalxas looking [12:21] <EvenR> you can also paste the output somewhere [12:23] <kalxas> https://dpaste.de/SyiK [12:23] <sigq> Title: dpaste.de: Snippet #382798 (at dpaste.de) [12:23] <kalxas> gdal v2.1.0 [12:24] <EvenR> kalxas: please do it on the subdataset you open in QGIS. The current output is just the general metadata [12:25] <EvenR> like gdalinfo HDF5:"A2016269121000.L2_LAC_OC.nc"://geophysical_data/Kd_490 [12:25] <kalxas> ok, doing it now [12:26] <kalxas> https://dpaste.de/43AB [12:26] <sigq> Title: dpaste.de: Snippet #382799 (at dpaste.de) [12:32] <EvenR> kalxas: the longitude of the GCPs is quite funky indeed. And they are dummy ones at the end (0,0)->(0,0,0) [12:33] <EvenR> there might be a 180 deg shift [12:34] <EvenR> looking in the driver, I see pasGCPList[k].dfGCPX = static_cast<double>(Longitude[iGCP])+180.0 . hum... [12:38] <EvenR> and this issue has existed for the 11 past years : https://trac.osgeo.org/gdal/changeset/8066 [12:38] <sigq> Title: Changeset 8066 – GDAL (at trac.osgeo.org) [12:39] <EvenR> a workaround would be to translate to VRT, edit the GCP X coordinates to substract 180, and remove the trailing dummy GCPs [12:40] <kalxas> :) [12:41] <EvenR> if you can recompile from source, just removing the +180 in hdf5imagedataset.cpp might be quicker. [12:42] <kalxas> thanks, I will try the vrt way first [12:42] <EvenR> not completely sure why there are those trailing dummy GCPs. Might be an issue in the way the subsampling is done [12:44] <kalxas> this is the file: http://oceandata.sci.gsfc.nasa.gov/cgi/getfile/A2016273115000.L2_LAC_OC.nc [12:52] <kalxas> EvenR, this is a GCP from the VRT [12:52] <kalxas> <GCP Id="" Pixel="1260.5000" Line="2000.5000" X="1.841315345764E+02" Y="3.734094238281E+01" /> [12:52] <kalxas> so I need to subtract 180 from all those [12:53] <kalxas> is this going to be patched in trunk? [12:53] <kalxas> I could make a patch for the distribution packages [12:54] <EvenR> kalxas: I'm working on a fix for both issues (+180 and dummy GCPs) . The result of warping looks good
Change History (3)
Note: See TracTickets for help on using tickets.