developer.forsk wrote:
>
> - If I generate the TAB/MAP files and open them in MapInfo, the hole is drawn as a second contour and no hole is present !
> - If I generate the MIF/MID files and import them in MapInfo, the hole is correctly drawn...
> - When I export the MIF/MID from TAB/MAP created by MapInfo at import time, the files remain the same then the original I have imported first !
>
> Does anyone know if this is a known problem in the MITAB library ? Or does anyone have a solution to avoid this problem ?
>

Yes, this is a known limitation of the MITAB library. The MIF/MID format
does not contain information about outside/inside rings (i.e. polygons
vs holes in polygons)... it just contains a list of region parts with
their coordinates. OTOH, the TAB format does contain information about
outside/inside rings in a REGION which MapInfo sets after analyzing the
polygon topology when you digitize new objects.

When MITAB reads in a multipart region from a MIF file like the one you
have, it treats it as a multipolygon and does not try to distinguish
holes from free standing polygons. As a result, when the MIF input (read
as multipolygon) is written to TAB, MITAB does not tag any of the rings
as holes... and you get the result that you got in MapInfo.

Since the days that MITAB was first written, OGR now has a new
OGRGeometryFactory::organizePolygons() method that could possibly be
used by the MIF reader to better handle polygons with holes:
http://www.gdal.org/ogr/classOGRGeometryFactory.html#fa3e76499553c3dc0a1621af98b88be6

We'd need to modify TABRegion::ReadGeometryFromMIFFile()
(mitab_feature_mif.cpp) to use OGRGeometryFactory::organizePolygons()
instead of always constructing a multipolygon as it does now. We'll add
this to our wishlist, but if you have funding available for this please
contact me off-list and we'd be happy to make that enhancement to the
library for you.

Daniel
--
Daniel Morissette
http://www.mapgears.com/