Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have something I'd like to discuss, I'll try to explain it first, why it's important, and I'll explain how ArcGIS handles the issue, which I think is a good way to handle it. Finally I'd like to know what you think.

The issue is this:

Many GIS editing software packages can edit many data formats. Each data format handles precision differently, for example, SHP format stores a double precision coordinate. SQL Server does the same, a 64 bit double. PostGIS seems to do the same. MapInfo's .TAB format apparently uses a 21 bit int to store a point as a linear interpolation between bounding coordinates. There will obviously be others. Editing software may have internal data structures whilst carrying out operations, and will then write to the end data store e.g., MapInfo linked tables store a value on a (for us, a 1 mm) grid, and push to the database, which stores it as a double precision float.

If you edit in mixed environments, then you can start getting inconsistencies where a feature with coordinates that were created off a grid (with doubel precision) are then edited in software that uses a grid (in mm precision). For example, I create a layer in SQL Server, add features in QGIS, then edit one of the vertices of one feature in MapInfo, that feature now gets all its coordinates snapped to the 1 mm grid, which means it doesn't align to neighboring features any more (the errors in my test were ~0.2 mm).

ArcGIS handles precision when using a database layer by keeping track of xy_resolution (see here for more on xy_resolution and xy_tolerance) explicitly. This seems the best way of handling it, since the coordinate precision is explicitly controlled (the default is 1 mm). When editing in MapInfo with carefully specified bounds you snap to a 1 mm grid implicitly, so this is sound too.

My question is:

How do you or your organisation handle editing in order to maintain topology, keeping in mind different sources with different precisions?

And as a secondary question, should editing tools, such as QGIS, include an option to use a defined coordinate precision or should we do it on data format, with a database trigger or MapInfo's bounds?



--Further Details follow:

I have two images, one of the shape I'm editing, one of the error introduced if editing with different precisions. I also have numbers showing what is being written to SQL Server when you move the central point in two different softwares.


POLYGON ((520191.61484399455 5259827.5143016046, 521146.0563152277 5259917.96005114, 521015.6907808886 5260649.8136086222, 520329.84600000043 5260729.1830000039, 520191.61484399455 5259827.5143016046))
POLYGON ((521146.0563152277 5259917.96005114, 522006.03708566393 5259775.4479602445, 522021.9278674855 5260443.1099995337, 521015.6907808886 5260649.8136086222, 521146.0563152277 5259917.96005114))
POLYGON ((521938.09510281781 5258959.9356564963, 522006.03708566393 5259775.4479602445, 521146.0563152277 5259917.96005114, 521194.71867216442 5258970.2782813907, 521938.09510281781 5258959.9356564963))
POLYGON ((521194.71867216442 5258970.2782813907, 521146.0563152277 5259917.96005114, 520191.61484399455 5259827.5143016046, 520191.61484399455 5259827.5143016046, 520287.61066861876 5259041.6976504158, 521194.71867216442 5258970.2782813907))


POLYGON ((520191.615 5259827.514, 520842.732 5259437.788, 521015.691 5260649.814, 520329.846 5260729.183, 520191.615 5259827.514))
POLYGON ((520842.732 5259437.788, 522006.037 5259775.448, 522021.928 5260443.11, 521015.691 5260649.814, 520842.732 5259437.788))
POLYGON ((521938.095 5258959.936, 522006.037 5259775.448, 520842.732 5259437.788, 521194.719 5258970.278, 521938.095 5258959.936))
POLYGON ((521194.719 5258970.278, 520842.732 5259437.788, 520191.615 5259827.514, 520287.611 5259041.698, 521194.719 5258970.278))

An image of a polygon that demonstrates errors

Polygon that was editied, the central point was moved. An example of an error

The resulting difference after editing in MapInfo, the dataset is no longer topologically correct.

share|improve this question
of the vertices of one feature in MapInfo does this apply if you use a live linked SQL Server table? – Nathan W Aug 14 '13 at 3:10
Hi Nathan, I haven't checked that, but I will. (I did ask that question myself! Hold on...) – Alex Leith Aug 14 '13 at 3:11
Scratch that, the precision is not conserved using live tables. Editing a live table seems to use the same bounds-defined precision. – Alex Leith Aug 14 '13 at 3:21
Check my comment above, I changed my mind! There's a <0.5 mm error introduced after editing with MapInfo using a live table non-cached. – Alex Leith Aug 14 '13 at 3:27
Bugger. Worth a shot :) – Nathan W Aug 14 '13 at 3:28

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Browse other questions tagged or ask your own question.