Best Practices for Using Oracle Spatial with EF Core (SDO_GEOMETRY, Spatial Functions, and Performance)

[Mganjirad]

Hello everyone,

I am currently developing spatial services on top of an Oracle Spatial database (tables with SDO_GEOMETRY columns), using .NET and Entity Framework Core as my ORM layer.

One of the challenges I am facing is that EF Core does not provide built-in support for Oracle Spatial functions such as SDO_ANYINTERACT, SDO_INTERSECTION, etc.
This forces me to use raw SQL queries (FromSqlRaw) for spatial operations, which raises concerns about performance and maintainability in scenarios with high request volume.

My design goals are:

• Continue to benefit from ORM features such as LINQ, unit of work, and entity tracking.
• Keep spatial computations (intersections, within, buffer, etc.) on the Oracle database side, where spatial indexing is optimized.
• Offload non-computational tasks such as format conversions (e.g., SDO_GEOMETRY to WKT/GeoJSON) to the application layer, to reduce database load.

My questions for the community are:

1. What is the recommended best practice for integrating Oracle Spatial with EF Core?
2. Are there known approaches for mapping Oracle Spatial functions into EF Core as DbFunctions?
3. How do you balance database vs. application load in high-volume spatial service scenarios?

Any insights, best practices, or examples would be greatly appreciated.

Thanks,

[alexkeh]

ODP.NET will add NetTopologySuite support by the end of this year.
#327

Does NTS meet your Oracle Spatial app requirements?

[Mganjirad]

that’s definitely good news.
That said, I have a couple of concerns that I’d appreciate clarification on:

• Curved geometries support

As far as I know, NTS does not support curved geometries (e.g., CIRCULARSTRING, COMPOUNDCURVE, CURVEPOLYGON).
In our Oracle Spatial datasets, it’s common to have tables where both linear and curved geometries are stored in the same column.

1. If EF Core + NTS integration attempts to materialize such geometries, how will this be handled?
2. Will ODP.NET automatically linearize these curved geometries when mapping them to NTS types (which would alter the original geometry)?
   Or is there a plan to allow applications to access the raw curved geometry as-is?

NTS

• Use case: returning original geometry to clients

1. In some scenarios, we need to read a curved geometry from the Oracle table, keep it in its original form, and convert it to WKT in the application layer before sending it to the client. Since NTS does not support curved types, how is this expected to be managed? Will there be an option to bypass NTS for these cases and still work with the raw SDO_GEOMETRY objects directly?

• Current EF Core behavior

1. Just to make sure I understand: if I connect EF Core to an Oracle Spatial database today, how are SDO_GEOMETRY columns currently represented in the EF Core model? Do they map to a specific .NET type, or are they exposed as raw objects that require manual handling?

Any insights into how these scenarios will be supported would be very helpful.

Thanks again