Wrong GCPs reported on MODIS L2 HDF5 products

[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

[Even Rouault]

In 35556:

HDF5: correct number of GCPs to avoid dummy trailing (0,0)->(0,0,0) and remove +180 offset applied to GCP longitude. Add instead a heuristics to determine if the product is crossing the antimeridian, and a HDF5_SHIFT_GCPX_BY_180 config option to be able to override the heuristics (fixes #6666)

[Even Rouault]

In 35557:

HDF5: correct number of GCPs to avoid dummy trailing (0,0)->(0,0,0) and remove +180 offset applied to GCP longitude. Add instead a heuristics to determine if the product is crossing the antimeridian, and a HDF5_SHIFT_GCPX_BY_180 config option to be able to override the heuristics (fixes #6666)

[kalxas]

Thanks for the fixes Even!