[gdal-dev] Re-organizing source tree regarding drivers?

[Even Rouault]

Hi,

with a number of drivers being raster+vector our current source tree 
organization is a bit messy.

For example, we have:

- ogr/ogrsf_frmts/gpkg: the GeoPackage driver started vector-only and 
then raster was added

- frmts/mbtiles: the MBTiles driver started raster-only and then vector 
was added

- ogr/ogrsf_frmts/pmtiles: you can guess what I will write here

- frmts/mem

I'm hesitating between:

- putting all drivers below a drivers/  directory

- or having drivers/raster/ , drivers/vector/ and drivers/mixed/

This later organization avoids a bit the issue of a monolithic drivers/ 
with 250+ subdirectories (who knows if Windows might not limit to 256 
:-)),  but it may involve moving code around when something that was 
raster or vector only later gains the other capability.

We should likely migrate OGR_ENABLE_DRIVER_XXXX CMake variables to using 
the GDAL_ prefix.

And C entry points for plugins would be all GDALRegisterXXXX() and 
shared libary names all gdal_XXXXX.dll/so

While we are it:

- gcore/ would be split between core/generic (driver and dataset 
classes) and core/raster.

- gcore/multidim/ --> core/multidim/

- ogr/ and ogr/ogrsf_frmts/generic would become core/vector/  , possibly 
with a core/vector/geometry for core geometry classes, and core/crs/ for 
OSR related classes

Thoughts? (I'm wondering how such a plan could be executed without 
freezing all pull request activity in the meantime to limit conflicts, 
although git might perhaps be smart enough to detect files moving around)

Even

-- 
http://www.spatialys.com
My software is free, but my time generally not.
Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania