Re-organizing source tree regarding drivers?
Even Rouault via gdal-dev <[email protected]>
| Newsgroups | gmane.comp.gis.gdal.devel |
|---|---|
| Message-ID | <[email protected]> |
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