Coordinates rounding issues: from GDB to SHP

Hi Maryse,

 

 

on what order is the rounding you're observing and what is the tolerance used in the GDB?

 

 

A specific example would help.

 

 

David

Hi Maryse,

 

 

How is the data type defined in the gdb?

 

Beside that when comparing you can always round both feature steams to the same decimal point, to avoid erranous results.

 

Hope this helps.

Hi both and thanks for your quick replies!

 

 

David,

 

 

The rounding can occur at about the 7th place behind the comma. Now about The tolerance, I'm not sure. Where do I find that out? At the moment I'm using the GDB writer as is.

 

 

Itay,

 

 

I've already tried rounding to the same decimal place (2nd place actually) but that still doesn't  solve the issue for all the features. I think the CoordinateRounder is rounding to the closest decimal, and it does not give the option to truncate only (which would be great in this instance!)

Hi Maryse,

 

 

aren't you transforming geometries before writing into GDB using a transformer extracting coordinates like the CoordinateExtractor? Since such a transformer extracts coordinates as character strings with a finite decimal places, a little change of real values may not be avoided.

 

Takashi

Hi Takashi,

 

 

Actually, I'm not transforming at all, only comparing (using ChangeDetector, CRCCalculators...). Just reading straight from the gdb and shp feature classes and comparing both datasets for changes in geometries.

 

 

The feature class from the gdb is written straight from the shp feature class on the first instance and is used as a reference.

 

 

I need to make sure no changes happened in the shp file when comparing its content with the gdb.

 

 

Maryse

Thanks a lot David! I think you're right! (http://gisintelligence.wordpress.com/2011/04/19/limiting-xyz-geometry-drift/)

 

David,

 

 

I have continue to research on the subject following your lead and here is what I've found. Features from ShapeFiles to File Geodatabases will be snapped to the default grid of the GDB (set to 0.001m in my case). This value cannot be edited for the FGDB format writer but is calculated based on the source feature coordinate system. Knowing that, I've found that if I set the CoordinateRounder on both data streams (from SHP reader and FGDB reader) to a value of 4, the feature geometries then match! Other values don't solve the issue though.

 

 

So to summarize, if you need to compare 2 streams of data coming from shp and fgdb, and you know the data should represent the same features, use the CoordinateRounder set to 4 before using the ChangeDetector on the geometries or their CRC values after stripping them from their geometries (depending on the data size; the second one is far quicker).

Hi Maryse,

 

 

thanks for following up with your findings, it is very helpful for those that stumble upon these issues later when searching the forums!

 

 

The use of a CoordinateRounder is, as you note, sometimes absolutely necessary when comparing geometries from different sources. Just be aware that there is no hard and fast rule about 4 decimal places, as that may vary depending on your data and coordinate system.

 

 

David