[gdal-dev] Importing completely MITAB into GDAL source tree ?
Uffe Kousgaard
uffe.kousgaard at routeware.dk
Wed Oct 1 06:27:01 PDT 2014
As the one, who have requested this, I obviously think it is a great
idea, since both https://github.com/mapgears/mitab and
http://mitab.maptools.org/ are "dead".
Including the forum at yahoo:
https://groups.yahoo.com/neo/groups/mitab/info
We currently maintain our own older code based upon 1.7.0, which
includes the first 2 fixes here:
http://trac.osgeo.org/gdal/ticket/5256
http://trac.osgeo.org/gdal/ticket/5676
And now I have just added this one (no fix for that one):
http://trac.osgeo.org/gdal/ticket/5677
We use MITAB C API and nothing else. That is the DLL version.
Compiled for both win32 and win64.
Regards
Uffe Kousgaard
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
>
>
More information about the gdal-dev
mailing list