<div dir="ltr">While the current organization is definitely not what we'd start with, I'm not sure the benefits or reorganization are worth making it harder to follow the commit history. But I have no strong objection if others would rather reorganize.<div><br></div><div>Dan</div></div><br><div class="gmail_quote gmail_quote_container"><div dir="ltr" class="gmail_attr">On Wed, May 6, 2026 at 8:28 PM Even Rouault via gdal-dev <<a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-style:solid;border-left-color:rgb(204,204,204);padding-left:1ex">Hi,<br>
<br>
with a number of drivers being raster+vector our current source tree <br>
organization is a bit messy.<br>
<br>
For example, we have:<br>
<br>
- ogr/ogrsf_frmts/gpkg: the GeoPackage driver started vector-only and <br>
then raster was added<br>
<br>
- frmts/mbtiles: the MBTiles driver started raster-only and then vector <br>
was added<br>
<br>
- ogr/ogrsf_frmts/pmtiles: you can guess what I will write here<br>
<br>
- frmts/mem<br>
<br>
I'm hesitating between:<br>
<br>
- putting all drivers below a drivers/  directory<br>
<br>
- or having drivers/raster/ , drivers/vector/ and drivers/mixed/<br>
<br>
This later organization avoids a bit the issue of a monolithic drivers/ <br>
with 250+ subdirectories (who knows if Windows might not limit to 256 <br>
:-)),  but it may involve moving code around when something that was <br>
raster or vector only later gains the other capability.<br>
<br>
We should likely migrate OGR_ENABLE_DRIVER_XXXX CMake variables to using <br>
the GDAL_ prefix.<br>
<br>
And C entry points for plugins would be all GDALRegisterXXXX() and <br>
shared libary names all gdal_XXXXX.dll/so<br>
<br>
While we are it:<br>
<br>
- gcore/ would be split between core/generic (driver and dataset <br>
classes) and core/raster.<br>
<br>
- gcore/multidim/ --> core/multidim/<br>
<br>
- ogr/ and ogr/ogrsf_frmts/generic would become core/vector/  , possibly <br>
with a core/vector/geometry for core geometry classes, and core/crs/ for <br>
OSR related classes<br>
<br>
Thoughts? (I'm wondering how such a plan could be executed without <br>
freezing all pull request activity in the meantime to limit conflicts, <br>
although git might perhaps be smart enough to detect files moving around)<br>
<br>
Even<br>
<br>
-- <br>
<a href="http://www.spatialys.com" rel="noreferrer" target="_blank">http://www.spatialys.com</a><br>
My software is free, but my time generally not.<br>
Highly recommend OxiGDAL if you want to live in the 21th century and cure Bixonimania<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href="mailto:gdal-dev@lists.osgeo.org" target="_blank">gdal-dev@lists.osgeo.org</a><br>
<a href="https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel="noreferrer" target="_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
</blockquote></div>