On Thu, Feb 13, 2014 at 2:14 PM, Even Rouault <even.roua...@mines-paris.org> wrote: > Hi, > > I've confirmed my presence to the OSGeo Vienna code sprint ( > http://wiki.osgeo.org/wiki/Vienna_Code_Sprint_2014 ). Are there folks that > will be there and indent doing some work on GDAL ? Any particular topics of > interest ? > > It could be the opportunity to take a crack at some changes that have been > mentionned for some time and are listed at > http://trac.osgeo.org/gdal/wiki/GDAL20Changes > > We should decide how to manage the 2.0 transition. I think that the 2.0 number > should be reserved as the opportunity of introducing breaking changes in the > API / ABI. But this might take a long time to implement all that is listed > above, so there's a risk we end up with a trunk that is never ready for > release for years. Not a good thing. > On the other hand, we could just be more modest and take breaking changes as > they are introduced and raise the major version number (so the yearly version > after 2.0 could be 3.0). This will require projects using GDAL to adapt > multiple times. > An alternative would be to prepare the API for new features even if they are > not implemented, but that's a difficult exercise and there's a risk that at > implementation time, the API doesn't fit. > Any thoughts ? > > Currently we have no such breakage in trunk so it could qualify as GDAL 1.11. > Perhaps we should just release it as such for now before the bigger changes ? > > Somes topics I can see for GDAL 2.0 that impact API/ABI : > - well, the mythological unification of OGR driver model with GDAL driver > model. > - XYZM support > - Curve geometries > - 64 bit integer support > > Other possible structural changes : > - Change of master version control system: switch to git / GitHub ? > - New build system : cmake ? > > Of course all of this will more likely happen if contributors or funders show > up ! > > Even > > -- > Geospatial professional services > http://even.rouault.free.fr/services.html > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev
Hi, I meant to bring this up in my earlier email, but it slipped my mind. Or maybe I didn't want to open a can of worms. What exactly would 'unification' entail? I assume all ogr drivers would have to inherit GDALMajorObject (and probably OGRDataSource and OGRLayer maybe?) and then ogr drivers would have to populate metadata. I also assume that this would replace GetCapabilities(). Can someone elaborate on the scope of such a change? Thanks. -- Kyle _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev