I have previously published a generalised question on this subject, but received only one reply.
Following is a more specific question with an actual example..
Running 10.5 on SQL Server 2016
Post https://community.esri.com/thread/112345 describes a situation where an apparently valid FGDB is copied to an EGDB and detects errors. In particular Vince Angelo states
‘The ArcSDE API enforces Clementini geometry integrity rules. It is not possible
to construct an SE_SHAPE object which does not conform to those rules. File
geodatabase and shapefile permit non-conformant rings.’
Our situation is the reverse.
If you take the following POLYGON
'POLYGON ((120.002794839062 -32.8470945869896, 120.002794613047 -32.836274112266, 119.992113708534 -32.8362742049204, 119.99211391052 -32.8470946837942, 120.002796135038 -32.8470945869779, 120.002794839062 -32.8470945869896))
And import it into an EGDB Layer specified with ESRI defaults then it does so without error. (Using either GEOMETRY or SDEBINARY)
If you take the same POLYGON and import it into an FGDB with ESRI defaults (same as EGDB defaults) then run CHECK GEOMETRY it shows as ‘SELF-INTERSECTING’.
How can a POLYGON be valid in EGDB and yet self-intersecting in FGDB?
I accept that point 2 is ‘wrong’, but why did EGDB load not fail. (Or alternatively why did FGDB load detect self-intersection).
My conclusion from this is that the ONLY way to change data reliably is to do so via FGDB and then to save to EGDB.
This is manageable at take-up time, but will have implications going forward in that processing taking place directly on EGDB may appear to have worked, but when it is sent to a FGDB for distribution it shows up as ‘self-intersecting’.
For clarity I have included additional information in attachment
Please tell me my conclusion is wrong!
