<div dir="ltr">Even,<br><br>On Tue, Mar 19, 2019 at 4:53 PM Even Rouault <<a href="mailto:even.rouault@spatialys.com">even.rouault@spatialys.com</a>> wrote:<br>><br>> Markus,<br>><br>> yes this file has unconventionnal indexing of variables, with the fastest<br>> varying dimension being latitude, which confuses the driver<br>><br>> In <a href="https://github.com/OSGeo/gdal/pull/1377">https://github.com/OSGeo/gdal/pull/1377</a>, I've made a number of changes that<br>> make support of such dataset a bit easier. I didn't go to making the driver<br>> autocorrect the swapped axis, but did a number of fixes so that the<br>> geotransform and Geolocation array metadata are correct (and also improve the<br>> geoloc transformer/wrapper to deal with such swapped axis)<br>><br>> With those fixes, the following does the right thing:<br>> $ gdalwarp -geoloc  NETCDF:"LPRM-<br>> AMSR2_L3_DS_A_SOILM3_V001_20190301000851.nc4":ts /tmp/out.tif -overwrite<br><div><br></div><div>thanks a lot!</div><div><br></div><div>But looking at all the datasets with weird georeferencing out there in the wild, it would be really ambitious to come up with a fix at driver level...<br></div><div>></div><div>> Without it, you can indeed have the expected result by setting GCP</div><div><br></div><div>This is what I ended up doing, it works just fine, also in an automated processing chain.</div><div><br></div><div>Markus M<br></div><br>><br>> $ gdal_translate \<br>>    NETCDF:"LPRM-AMSR2_L3_DS_A_SOILM3_V001_20190301000851.nc4":ts \<br>>    tmp.vrt \<br>>    -gcp 0 0 -180 90 \<br>>    -gcp 1800 0 -180 -90 \<br>>    -gcp 0 3600 180 90 \<br>>    -gcp 1800 3600 180 -90<br>><br>> $ gdalwarp tmp.vrt out.tif -order 1 --config GDAL_NETCDF_BOTTOMUP 0 -overwrite<br>><br>> Even<br>><br>> --<br>> Spatialys - Geospatial professional services<br>> <a href="http://www.spatialys.com">http://www.spatialys.com</a></div>