Ticket #2265 (new defect)

Opened 4 months ago

Last modified 4 months ago

MapInfo File Driver does not write correctly empty geometry in MIF/MID files

Reported by: elzouavo Assigned to: dmorissette
Priority: normal Milestone: 1.6.0
Component: OGR_SF Version: unspecified
Severity: normal Keywords: mitab midmif
Cc: warmerdam

Description

I have shapfiles with empty geometries. Those empty features were created by OGR GEOMETRY INTERSECTION method. I use ogr2ogr (FWTools 2.1.1) to convert them to MIF/MID format. Then, when I try to import them in MapInfo?® Professional I have an error message telling that MapInfo?® can't insert an empty object in the TAB. I edit one MIF file created by ogr2ogr and I can see that empty geometries are wrotten like that : Pline 0

Pen (1,2,0)

It seems that the syntax should be : none

Regards

Change History

03/07/08 11:36:29 changed by warmerdam

  • keywords set to mitab midmif.
  • owner changed from warmerdam to dmorissette.
  • component changed from default to OGR_SF.
  • cc set to warmerdam.

Daniel,

I presume this is an MITAB issue, so would you be able to take it? If not, reassign to Mateusz.

03/07/08 11:41:19 changed by dmorissette

I suspect what happens is MITAB gets a LineString? geometry with 0 vertices in it. Is a linestring with 0 vertices really a valid geometry? Should the shapefile driver not return a null geometry in this case?

BTW, MITAB already handles null geometries properly and will write then as NONE in the .MIF file. I could catch the case of 0-vertices LineString?, but if we go there we need to validate all geometry types which is a mess and I doubt all drivers do that.

What do you think Frank?

03/07/08 12:26:45 changed by warmerdam

Hmm. I'm not sure that it is unacceptable for a driver to return zero vertice line strings or not, though it is quite questionable.

But I would still think that it would be prudent for the MITAB driver to avoid writing such a geometry if it is going to mess up mapinfo.

03/07/08 14:45:06 changed by dmorissette

  • milestone set to 1.6.0.

The single case of a 0-vertice linestring in MIF output is fairly easy to catch and fix (a couple of lines of code), but if we declare that empty geometries are acceptable input then we need to scan the input geometries for all the following as well:

  • linestrings with < 2 vertices
  • linearrings with < 3 vertices
  • multipolygons/multilinestrings with one or more empty rings or linestrings
  • multipolygons/multilinestrings with 0 rings or 0 linestrings
  • multipoints with 0 points
  • collections with 0 elements
  • collections which contain any of the above

If those cases are acceptable input, we presumably don't want any of them to trigger a fatal error (we want to write a NONE geometry instead). This means that this check needs to happen before we determine the type of feature to write and enter the write function, which means scanning the geometry components twice: once to detect invalid components and once to do the actual write. Ugly and useless overhead when we could simply produce a fatal error and declare empty geometries as being invalid.

I'll add this one to my list. Please bug me again if you don't see any activity in a little while.