RFC 70：从实用程序的输出文件扩展名猜测输出格式
作者： |
甚至鲁奥 |
联系方式： |
|
起动： |
2017年8月 |
状态： |
通过、实施 |
实施版本： |
2.3.0 |
总结
这个建议是添加syntaxic sugar来生成GDAL和OGR命令行实用程序，因此当没有使用-f/-of开关显式指定输出驱动程序时，它们会考虑输出文件名的扩展来猜测要使用哪个输出驱动程序。
动机
当前，命令行实用程序需要在不希望使用默认格式（通常是栅格格式的GeoTIFF和矢量格式的Shapefile）时显式指定输出格式。但这相当违反直觉。例如，“gdal_translate in.tif out.png”将生成GeoTIFF，“ogr2ogr out.gpkg in.shp”将生成shapefile。所以必须分别指定-of PNG和-f GPKG才能得到预期的结果。
例如，在ImageMagick convert实用程序或OpenJPEG opju compress/opju decompress实用程序中，可以从输出文件名的扩展猜出输出格式。
C/C++和Python实用程序的更改
如果未指定-f或-of，则命令行实用程序（注意：由于r39878两个开关都可以不同地使用），将遍历已注册的驱动程序，并检查是否有一个或多个具有输出功能的驱动程序声明识别输出文件名的扩展名。
当只有一个驱动程序声明此扩展（.tif、.png、.jpg等）时，将自动使用
当多个驱动程序声明此扩展名（例如KML和LIBKML for.KML）时，实用程序将选择第一个注册的驱动程序（netCDF而不是GMT for.nc文件除外），并发出一个警告，指定使用哪个驱动程序
如果没有驱动程序声明此扩展名，并且扩展名不是空的（例如.mpg文件名），则实用程序将出错
完整性：
如果没有扩展名，并且无法识别前缀（见下文），则默认输出驱动程序将被静默使用，与当前一样
由于至少GDAL 1.10，该逻辑的基础已经存在，因为对于C/C++实用程序发出警告，当输出格式的扩展被已知的是由另一个驱动程序识别而不是默认输出驱动程序时。
类似地，对于向量输出，如果执行类似于“ogr2ogr PG:dbname=mydb”的操作输出.shp，使用shapefile创建PG:dbname=mydb目录，而不是将shapefile摄取到PostgreSQL中。在这种情况下会发出警告，因为PG驱动程序在其元数据中声明PG:前缀。在这种情况下，新的行为将暗示-update开关。
当实用程序作为库函数（GDALTranslate（）等）可用时，如果未指定开关的-f/-of，也将应用输出格式猜测
SWIG绑定的更改
对于librarified实用程序（gdal.Translate等），format参数现在默认为None。
潜在问题
在GDAL版本只有一个支持扩展xxx的驱动程序，但较新版本添加了另一个也支持扩展xxx的驱动程序（或者同一版本的另一个发行版有一个处理xxx的插件）的情况下，新逻辑可能存在一些脆弱性。因此，“gdal_translate in out.xxx”的脚本现在将在下一个版本中出错，因为有几个驱动程序可用。
底线：当需要可靠性/再现性时，始终指定输出驱动程序。
这个RFC主要有助于交互式转换，你键入的越少越好。
向后兼容性
这将中断使用扩展名与非默认驱动程序匹配的输出文件名的脚本。这种不兼容性是不太可能的，因为以前的GDAL版本已经在这种情况下发出警告（对于C/C++实用程序而言）。对于Python实用程序，默认的驱动程序是静默使用的），因此如果人们真的想执行“gdal_translate in.tif out.png-of GTiff”，他们可能已经指定了输出驱动程序。
MIGRATION_GUIDE.TXT将提到这些潜在的警告。
测试
现有的自动测试套件应该继续通过（与当前行为的测试相关的一些更改）
实施
实施将由甚至鲁奥完成
提议的实施 https://github.com/rouault/gdal2/tree/rfc70
差异： https://github.com/OSGeo/gdal/compare/trunk...rouault:rfc70
投票历史
+1名来自JukkaR，TamasS，DanielM和Ever