I am connecting a PostgreSQL database to ArcGIS Pro and it connects but when I attempt to open the attribute table I receive a "Shape Integrity Error" and cannot view it.

2898
10
02-27-2019 02:19 PM
PaulLomas
New Contributor

I am able to view the attribute table without any errors when I connect the database using Arcmap.

Any idea on the issue?

Thanks in advance

10 Replies
EarlMedina1
Occasional Contributor III

Which versions are you working with? Is that a PostGIS database by any chance?

Without further details, I surmise the problem is related to validation: Database data and ArcGIS—Help | ArcGIS Desktop 

0 Kudos
PaulLomas
New Contributor

I am working with ArcGIS Pro 2.3.0 and yes it is a PostGIS database.

0 Kudos
EarlMedina1
Occasional Contributor III

All right. I think that you're running into a flavor of this limitation: BUG-000119406: The error message, "Shape Integrity Error" is return.. 

The root cause would appear to be the validation checks. The easiest workaround is to use a version of ArcMap lower than 10.6.1 or a version of ArcGIS Pro lower than 2.2.

Alternatively, you could import that same data into a SDE-enabled database (Enterprise Geodatabase) and it should load without issue.

FlavieMoraux
New Contributor III
I have the same probleme, I am working with :
- ArcGIS Desktop 10.6.1 and PRO 2.2.
- BDD PGSQL 9.5/9.6 and PostGIS 2.4/2.5
For information data have been corrected in PostGIS (St_MakeValid) and are now valid for PostGIS (ST_IsValid).
What are the new rules mentioned in the BUG?
Having new tables created that work okay makes sense as they are using newer rules

Thanks,

Flavie

0 Kudos
MarcoBoeringa
MVP Regular Contributor

Have you also attempted to test the integrity of the geometries with ST_IsSimple? ST_IsValid does not garantuee that there are no self intersections. I would recommend double checking with both ST_IsValid and ST_IsSimple, unless you have a specific reason to allow self intersections in another application that creates or manages the original data:

https://postgis.net/docs/ST_IsSimple.html

Note that polygons are considered by definition simple, according to this help page, so this advice is especially for line feature classes:

https://postgis.net/docs/using_postgis_dbmanagement.html#OGC_Validity

0 Kudos
FlavieMoraux
New Contributor III

Marco Boeringa thanks for your advice, but it's not better.

All my features are simple ("NOT ST_IsSimple" return nothing).

Instead of make data valid (ST_MakeValid) I delete them. But ArcMap and ArcGIS Pro always throw the same error.

0 Kudos
FlavieMoraux
New Contributor III

Hy,

With ArcGIS Desktop 10.7.1 problem still continues. After investigation in my case it seems that the problem is related to repeated points (sample with last point) :

POLYGON((2.52987022611831 48.9948072225487, ... ,2.52987022611831 48.9948072225487,2.52987022611831 48.9948072225487))

I don't understand why it is a problem in ArcGIS because this case of geometry is well-formed for PostGIS (test is successful with method ST_ISVALID).

The only workaround I can think is to create a view in wich I remove repeated points. Indeed if a remove repeated points (with method ST_REMOVEREPEATEDPOINTS) then error no longer occurs.

Has anyone encountered this error? An other idea/workaround ?

Thanks,

Flavie

0 Kudos
MaxSquires1
New Contributor

Good morning,

@FlavieMoraux, I think the only alternative to doing this type of validation appears to be using Esri tooling to get the data into the database in the first place.  that type of loading performs the validation. unfortunately, for me this is not an option. i imagine is is not an option for you either.   after the data is in PostgreSql i can use Esri tools, but this adds a lot of overhead.

I, too, am having an issue with PostgreSql and usually this removal of repeated points works for me (st_removerepeatedpoints(geom), along with zero buffering (st_buffer(geom, 0)), and normalizing the geometry (st_normalize(geom)) - combined as follows:

 

st_buffer(st_normalize(st_removerepeatedpoints(geom)), 0) AS shape

 

unfortunately, even with this nasty conversion, Esri still complains about a 'shape integrity error' when opening the attributes of the output table.  ST_IsValid returns true for every geometry in my source table.

 

i cant think of another solution but Esri was able to do something proprietary prior to version 10.6 (according to the referenced bug) and i can't figure out what it was.   the problem i have is that my only 'solution' that works is to eliminate the rows from the selection statement that are causing me problems still, which isn't really a solution since that eliminates 20 percent of my data.  

 

my theory, as of yet unproven, is that the nesting of rings in polyons  of the features from the source (which is continually appended to the the PostgreSql table) is done in different orders (i.e. clockwise one day, and counter-clockwise the next).  I would like to find a way to check the order of the digitization (the general direction that the points x,y coordinates of a polygon appear in space) and reverse it if it is not 'correct'.   This gis.stackexchange discussion talks about the nested rings issue. 

 

creating a temporary table and writing the data to a file geodatabase using the open file geodatabase api and gdal is another thing i plan on trying as well.  having the data in a file geodatabase allows the 'check geometry' or 'repair geometry' tools (arcpy) to be run against the data.  but this can only be done at the end of my processing stream - once the data is accessible by Esri tools.  it may be that the file geodatabase also enforces some kind of validation upon loading that i am not getting with the current insert method being used.

finally, i will give an example of a geometry (converted to text using st_astext(geom)) that is generating this error.  I shared this with Esri and they confirmed that by translating it back into a binary geometry, they could not load the data into the Esri platform without a shape integrity error.  Despite all of the above, the following does not have an interior ring so i am totally at a loss here.

 

MULTIPOLYGON(((-88.7572933879595 28.8780531087591,-88.937 28.691,-89.175 28.63,-89.399 28.577,-89.712 28.693,-89.828 28.916,-90.102 28.755,-90.54 28.711,-90.5583097345133 28.711,-90.91 29.73,-91.4 30.64,-91.95 31.21,-92.53 31.44,-93.02 31.32,-93.23 30.94,-93.04 30.41,-92.9128417481541 29.3291548593095,-92.9128417481541 29.3291548593095,-93.243 29.441,-93.588 29.43,-93.777 29.35,-93.961 29.348,-94.1355988849544 29.2758706245762,-94.53 31.02,-94.17 31.67,-93.66 32.16,-93.1 32.4,-92.31 32.36,-91.67 32.04,-90.45 30.95,-88.7572933879595 28.8780531087591,-88.7572933879595 28.8780531087591)))

 

 

I'd appreciate any tips anyone on this thread has as to how to resolve this issue and whether you think there is any risk to doing the geometry manipulation described here to the validity of the data.

 

Thanks

 

Max

0 Kudos
FlavieMoraux
New Contributor III

Thanks for your feedback.

I am talking with french support who also suggested to use verification and validation tools. But like you said data must be stored in shapefile ou inside FGDB, not our case ‌:(‌

Just in case I tried to test these tools, but I have a problem with this solution. Before I need to copy data from ArcMap inside à FGDB… copy fails at first geometry "in error" ! So i can't verify and validate anything. I haven't yet tested copy WITH GDAL

I’m curious, copy is working for you with your data ?

Flavie

0 Kudos