[gdal-dev] Importing completely MITAB into GDAL source tree ?

[Even Rouault]

Daniel,

thanks for your thoughts.

> Thank you for bringing this up, FWIW I am supportive of solving the
> MITAB situation and will do my best to help do this in the best interest
> of all users.
> 
> Instead of just forking the source, should we talk instead about
> migrating the ownership/direction of the MITAB project under the GDAL
> umbrella? Would the GDAL PSC be interested in that? 

In such a mode, I guess MITAB releases would be synchronized with GDAL ones, 
as that would be the same source tarball.

> That would help
> address the perception that MITAB is "dead" and make it easier for
> people like you to contribute to it since there would be only one MITAB,
> the one maintained by the GDAL team.
> 
> Note that if we are to move MITAB under the GDAL umbrella, we'd need to
> keep in mind that this involves more than just copying the source under
> the GDAL source tree as you suggest here. The standalone version of
> MITAB contains a subset of the CPL and OGR files, which is just the bare
> minimum for MITAB to work. 

Yes I'm aware of that. I tried not so long ago to sync the CPL and OGR core 
version of MITAB with the ones of GDAL trunk in a branch of my MITAB fork : 
https://github.com/rouault/mitab/commit/9e62e99a11c1163460fd9530c494e35262561b24

> If you move the official MITAB source under
> the GDAL source tree, this separation will be lost and it will become
> impossible to build MITAB as a standalone lib independent of GDAL/OGR.

My idea was actually to have build scripts in let's say 
ogr/ogrsf_frmts/mitab/build that would still generate an independant mitab lib 
with as few as possible CPL/OGR files in it. That should be doable hopefully.

There are somewhat similar, although probably more simple, similar cases in 
the GDAL source tree. Some drivers, like OGR DGN, GDAL HFA,etc... have specific 
build targets to build debug utilities (although I suspect most must be broken 
due to the changes done over the year), or small library to deal just with the 
format.

> 
> All this to say that just moving the source as you suggest is probably
> not enough to get real benefits, that would just formalize the fork
> between MITAB and GDAL without helping the users that need a standalone
> MITAB.
> 
> I think the MITAB situation is a bit similar to that of shapelib and
> libgeotiff which are extensively used by GDAL, but that also need to
> exist by themselves for the application developers that want direct
> access to a single format in a lightweight lib.
> 
> Who maintains and releases shapelib and libgeotiff today? I believe it's
> Frank. Would it make sense to also officially bring those two under the
> GDAL umbrella at the same time and solve the "when will you publish a
> new libgeotiff release?" question that I seem to hear every once in a
> while over beers at FOSS4G or code sprints.

That's Frank's call, but indeed regarding shapelib last release was in april 
2012, and the OGR version has got a few improvements since.

Regarding libgeotiff, Frank and Howard have championned a RC during the code 
sprint at FOSS4G, that should be released tomorrow according to 
http://lists.maptools.org/pipermail/geotiff/2014-September/000774.html

> 
> That would be a bit like what we did when MapCache and TinyOWS joined
> MapServer project.

The situation is a bit different since MapCache and TinyOWS, as far as I know, 
don't share (currently) code with MapServer, and have actually their own git 
repositories (even if hosted under the same account at github)

> The long term goal was to facilitate their
> integration with the MapServer core, and in the short term to increase
> the bus number of those projects and ensure their long term viability.
> 

Even

-- 
Spatialys - Geospatial professional services
http://www.spatialys.com