Thomas,
part of the unexposed options are indeed due to:
- sometimes desynchronization between the C++ and Python API
- sometimes not finding quickly a good enough Python name, and the
option being of marginal use
- or because the handling of the switch must be done when
opening/creating the input/output dataset and, as gdal.Warp() can accept
dataset objects in addition to filenames, the option would be without
effect. If you look at apps/gdalwarp_lib.cpp in the
GDALWarpAppOptionsNew() function, all switches that have only the effect
of setting a field of the psOptionsForBinary structure aren't good
candidates to be mapped as kwargsoptions. -overwrite is in this category
(if you pass an output dataset *object*)
Regarding -rb, -rc, -rcs they are historical shortcurs for -r bilinear,
-r cubic, -r cubicspline that have been undocumented for phasing them
out as we have now a bunch of methods compared to the few ones of older
versions.
Even
Le 31/05/2021 à 22:50, Thomas Gratier a écrit :
Hello all,
Due to question at
https://gis.stackexchange.com/questions/398223/how-to-remap-gdal-options-from-string-version-to-a-dictionary-version
<https://gis.stackexchange.com/questions/398223/how-to-remap-gdal-options-from-string-version-to-a-dictionary-version>
I've taken a look at code
When trying to use gdal.Warp from Python, most options are supported
but some seems to be missing
Although an approach with only `gdal.Warp(dest, origin,
options='-overwrite')` can work without code change,
the dict approach like below seems to be simpler from a Python perspective
kwargsoptions = {"overwrite": True} # particular key does not exist,
just for the explanation
gdal.Warp(dest, origin, **kwargsoptions)
Below are the command options I only found in gdalwarp command line
but absent in the WarpOptions (from doc
https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-r
<https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-r>)
[-ct string]
[-novshiftgrid]
[-refine_gcps tolerance [minimum_gcps]]
[-ovr level|AUTO|AUTO-n|NONE]
[-srcalpha|-nosrcalpha]
[-q]
[-if format]*
[-overwrite]
[-oo NAME=VALUE]*
[-doo NAME=VALUE]*
-srcalpha is present but not it counterpart -nosrcalpha
In gdal.py code, there are references to resampling option not in the
doc e.g below excerpt
(from
https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/osgeo/gdal.py#L588
<https://github.com/OSGeo/gdal/blob/master/gdal/swig/python/osgeo/gdal.py#L588>)
.
elif resampleAlg == GRIORA_Bilinear:
new_options += ['-rb']
elif resampleAlg == GRIORA_Cubic:
new_options += ['-rc']
elif resampleAlg == GRIORA_CubicSpline:
new_options += ['-rcs']
It may to need to be removed if looking at
https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-r
<https://gdal.org/programs/gdalwarp.html#cmdoption-gdalwarp-r>
e.g (no -rcs, -rb or -rc options) except maybe for compatibility reason
I will try to make a PR. The main issue is more about naming for each
option.
I also don't know if command line and Python API "unsync" is due to
evolution, to intended API choices or other reasons.
I also only discuss here the gdal.Warp options but I suppose there are
maybe other Python tools ported from RFC 59
https://gdal.org/development/rfc/rfc59_utilities_as_a_library.html
<https://gdal.org/development/rfc/rfc59_utilities_as_a_library.html>
that may have the same "unsync" issue.
Did not look at the moment
Regards
Thomas Gratier
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
--
http://www.spatialys.com
My software is free, but my time generally not.
_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev
