Error: ???line string or poly boundary is self-intersecting??? error,

[Anonymous User]

Original User: Jamal432@gmail.com

Error: �??line string or poly boundary is self-intersecting�?� error,

Copying the features of the attached layer to a file geodatabase layer works fine. If these features are copied to an enterprise geodatabase layer an error is generated �??line string or poly boundary is self-intersecting�?�

[ATTACH=CONFIG]33267[/ATTACH]

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"?


Best

Jamal

[Anonymous User]

Original User: nidhinkn

Run 'Check Geometry' and 'Repair Geometry' tool on the Feature Class.

All spatial types have their own accessor functions and use their own shape verification rules.
Therefore, to determine the steps required to check for shape validity of third-party spatial types, refer to the appropriate database spatial type documentation.

For the Esri ST_Geometry validation rules, see Geometry validation on tables containing ST_Geometry columns.

[VinceAngelo]

Why the enterprise geodatabase layer doesn�??t accept self-intersecting features while the file geodatabase layer does?

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.

What might be the issue here?

The line string or poly boundary is self-intersecting.

How to let the enterprise geodatabase layer accept self-intersecting features without applying "repair geometry"?

Not possible.  "Repair Geometry" exists so that shapes can be made acceptable.
The only other option is to write your own code to clean geometries (expect to
take a few months on this project).

- V

[Anonymous User]

Original User: mboeringa2010

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.

Actually, I never realized this, and this difference may represent a major headache for GIS operators using both File Geodatabases and Enterprise Geodatabases.

I would have expected File Geodatabases (or maybe it is better to say the ESRI APIs accessing them), being so ubiquitous as the "new" "import/export" format from Enterprise Geodatabases, to be just as strict as Enterprise Geodatabases on enforcing geometric integrity.

In this respect I can fully understand Jamal's questions.

[VinceAngelo]

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

[Anonymous User]

Original User: mboeringa2010

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.

[JamalNUMAN]

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.

The origin of �??roads�?� layer is CAD file and extracted by the FME. Despite the fact that the �??GeometryValidator�?� is applied in the FME, nevertheless, this appears not to be sufficient to resolve the issue of self-intersecting.

[ATTACH=CONFIG]33283[/ATTACH]

However, the challenge now is the fact that the enterprise geodatabase layer doesn�??t accept the features of the �??Roads�?� layer.

[ATTACH=CONFIG]33284[/ATTACH], [ATTACH=CONFIG]33285[/ATTACH]

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.

[Anonymous User]

Original User: mboeringa2010

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?

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).

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.

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?

[JamalNUMAN]

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?

Many thanks Marco for the input.

It appears that this is the only option that I have: to go back to the original data (which is really massive\that was just a sample) and fix it at the level of AutoCAD.

I have checked all the parameters in the FME but with no luck to have the errors fixed.

[ATTACH=CONFIG]33300[/ATTACH]
Best

Jamal

[Anonymous User]

Original User: mboeringa2010

Just keep in mind there is still a chance the self intersections are a result of the data processing workflow to get the data in the geodatabase, and not an issue in the CAD files. I would also recommend having a close look at these features in ArcGIS (e.g. by storing them in a File Geodatabase, and starting an edit session). If you know what features are being rejected, having a detailed look at the features might tell a lot (this is what I also did in the project I wrote about above).

I am also wondering if the Integrate (Data Management) tool could be of some help?...