5

I've got a large dataset in PostGIS which I've made available to an indirect colleague who's using ArcGIS. However, he can't load most of the features which have the polygon geometry type.

I've already tried using ST_MakeValid and furthermore, I've validated all features with ST_IsValid which they are.

The error message he's getting in ArcGIS is a "Shape integrity error". Does anyone have an idea what it could be? Furthermore, does anyone know a good workflow in which I can troubleshoot this myself? Since I don't have the ArcGIS software I can't verify my solutions.

9

1 Answer 1

9
+100

I have experienced similar issues, where data that is perfectly fine according to PostGIS and QGIS (tested with ST_MakeValid in PostGIS, and by loading the data in QGIS and running QGIS's geometry validity checker), still couldn't be loaded reliable in ArcGIS.

Note that the data in my case was stored in WGS 1984 (SRID 4326) "geometry" storage (so not "geography").

I finally solved it by using three strategies:

  • Run ST_Buffer in PostGIS with a tolerance of 0 after ST_MakeValid, which is a quite common practice according to what I read to solve some difficult to resolve geometry errors. In case of Polygon data, it is also recommended to create a statement including ST_CollectionExtract, with 3 as the indicator for extracting Polygon type geometry only. This avoids creating GeometryCollections.

  • Run ST_Normalize. Despite the PostGIS documentation stating this is "Mostly only useful for testing purposes", I found clear cases where putting in an extra ST_Normalize allowed data that reported a "Shape integrity" error in ArcGIS, to be suddenly perfectly readable in ArcGIS after running this command. The documentation is vague about exactly what it does though, besides reshuffling parts of a polygons, and I have difficulty understanding why it allows ArcGIS to read the data afterwards (maybe something to do with internal rings and outer shells requiring a specific order in ArcGIS?).

E.g. so a complete command, except the last recommendation mentioned below, could look like this: ST_Normalize(ST_Buffer(ST_CollectionExtract(ST_MakeValid(<GEOMETRY_COLUMN_NAME>),3),0))

  • If that still fails to return a valid data set for ArcGIS (and it wasn't enough in my case...), I recommend deleting any Polygon geometry record having an area less than 1 square meter.

To do this, I calculated the geodesic area for all Polygons in PostGIS, and subsequently deleted the ones with area < 1 m2. The latter action solved my issues, and allowed ArcGIS to finally accept the data as 100% valid and load it without issues as an ArcGIS Query Layer.

If you want to calculate the geodesic area as well, you can use:

  • If your data is in SRID 4326: ST_Area(<GEOMETRY_COLUMN_NAME>::geography,False)

  • Other projection: ST_Area(ST_Transform(<GEOMETRY_COLUMN_NAME>,4326)::geography,False)

However, depending on your data, I don't know if this latter action is acceptable, although arguably, Polygons with an area < 1 m2 are likely erroneous in most GIS data sets (sliver data etc.). There is not much use for such tiny geometries in the real world of GIS daily practice and databases.

By the way, I have no idea why ArcGIS isn't capable of using these tiny shapes, while QGIS happily ingests them. Looking at the WKT representation of problematic features in DBeaver, apparently showed a valid representation. Maybe it is something to do with maximum coordinate precision in ArcGIS, and conversions (transparently executed - not visible to user) needed to get the data in ArcGIS ready format for display, and / or the combination with storage of coordinates in lat/long SRID 4326 instead of a more regular planar projection like Web Mercator, but this is all speculation...

5
  • I Think st_dump to explode my multipolygons then selecting all polygon with an area>1m2 fixed it.
    – Bera
    Commented Aug 5, 2020 at 7:03
  • 1
    Yes, using ST_Dump to explode multipolygons might be necessary. Multipolygons can have parts of any size. Good to hear it appears the solution worked for you as well. I think you meant "< 1 m2" by the way... Although creating a likely empty table using > 1 m2 would resolve any issues as well ;-)
    – Marco_B
    Commented Aug 5, 2020 at 8:08
  • @BERA Just for the record, but was your data stored in SRID 4326 as well?
    – Marco_B
    Commented Aug 5, 2020 at 8:26
  • No 3006. Originally in Microsoft SQL server, then exported and processed in postgresql+postgis
    – Bera
    Commented Aug 5, 2020 at 8:27
  • 1
    @BERA, I ammended my first post with some extra recommendations, you might want to have a look.
    – Marco_B
    Commented Sep 3, 2020 at 19:23

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.