2

We have a serious problem with QGIS 2.18. We do design for telecom and we have recently moved from MapInfo to QGIS. We receive MapInfo TAB files from Client and Open them in QGIS. After several days of design, all of sudden QGIS Acts weirdly and it moves the features to random places. this picture shows where the feature suppose to be(it was there till yesterday)

enter image description here

this is the new place some of the features moved

enter image description here

As the second picture shows all the features have random(invalid coordinates)

Is it something we are doing wrong in QGIS?

Improve this question
10
  • Do you have the option to use (or test) QGIS 3.2? (it has many bug fixes)
    – Mapperz ♦
    Commented Oct 4, 2018 at 0:46
  • Is there still a point a the proper location? I have seen this behavior before with DB views (not tab files) having unstable IDs (i.e. not constant through time for a given feature, making the ID used for fetching the geometry a different one than the ID used for fetching the attribute table)
    – JGH
    Commented Oct 4, 2018 at 1:07
  • Some of the points stay at original coordinate and QGIS moves only some of the points. For example, if I have 300 Feature QGIS moves 40 of them to random locations and the rest are fine.
    – Ehsan Aliverdi
    Commented Oct 4, 2018 at 1:22
  • Unfortunatly we cannot move to 3.2 as it is not LTR.
    – Ehsan Aliverdi
    Commented Oct 4, 2018 at 1:23
  • FYI: October 26th 2018 QGIS LTR will be 3.4 according to the roadmap qgis.org/en/site/getinvolved/development/…
    – Mapperz ♦
    Commented Oct 4, 2018 at 1:48

1 Answer 1

Reset to default
6

I have also encountered this problem and I was surprised how little detail is available on this.

Essentially my conclusion is that the .tab file uses MapExtreme libraries in order to process their info. This library is nearly perfectly accounted for in QGIS through ogr2ogr. However it is not perfect! As a result, sometimes in the saving process, if QGIS crashes, it will screw up the file.

I should preface this by saying that this issue is rare. It doesnt happen often and in general QGIS has little to no problems working with .tab files. However when this error occurs, it is one of the most frustrating and annoying issues.

Here are some things I have found which seem to help avoid this issue in the future:

  1. Ensure your .tab has only 4 files. You should only have a .dat, .ID, .MAP and .TAB. If you have any other files associated, the chance of data corruption increases significantly. You can open your .tab file in QGIS or MapInfo and save as a copy. The new file should only have 4 files.

  2. Only open the .tab file in one instance of QGIS. If you are working on a network where multiple people might want to look at the data in a .tab file, it is better to use .mif for just reading data. The .tab format can only accept read and write through one open instance. If you open it multiple times and multiple people try to save on top of each other, there is a chance that the data will be corrupted.

  3. When there are unsaved changes in any open layer, do not give QGIS any heavy processing tasks. Basically, you are using QGIS 2 which is much more unstable than QGIS 3. Please switch to QGIS 3.4 when it is released. They are both completely backwards compatible (except for some plugins) and stability is greatly improved. If QGIS crashes when a layer is in edit mode, it can close the layer without saving the changes properly. This applies to all file types. However, due to the nature of .tab files, it can result in data corruption in the .MAP file. This causes some data to be completely dislocated in space or lost. There is no easy way to recover this data.

  4. If file format is not a concern, there is a QGIS plugin which allows you to batch convert all open layers into another file type. I would advise using .gpkg or .shp. Both formats are way more stable. Also you can edit .gpkg natively in both MapInfo and QGIS.

  5. Pack the .tab file. I am not sure how to do this within QGIS. Essentially .tab files store all the table entries. With large data sets, you may need to pack the table every so often to increase processing speed. It is really easy to write a MapBasic script which will pack as many files as you want at once.

As for any resolution on this data set. I have found that if this issue ever occurs, the orientation is still maintained. As a result, you can select all the data that has moved, then use the "move" tool and collectively move it back to a base point in another layer which has the correct coordinates and snap it. This will result in all the selected points moving and snapping back to the correct location.

If you dont have a base coordinate, then I am not sure what the solution is.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.