FME SDE Writer changing part sequence of Multi-part polygon on Insert?

Question

I am creating a FME script that will accept to databases (MDB file and SDE Database) and will update the SDE database if there are any changes to the MDB file. I have a CRCCalculator for both SDE and MDB file to determine if there are any changes and a UniqueIdentifier is present on both.

Its currently working but I'm noticing that when FME writes the features to the SDE database (e.g. FMEMultiArea), in some cases it changes the sequence of the parts therefore changing the area value. This will in turn change the CRC value calculated when i run the FME script again so everytime it thinks there is an update.

I'm wondering if i need to add something to prevent the writer from changing the sequence.

FME Workflow:

Sample MDB Feature:

Sample SDE Feature:

I am using SQL Server 2012 to store the data.

Answer 1

There's a piece of the puzzle that your workflow does not consider:

• Enterprise geodatabase shapes all pass though the ArcSDE API, which performs standardization of geometries (integer encoding, dropping duplicate vertices, reordering incorrectly wound rings, merging inversions into their parent ring, etc)

This impacts you in two ways:

1. The vertex ordering may be different (personal geodatabase and shapefile don't care), and
2. The vertex values exported may be shifted by up to one-half the inverse of the xyscale, zscale, and mscale associated with the feature class coordinate reference.

In order to overcome these differences, you'll need to be ready to export geometries back to personal geodatabase as part of a validation pass.

It would also help if you used standard whole number (preferably power of 10) values for xyscale (10000000 vice 4167839431.4937829), zscale (1000 vs 778658.748954) and mscale, which will round coordinates to a fixed number of places, and will make computing a CRC easier.

Answer 2

Those are great answers by Vince. I think he's spot on with how, for SDE, FME will need to possibly make changes to meet SQL Server specifications (like vertex ordering, removing duplicate points, etc).

I did want to suggest, re the grid/coordinate issue, that you try the ArcSDEGridSnapper transformer. It simulates the effects of writing to ArcSDE (in terms of grids). The help doc says:

Simulates the ArcSDE conversion on a feature by performing ArcSDE translation, scaling, and coordinate snapping. Also removes duplicate vertices resulting from snapping multiple formerly separate vertices to the same grid point. These coordinates will also be recorded in a list attribute.

So running your MDB data through that transformer will, I think, ensure it has the same settings as the SDE version, in terms of coordinate precision.

Alternatively you could try the CoordinateRounder transformer. It will obviously reduce your precision, but I'm thinking for gross matching of features it might not be an issue. The ArcSDEGridSnapper still should be the better solution.

Sadly I can't think of a simple fix for the vertex order issue. One extreme solution is writing a duplicate of all multi-part features to a separate (non-SDE) dataset, just for the purposes of later comparisons! Or you could try calculating CRC values on coordinate values (ie extract them as attributes) in which case order might not be an issue. Or round-trip all your MDB data through SDE and back, just to have it go through the same standardization process.