search

qgis / QGIS

QGIS is a free, open source, cross platform (lin/win/mac) geographical information system (GIS)
https://qgis.org
GNU General Public License v2.0
10.52k stars 2.99k forks source link

Corruption of MapInfo TAB: Saving shifts objects far away #42077

Closed VEWA-Patrice closed 3 years ago

VEWA-Patrice commented 3 years ago

I observed corruptions since months very similarly to the issue described in https://gis.stackexchange.com/questions/297868/qgis-moving-some-features-randomly but now I've found a reproducible situation in which it happens, with a TAB and a matching QGIS QGZ file: Once adding just a point and trying to save the layer, a part of the surrounding points are moved far away.

As the TAB is confidential, please contact to me to obtain it if needed for the analysis.

gioman commented 3 years ago

As the TAB is confidential, please contact to me to obtain it if needed for the analysis.

@VEWA-Patrice send me a sample project + data at giovanni DOT manghi AT gmail DOT com

gioman commented 3 years ago

@VEWA-Patrice I can't investigate deeply what is going on... but it seems to me that your original layer has some kind of corruption, in fact if you create a copy of it both with QGIS or from the command line you get a layer that does not show the described anomaly, i.e.

ogr2ogr -F "Mapinfo file" -t_srs EPSG:4326 copy.TAB my_corrupted_layer.TAB

Note that I specified the copy to have the 4326 CRS, something that your original layer has not well specified (and that maybe is part of the problem).

I would say that this is a "won't fix" as there isn't anything to fix on QGIS side.

VEWA-Patrice commented 3 years ago

That is an interesing sentence: "something that your original layer has not well specified". MapInfo, MS Access and QGIS (and in the past GBM Mobile) are working on that layer, so one of these is/was corrupting it. I used the command you recommended which destroyed charset dependant strings which can be easily restored from a backup via MS Access. Transporting the layer through QGIS -> MapInfo -> MS Access and backward again, but now QGIS can save new objects again. I'll check and observe it the next hours. @gioman Thank you for your efforts!

The reason for involving MS Access is that the original object database and VBA script had been developed in here since the 1990s. MapInfo was added as geo database since 2009 which has an interface to save the TAB with an ACCDB. So far I have not found a replacement for the TAB format. I tried GPGK, but did not find an ODBC driver that enabled more than reading in MS Access, it could not write. I understand this is a different topic, but could be a workaround to avoid any future corruption: Does anyone have an idea for a format, that can be processed in both MS Access and QGIS?

gioman commented 3 years ago

I used the command you recommended which destroyed charset dependant strings

@VEWA-Patrice the command can be tweaked with some flag/parameters in order to keep those special chars. Mine was just a simple example.

If I have to make a bet, i would say that is Access that is corrupting your data, but I say this just because i don't like Access ;)

Does anyone have an idea for a format, that can be processed in both MS Access and QGIS?

maybe you should consider moving to a proper spatial database, like PostgreSQL, if is accessible with LibreOffice Base it should be also by MS Access.

nyalldawson commented 3 years ago

This is a known limitation of the mapinfo tab file -- it uses a precision which dictates the precision of coordinates stored in the file. See https://gdal.org/drivers/vector/mitab.html#creation-issues

The solution is to use a different format if this limitation is affecting your workflow.