OGC compliant storage of geometries in Enterprise Geodatabase (Microsoft SQL Server)

[Palladius]

To date it is only possible to store geometries OGC compliant in a File Geodatabase. Accordingly ArcGIS Pro provides the Data Management Tools “Check Geometry” and “Repair Geometry” with the Validation Method “OGC”. For Enterprise Geodatabases the Validation Method “OGC” is not available. Geometries can only be checked/repaired/stored according to the “Esri Simplify method” in an Enterprise Geodatabase.

A problem arises with data that contains polygons with holes when migrated from a File Geodatabase into an Enterprise Geodatabase in Microsoft SQL Server: the geometry of the data is converted into a single ring (using a point twice if the hole touches the outer ring). This is then no longer OGC compliant.

A description of the case can be found here (Examples OGC vs. Esri - Case a): What is a simple polygon · Esri/geometry-api-java Wiki · GitHub [github.com]
The problem is also described in the following feed: sql server - Can a self-intersecting banana polygon be made OGC-compliant in an Azure SQL Database using spatial functions? - Geographic Information Systems Stack Exchange.

Please allow for the OGC compliant storage of geometries also in Enterprise Geodatabases for Microsoft SQL Server. This way such geometries can be provided in a standardized way by the Feature Service REST interface and can be further processed by any Third Party products that expect OGC compliance.

[Palladius]

Let me add a little context information as to why i posted the idea (and why it may be beneficial to others, too). We are working in an enterprise IT environment which is characterised by a fairly large number of seats (>10000) and federation of IT systems (with our ERP system as central element). For incorporating the spatial aspect into mainstream business processes a good integration of our corporate GIS (ESRI) into the mainstream IT is essential. More to the point: Right now we have a particular problem of getting the ESRI Enterprise Geodatabase talk to another component of our IT environment due to the inability of OGC-compliant storage (implications for business processes see above).

The implementation of OGC compliant storage would thus help the ESRI ENTERPRISE! Geodatabase living up to its name. 

[JoshuaBixby]

If one is working with SQL Server geometry data type, it does conform to OGC Simple Features 1.1.0 and SQL MM.  From Spatial Data Types Overview - SQL Server | Microsoft Learn

There are two types of spatial data. The geometry data type supports planar, or Euclidean (flat-earth), data. The geometry data type both conforms to the Open Geospatial Consortium (OGC) Simple Features for SQL Specification version 1.1.0 and is compliant with SQL MM (ISO standard).

I believe the issue you are running into is less about how the geometry object is stored and more about differing geometry models.  Esri has its own geometry model that is not a one-to-one match with the OGC geometry model.  Looking at Check Geometry (Data Management)—ArcGIS Pro | Documentation

After a feature's geometry is repaired using the OGC option, any subsequent edit or modification may cause the geometry to no longer comply with the OGC specification.

This statement exists because Esri tools operate based on the Esri geometry model, and since the Esri geometry model isn't exactly the OGC geometry model, taking an OGC compliant geometry and processing it with Esri tools may result in a non-OGC compliant geoemtry.

Even if this was a geometry data type storage issue, which I don't believe it is, implementing this idea would involve Esri creating their own spatial data type in SQL Server, which is not a trivial effort.