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

[Daniel Morissette]

Hi Even, all,

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? 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. 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.

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 would be a bit like what we did when MapCache and TinyOWS joined 
MapServer project. 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.

Daniel


On 14-10-01 8:07 AM, Even Rouault wrote:
> Hi,
>
> As some of you know, the OGR MapInfo driver heavily depends on the source code
> of the MITAB library. Over the years, people have contributed fixes and
> improvements through GDAL. Not all those changes have made their way in the
> official MITAB repository that sits at https://github.com/mapgears/mitab and
> which has not evolved a lot in comparison to its copy in OGR.
> Maintaining 2 copies and synchronizing them is a time consuming and error-
> prone process.
> On the other hand, there are still people that depend on the standalone MITAB
> library, its utilities (tab2tab, etc...) and its dedicated C API. So I'm
> wondering if it wouldn't be more efficient to import those specific remaining
> parts (standalone build scripts, C API and utilities) into the GDAL source
> tree (probably a ogr/ogrsf_frmts/mitab/build and ogr/ogrsf_frmts/mitab/apps)
> That way both projects would share the same code in a very obvious way, while
> keeping their specificities.
>
> Thoughts ?
>
> Even
>


-- 
Daniel Morissette
T: +1 418-696-5056 #201
http://www.mapgears.com/
Provider of Professional MapServer Support since 2000