Skip to main content
Hi all,

 

 

is there a way to make sure that data from a shape file transfered to a gdb file using FME have the exact same coordinate values?

 

 

I happen to have to rounding happening in some features. This means that when I compare features from the shp and the gdb feature class, there will be some geometry discrepencies flagged up even though there should be.

 

 

I don't know when the rounding occurs (i.e. when it's written the first time to the gdb or when it's read the following time from the gdb)

 

 

Any idea? Anything I can set on the GDB writer or FeatureReader to make sure this doesn't happen?

 

 

Thanks in advance,

 

 

Maryse
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
Hi Maryse,

 

 

you will find the tolerance using ArcCatalog, look at the feature class properties. You can think of the tolerance as a sort of snapping grid: your features cannot have a higher precision than the specified tolerance, otherwise it will be "snapped" (or, rather, rounded) to the nearest point on the tolerance grid. This is a common feature of all SDE-based datasets (personal, file and enterprise geodatabase).

 

 

The tolerance can only be specified when you create the feature class, it is not possible to change it later on.

 

 

If you create the feature class with FME, you can specify the tolerance on the writer, see the help file for details.

 

 

I also highly recommend the ArcGIS help, see the section "Feature tolerances" some way down the page.

 

 

David
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

Reply