[gdal-dev] Call for review on RFC 104: Adding a "gdal" front-end command line interface

[Even Rouault]

Le 18/11/2024 à 22:27, Andrew Bell a écrit :
> My biggest question is why you would mix vector and raster operations
> in the CLI.
>
> And since we're taking on changing things, I would wonder why those
> two parts of the codebase are commingled. Is there a strong reason not
> to have an OGR project that does vector operations and a GDAL project
> that does raster operations? It seems like mostly an historical
> artifact.

At the beginning of times, GDAL and OGR were separate sub-projects, and 
it was thought in 
https://gdal.org/en/latest/development/rfc/rfc46_gdal_ogr_unification.html 
(almost 10 years ago) that they should be unified, at least as some 
aspects, driver management, dataset structure and metadata handling, 
were common between both. Not to mention formats that can contain vector 
and raster metadata in the same container. Admittedly, some aspects of 
the unification could still be perfected, like converting a dataset with 
both types at once. Mostly an implementation detail at the driver level...

In practice there are operations like rasterization, gridding, 
contouring, polygonization that mix both data types. So considering them 
as fully separate is not so obvious. I believe that having "gdal convert 
in.shp out.parquet" and "gdal convert in.tif out.nc" work in an 
identical way would be big progress compared to "ogr2ogr out.parquet 
in.shp" and "gdal_translate in.tif out.nc" . It has just crossed my mind 
that "gdal convert in.shp out.tif" could do a rasterization behind the 
scenes, but that's probably pushing syntax sugar too far...

-- 
http://www.spatialys.com
My software is free, but my time generally not.
Butcher of all kinds of standards, open or closed formats. At the end, this is just about bytes.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20241118/aa79b7c0/attachment.htm>