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
_______________________________________________
gdal-dev mailing list
[email protected]
http://lists.osgeo.org/mailman/listinfo/gdal-dev
