Geodatabase error: The operation was attempted on an empty geometry.

21270
16
01-05-2018 01:29 AM
by Anonymous User
Not applicable

In the Server Manager logs - what does this mean? 

How do I fix it? 

SEVEREJan 5, 2018, 9:20:36 AMGeodatabase error: The operation was attempted on an empty geometry.Administrative_Boundaries/Local_Authority_Districts_December_2015_Boundaries.MapServer
SEVEREJan 5, 2018, 9:20:35 AMGeodatabase error: The operation was attempted on an empty geometry.Administrative_Boundaries/Local_Authority_Districts_December_2015_Boundaries.MapServer
SEVEREJan 5, 2018, 9:19:54 AMGeodatabase error: The operation was attempted on an empty geometry.Administrative_Boundaries/Local_Authority_Districts_December_2015_Boundaries.MapServer
SEVEREJan 5, 2018, 9:18:52 AMGeodatabase error: The operation was attempted on an empty geometry.Electoral_Boundaries/Westminster_Parliamentary_Constituencies_December_2015_Boundaries.MapServer

Thanks

Matt

16 Replies
PanagiotisPapadopoulos
Esri Regular Contributor

maybe the feature class has geometry errors.

 

You try to do  a check geometry with arctoolbox.

Checking and repairing geometries—Help | ArcGIS Desktop 

JoeBorgione
MVP Emeritus

Check geometry and repair geometry tools do not work on an enterprise (aka SDE) data base.  It appears you are dealing with polygon features: sort them by area and delete those where it =  0 (zero).  You'll notice that those where the area = 0 no other attributes are populated as well.  I've referred to these as "ghost" features and they appear from time to time and always blamed the occurance on an undocumented feature somewhere in the enterprise/sde environment, but I could be wrong...

from the link provided:

The exception to this is when the data is loaded to an ArcSDE geodatabase. Before it is stored in the feature class, each record's geometry is checked for geometry problems and repaired if necessary.

That should just about do it....
JoshuaBixby
MVP Esteemed Contributor

Joe, you might be interested in one of my past blog posts:  /blogs/tilting/2015/05/29/whats-in-your-feature-class-nothing-null-or-empty .  The fact is Esri doesn't consistently handle missing or empty geometries.  When a geometry is optional and missing, some tools leave the SHAPE field NULL while others create an empty geometry and insert it into the field.  Even on the retrieval side, different tools handle empty geometries differently.

Just like an empty set is a valid set, and actually a critically important set in mathematics, an empty geometry is a valid geometry.  Esri's poor support and handling of empty geometries is akin to having them support Roman numerals instead of Arabic numerals.  Who needs to use zero, right?

From a practical perspective, I tell users in my organization to make geometry required when working with Esri's systems.  Even though an empty geometry is a geometry, most users have no idea how to make them, so requiring them prevents some of the inconsistent behavior when there is a missing geometry.

ChristopherCounsell
MVP Regular Contributor

ArcGIS Pro 2.7 onward now supports checks in some enterprise databases and some repairs
https://pro.arcgis.com/en/pro-app/2.8/tool-reference/data-management/check-geometry.htm

0 Kudos
JayantaPoddar
MVP Esteemed Contributor

The error message might not be enough to reach to a conclusion.

If you are using enterprise geodatabase, what is the version of ArcGIS Server and the Geodatabase?

Under what circumstances, are you receiving the stated error message?

Meanwhile, I would also suggest you to contact Esri Tech Support for resolving the issue.



Think Location
WWalker
New Contributor III

Just out of curiosity, do these feature classes participate in a topology?

0 Kudos
DougGreen
Occasional Contributor II

I found this as I was getting the same exact error in Desktop. I use backend STIsEmpty(), STIsValid(), STIsSimple() as mentioned in previous comments. All were valid and simple, none were empty. We are on 10.5. I have discovered something after thorough testing. I have narrowed it down to an issue with Enterprise GDBs in SQL server (haven't tested in Oracle etc).  Place two feature classes with non-overlapping extents from an EGDB in a map. Run "Select by Location" in the following scenarios:

  1. Select one feature in FC1 and then run "Select by Location" selecting features from both FCs within a distance that will not reach features in FC2.
    1. Error occurs
  2. Select one feature in FC1 and then run "Select by Location" selecting features from both FCs within a distance that will reach features in FC2.
    1. Error does not occur
  3. Select one feature in FC1 and then run "Select by Location" selecting features only from FC1 within a distance that will not reach features in FC2.
    1. Error does not occur
  4. Select one feature in FC1 and then run "Select by Location" selecting features only from FC1 within a distance that will reach features in FC2.
    1. Error does not occur

Repeat the inverse of this (swapping FC1 with FC2 in each scenario) and you will get the same results.

Conclusion: Error is produced when selecting features from both FCs when the search radius does not intersect the second FCs extent.

If this same test is performed with the feature classes in a File GDB, no errors are shown. I have called and I'm waiting for a call back from Tech Support. I have tested this in a 10.4.1 and 10.5 GDB. I don't know if perhaps it is fixed in a newer release.

JoshuaBixby
MVP Esteemed Contributor

You state:

I use backend STIsEmpty(), STIsValid(), STIsSimple() as mentioned in previous comments.

I assume this statement means you are running SQL outside of ArcGIS to test the features?  If so, are you running the queries against the base tables of the version views?  I ask because if this is versioned data, it might be you haven't run those commands against the same data set that the took is using in ArcGIS.

DougGreen
Occasional Contributor II

Joshua,

I am running these queries in SSMS. These two feature classes are not versioned but on feature classes that are, I append "_evw" to the end of the name to select from the multi-version view of the table/featureclass.

Good thought though.

Doug

0 Kudos