OGR crashes on OGC sample MIF files

[Markus Neteler]

Frank,

today I tried GRASS 5.1's v.in.ogr with sample MIF files from OGC.
http://www.opengis.org/techno/interop/
 -> Normal.mif
 -> World.mif

v.in.ogr crashed on both (which can be a GRASS problem). But
also ogr2ogr crashes:

ogr2ogr -f "ESRI Shapefile" normal.shp Normal.mif
ERROR 1: Attempt to write non-point (LINESTRING) geometry to point shapefile.
ERROR 1: Terminating translation prematurely after failed
translation of layer Normal

ogr2ogr -f "ESRI Shapefile" world.shp World.mif
Segmentation fault

strace ogr2ogr -f "ESRI Shapefile" world.shp World.mif
[...]
write(7, " Zimbabwe                      H"..., 330) = 330
_llseek(7, 72507, [72507], SEEK_SET)    = 0
write(7, " Poland                        W"..., 330) = 330
_llseek(7, 69632, [69632], SEEK_SET)    = 0
read(7, "0039075   7634103   11841460    "..., 4096) = 3205
write(7, " Belarus                       M"..., 330) = 330
_llseek(7, 0, [0], SEEK_SET)            = 0
--- SIGSEGV (Segmentation fault) ---
+++ killed by SIGSEGV +++

As a proof of concept it may be nice to have OGR accepting these
sample files (perhaps they are odd, though).

Best regards

 Markus

[warmerdam]

Markus, 

I was unable to reproduce this crash.  There was a bug in OGR's Shapefile
driver yesterday which could cause a crash on exit.  Was you GDAL build built
from recent source (last couple days)? If so, update and try again.

However, the problem with trying to convert Normal.mif to a shapefile is
expected.  Normal.mif contains several different types of geometry ... point, 
line and polygon.  Shapefiles can only support a single type of geometry per
shapefile.  however, this shouldn't be responsible for the crash ... it should
just mean that some geometries are lost in translation. 

Let me know if the bug persists for you.  You may need to build with debug
into and provide a traceback since I can't reproduce the crash.

[neteler@…]

Frank,

thanks for trying. My last update was done 3 hours ago, but I didn't
run 'make clean' (I think the DEPENDENCIES should catch that).

I'll retry from a fully cleaned OGR.

Markus

[warmerdam]

Markus,

While ideally any system should rebuild needed files when an include file
changes, it has been my experience that this results in huge amounts of 
needless re-compilation everytime I add a prototype, or fixes a formatting
error in an include file.  To avoid this I build no dependencies on include
files into GDAL and expect developers to do clean builds when it is likely that
core classes have changed. 

Error prone, but less of a drag on development than the alternative IMHO. 

[neteler@…]

Frank,

that's fine with me of course (due to my ignorance 
I just wasn't aware of that).

After full clean and recompilation no more crashes.

Best regards

 Markus

PS: Just FYI:
v.in.ogr finds a few duplicate centroids in "World.mif"
but that will be related to the data. Then the new v.clean
wipes them successfully away.

WARNING: 2. centroid found in area 405
WARNING: 2. centroid found in area 494
WARNING: 3. centroid found in area 494
WARNING: 4. centroid found in area 494
WARNING: 5. centroid found in area 494
WARNING: 6. centroid found in area 494
WARNING: 7. centroid found in area 494
WARNING: 2. centroid found in area 611