[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