MapInfo driver that reports a layer with geometry when there is none ?

[lpercich]

When using ogr2ogr 1.9dev with output driver = PGDump to convert a MapInfo tab file with no geometry, the following problems arise under different combinations of --config PG_USE_COPY and -lco CREATE_TABLE:

ogr2ogr --config PG_USE_COPY YES -append -progress -f 'PGDump' out.sql in_non_geometric.TAB -lco CREATE_TABLE=ON

CREATE_TABLE=ON always fails generating an AddGeometryColumn() instruction.

PG_USE_COPY YES always generates null (\N) geometric values and tries to insert them in the non-existent wkb_geometry column;

PG_USE_COPY NO works fine, recognizing there's no geometric column, even if issued along with CREATE_TABLE=ON.

The attached test_OGR_PGDump_nogeom.zip contains a test non-geometric MapInfo table, a bash script with the 4 different invocations and the resulting sql files.

[lpercich]

Test data and script

[Even Rouault]

Several comments/questions :

• You say "CREATE_TABLE=ON always fails generating an AddGeometryColumn() instruction." --> In the log you've included, on the contrary I can see the AddGeometryColumn() instruction. You probably meant CREATE_TABLE=OFF, didn't you ? But even in the CREATE_TABLE=OFF case, it is logical that AddGeometryColumn() doesn't appear, because it modifies the table structure. The doc is perhaps not explicit enough by CREATE_TABLE=OFF is intented to disable the writing in the sql of both the CREATE TABLE () and SELECT AddGeometryColumn().

• I think that the tests done with CREATE_TABLE=OFF should work fine if you append the data to a table that was created by the OGR PGdump driver with the CREATE_TABLE=ON. That is to say that even if there's no geometry to insert, it is fine to insert \N if the wkb_geometry column exists in the table definition. Obviously if you have created the table structure by your means, the driver cannot be aware of that...

• In your particular example, the original MapInfo data is reported as having a wkbUnknown geometry type by the MapInfo driver, which means that features can have a geometry of any type (this is different from wkbNone which means no geometry at all), so it is expected that the PGDump driver creates a geometry column. It cannot know in advance that none of the features have indeed any geometry.

So, all in all, I think the driver behaves consistently.

[lpercich]

Sorry, it's my bad english. I meant that I consider a failure when the driver generates an AddGeometryColumn() if the source MapInfo Table has no geometry column. I'd expect that AddGeometryColumn appears only when CREATE_TABLE=ON and source table has a geometry column.

I'm trying to insert into an already generated empty PG table, mainly because I'd prefer not having FIDs and geometric columns created for tables which already have Primary keys and don't have geometries.

So maybe the problem lies with the MapInfo driver? The original MapInfo table has no geometric column at all, so I would expect a wkbNone...

Have you noticed that COPY and INSERT behave differently? INSERT realizes that there's no geometry to insert, while COPY copies null.

Even if I have a lot of experience programming in MapInfo, I'm not skilled in C++; I'll try to have a look at the source code anyway. Please let me now if I can be of any help.

Thanks in advance

Sig

[Even Rouault]

ok, overall, I think there's no issue in the PGDump driver. The difference of behaviour between COPY and non COPY mode is expected : in COPY mode, we must fill every field, even when it is unset. Whereas in non COPY mode, we can only specify set fields.

As a workaround you can still try specifying -nlt NONE to ogr2ogr. This will force the new layer to have no geometry column.

So the remaining problem, if confirmed, seems to be in the MapInfo driver that reports a layer with geometry when there is none. CC'ing the mapinfo experts if they want to have a look at it ;-)

[lpercich]

Replying to rouault:

ok, overall, I think there's no issue in the PGDump driver. The difference of behaviour between COPY and non COPY mode is expected : in COPY mode, we must fill every field, even when it is unset. Whereas in non COPY mode, we can only specify set fields.

You're right. I cheched with a geometric MapInfo table having one row with a null geometry - the insert instruction doesn't make an explicit insert of null into geom.

As a workaround you can still try specifying -nlt NONE to ogr2ogr. This will force the new layer to have no geometry column.

The -nlt NONE option works fine! Should we state in the documentation that it's better always specifying the layer geometric type (and NONE when no geometry) even if appending to existing layers?

So the remaining problem, if confirmed, seems to be in the MapInfo driver that reports a layer with geometry when there is none. CC'ing the mapinfo experts if they want to have a look at it ;-)

Thanks! I'll leave you alone for a while and start annoying them :))))

Thanks again for your patience

Sig

[Jukka Rahkonen]

I tried to test what happens now with GDAL 2.0-dev on Windows 64. Result: ogrinfo crashes with command

ogrinfo nogeomtest.tab

By crash I mean that I get a Windows message telling that ogrinfo.exe stopped working.

[Even Rouault]

Hum, I got no crash on Linux or my custom Win32 build. But there's a debug trace that triggered a null pointer that could cause issues with some C runtime libraries. I've fixed it in r28134 "OGRMILayerAttrIndex::LoadConfigFromXML(): fix potential crash when pszMetadataFilename was null (related to #4031)", but I'm not sure that the reason for the crash you observe. If that's the cause that crash should have occured with any earlier version I think

[Jukka Rahkonen]

No crash now with recent GDAL 2.0-dev on 64-bit Windows 7.

Schema still shows a geometry column of type Unknown (any).

ogrinfo nogeomtest.tab -al
INFO: Open of `nogeomtest.tab'
      using driver `MapInfo File' successful.

Layer name: nogeomtest
Geometry: Unknown (any)
Feature Count: 5
Extent: (-1000000.000000, -1000000.000000) - (1000000.000000, 1000000.000000)
Layer SRS WKT:
LOCAL_CS["Nonearth",
    UNIT["Meter",1.0]]
cod: String (16.0)
ord: Integer (0.0)
descrizione: String (254.0)

It is a corner use case to convert plain attribute data with GDAL which after all is Geospatial Data Absraction Library. Formats like shapefile do not support such geometry-less option at all even for Mapinfo users joined attribute tables are well known. The described workaround to use -nlt NONE works well and is simple. I would be ready for closing this ticket but I let the Mapinfo minded developers to decide.

I wonder if OGR drivers behave in consistent way with reporting the no-geometry layers. At least CSV driver and Spatialite are reporting layer as Geometry: None which feels like a correct option for Mapinfo driver as well.

ogrinfo test.sqlite -sql "select * from nogeom"

Layer name: SELECT
Geometry: None
Feature Count: 317
Layer SRS WKT:
(unknown)

[Even Rouault]

There's no (efficient) way with mapinfo .tab to know if all features have no geometries. Closing as wontfix