Re: Re-organizing source tree regarding drivers?

--===============8293178744879500974==
Content-Type: multipart/alternative; boundary="00000000000050099406518c155f"

--00000000000050099406518c155f
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

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.

Dan

On Wed, May 6, 2026 at 8:28=E2=80=AFPM Even Rouault via gdal-dev <
[email protected]> wrote:

> 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
>
> _______________________________________________
> gdal-dev mailing list
> [email protected]
> https://lists.osgeo.org/mailman/listinfo/gdal-dev
>

--00000000000050099406518c155f
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr">While the current organization is definitely not what we&#=
39;d start with, I&#39;m not sure the benefits or reorganization are worth =
making it harder to follow the commit history. But I have no strong objecti=
on if others would rather reorganize.<div><br></div><div>Dan</div></div><br=
><div class=3D"gmail_quote gmail_quote_container"><div dir=3D"ltr" class=3D=
"gmail_attr">On Wed, May 6, 2026 at 8:28=E2=80=AFPM Even Rouault via gdal-d=
ev &lt;<a href=3D"mailto:[email protected]">[email protected]=
</a>&gt; wrote:<br></div><blockquote class=3D"gmail_quote" style=3D"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>
-=C2=A0ogr/ogrsf_frmts/pmtiles: you can guess what I will write here<br>
<br>
- frmts/mem<br>
<br>
I&#39;m hesitating between:<br>
<br>
- putting all drivers below a drivers/=C2=A0 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>
:-)),=C2=A0 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 <b=
r>
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/ --&gt; core/multidim/<br>
<br>
- ogr/ and ogr/ogrsf_frmts/generic would become core/vector/=C2=A0 , possib=
ly <br>
with a core/vector/geometry for core geometry classes, and core/crs/ for <b=
r>
OSR related classes<br>
<br>
Thoughts? (I&#39;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)<b=
r>
<br>
Even<br>
<br>
-- <br>
<a href=3D"http://www.spatialys.com" rel=3D"noreferrer" target=3D"_blank">h=
ttp://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 B=
ixonimania<br>
<br>
_______________________________________________<br>
gdal-dev mailing list<br>
<a href=3D"mailto:[email protected]" target=3D"_blank">gdal-dev@list=
s.osgeo.org</a><br>
<a href=3D"https://lists.osgeo.org/mailman/listinfo/gdal-dev" rel=3D"norefe=
rrer" target=3D"_blank">https://lists.osgeo.org/mailman/listinfo/gdal-dev</=
a><br>
</blockquote></div>

--00000000000050099406518c155f--

--===============8293178744879500974==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
gdal-dev mailing list
[email protected]
https://lists.osgeo.org/mailman/listinfo/gdal-dev

--===============8293178744879500974==--