very small transformation errors

[anna123]

I have a shapefile in WGS84 and I need that this is topological correct - in our case there shouldn´t be any overlaps or gaps between adjacent parcels. To check this I needed to project the shapefile to a UTM projection and then prior importing to our database I transformed it again to WGS84. With this process - without changing any geometry - ogr is producing very small overlaps between the geometries in our shapefile and our database table. The overlaps are smaller than 1mm.

[Even Rouault]

In order to reproduce, you should provide a sample dataset with the exact commandline you've used, but I'm afraid there's nothing to do about that. It must be the combination of "natural" numerical precision loss and possibly the non-perfect invertability of the reprojection involved. And if there's something to fix, I think that should rather be in PROJ.4 where the actual reprojection occurs.

[Even Rouault]

Closing due to lack of feedback from reporter. Please reopen if you can provide the above mentionned information.

[anna123]

data

[anna123]

Here is some data that I used and with which we had that problems. I used the following command to reproject:

ogr2ogr -t_srs EPSG:32647 projection_test.shp noDB_Import.shp

[Even Rouault]

Reprojection isn't always an inversible operation, and even if it is sometimes, floating point numbers have a limited precision, so it is expected that there will be a (small) transformation error when coming from A to B, and then B to A.

ogrinfo noDB_Import.shp -fid 1 -al :

  POLYGON ((101.073420667591691 20.662438471906121,101.073216087003999 20.6626962828554,101.073217602388993 20.662957302732899,101.073727939701683 20.662938011169377,101.073843942885688 20.662710093280108,101.073723779255687 20.662709263529869,101.073595549365692 20.662416409509827,101.073420667591691 20.662438471906121))

ogr2ogr -t_srs EPSG:32647 projection_test.shp noDB_Import.shp -overwrite
ogr2ogr -t_srs EPSG:4326 projection_test2.shp projection_test.shp -overwrite

ogrinfo projection_test2.shp -fid 1 -al:

  POLYGON ((101.073420667591478 20.662438471905048,101.073216087003786 20.662696282854334,101.07321760238878 20.662957302731829,101.07372793970147 20.662938011168311,101.073843942885475 20.662710093279038,101.073723779255474 20.662709263528807,101.073595549365479 20.662416409508758,101.073420667591478 20.662438471905048))

Closing as wontfix, since to the best of my knowledge, there's no way of fixing this (unless you have an idea!)

[anna123]

is there a possibility to limit the amount of the decimal places? For me this would be a solution - a parameter with which you could limit the decimal places. Or is there already a possibiltiy?

[Even Rouault]

Some text based formats have a creation option to limit the number of decimal places, but for shapefiles whose coordinates are stored as IEEE754 doubles (binary), this doesn't make much sense. And I'm not sure how it will solve your problem : it would require to modify your input dataset, but I may miss something. Perhaps you could bring that issue as a discussion on the gdal-dev mailing list. Much more people are reading it than a bug tracker.