Why the enterprise geodatabase layer doesn�??t accept self-intersecting features while the file geodatabase layer does?
What might be the issue here?
How to let the enterprise geodatabase layer accept self-intersecting features without applying "repair geometry"?
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.
Much the way SQL databases permit invalid geometries for the purpose of
allowing the use of repair tools from SQL, there has to be some format from
which geometries are allowed to be repaired. Given the multitude of defects
for shapefiles with respect to attributes, I'm glad it's FGDB.
- V
OK, I had overlooked that aspect of using File Geodatabases... I guess importing dirty CAD data into a FGDB and using Check Geometry and Repair Geometry before loading into an ArcSDE managed Enterprise Geodatabase makes sense.
Still, you wonder if there shouldn't be a special "flag" / user settable attribute for FGDBs, allowing one to force the ESRI API's to enforce strict geometric consistency, in a manner that is fully compatible with the Enterprise Geodatabase.
What settings\configurations at the level of enterprise geodatabase layer can still be set to let it accept these features as they are copied and pasted?
In certain cases, repairing these features could cause them to get deleted. I�??m not sure if there is other way to repair them without deleting any one of them nor changing its geometry.
I think Vince already gave the answer, see this post: you really can not circumvent the strict geometric consistency checks when using ArcGIS tools to build an enterprise geodatabase (and I think that is a good thing!, there is already to much badly constructed data out there in the real world).
At some point, you really do need to get back to the original producers of the data, and have them fix it. I was once involved in a project regarding photogrammetrically derived data, that needed to be stored in a geodatabase. The system used to generate the data wasn't ArcGIS, and despite having some topology and geometry checks, failed to locate some major issues. Based on the IDs of the affected geometries, the data could be send back to the operators of the system, to adjust it there and fix the issues.
By the way, I noticed in the screenshots, that FME seems to offer some user configurable parameters for the different checks. Did you have a look at these? Maybe adjusting parameters fixes most of the issues?