[gdal-dev] Misc. subjects : OSGeo Vienna code sprint, release plans, GDAL 2.0

Kyle Shannon kyle at pobox.com
Tue Feb 18 09:20:25 PST 2014


On Thu, Feb 13, 2014 at 2:14 PM, Even Rouault
<even.rouault at 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 at 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


More information about the gdal-dev mailing list