Select to view content in your preferred language

ST_Geometry vs SDO_Geometry?

20545
10
02-17-2016 10:58 PM
JayantaPoddar
MVP Esteemed Contributor

Hi Everyone,

I could not find any consolidated document which precisely differentiates between ST_Geometry and SDO_Geometry, especially related to the supported functionalities in ArcGIS Desktop/Server.

Could anyone help me pointing out the challenges we might face on choosing SDO_Geometry over ST_Geometry?

Currently using

ArcGIS 10.3.1 Desktop/Server;

Oracle 11g/12C

Vince AngeloAsrujit SenGuptaJake SkinnerGeorge Thompson



Think Location
0 Kudos
10 Replies
George_Thompson
Esri Notable Contributor

Hi Jayanta,

I would start here: Oracle data types supported in ArcGIS—Help | ArcGIS for Desktop

ST_Geometry in Oracle—Help | ArcGIS for Desktop

SDO_GEOMETRY and ArcGIS—Help | ArcGIS for Desktop

Deciding which one is best for you would be based on your workflows. Also how comfortable you are at using SQL: SQL and enterprise geodatabases—Help | ArcGIS for Desktop

*Updated: I would also add this, what other products are going to be consuming the data? If all ArcGIS products they can read the ST_Geometry, if they are 3rd party products then they may only read SDO_Geometry. Just something to keep in mind.

Hope this help!

-George

Managing DataEnterprise GIS

--- George T.
by Anonymous User
Not applicable

Hi Jayanta

I don't know if you are pointing in the right direction.. In fact, using ST_GEOMETRY or SDO_GEOMETRY as geodatabase spatial storage format would not affect functionality. ESRI recommends ST_GEOMETRY as geometry storage format even compared with SDEBINARY, but finally, this wont affect fuctionality.

So, why are you thinking about using SDO_GEOMETRY? If you want to use SDO_GEOMETRY because of you can take benefit of a multi-vendor software scenario (with non-ESRI clients connecting the geodatabase) for sure you will be oblied to use SDO instead of ST...and you will need to adjust your workflows...And, in this scenario the functionallity will be affected... Is this the correct scenario?

Regards

Jesús de Diego

JayantaPoddar
MVP Esteemed Contributor

George and Manuel,

Thank you for your suggestions. We need to create a centralized database, from which data would be fetched by softwares from Intergraph and AutoDesk as well. They recommend SDO_Geometry.

I guess the term "Functionalities" was a bit ambiguous.

I am looking to preserve the dataset properties like topological rules, network dataset and relationship classes. Will they be preserved or newly created when my data is in SDO_Geometry?



Think Location
0 Kudos
George_Thompson
Esri Notable Contributor

I would yes, that is a supported spatial type within ArcGIS and you can use all the functionality that you mention above.

--- George T.
0 Kudos
JayantaPoddar
MVP Esteemed Contributor

What if I don't have Oracle Spatial. Just Oracle Locator.



Think Location
0 Kudos
by Anonymous User
Not applicable

There is no difference... so you are using MDSYS.SDO_GEOMETRY data type, anyway....

Jesús

0 Kudos
VinceAngelo
Esri Esteemed Contributor

The SDO_GEOMETRY type is provided by Locator, which is part of the Intermedia bundle, and bundled into the base cost of Oracle. Esri does not use any Spatial-restricted functions anywhere in the utilization of the SDO_GEOMETRY type (unless users explicity add one in a WHERE clause or a view).

- V

VinceAngelo
Esri Esteemed Contributor

You need to specify the lineage of ST_Geometry on Oracle, because there are two of them -- MDSYS.ST_GEOMETRY and SDE.ST_GEOMETRY.  ArcGIS only supports MDSYS.SDO_GEOMETRY and SDE.ST_GEOMETRY native types (The MDSYS.ST_GEOMETRY is a wrapper around SDO_GEOMETRY).

The biggest difference is that SDO_GEOMETRY does not use a compression algorithm on the vertex stream the way SDE.ST_GEOMETRY does, so lines and polygons stored in SDE.ST_GEOMETRY will be smaller (with a corresponding throughput performance gain).  I once had a customer complain that SDO_GEOMETRY was twice as slow as the Esri type in a full table scan query,  and when I had him measure the storage of the tables, the SDO layer used twice the space.

If you have 3rd-party applications reading the database, and they don't support SDE.ST_GEOMETRY, then your decision tree is simple.  If it's just a storage decision, then I'd encourage you to benchmark performance with your data using Python (for the millisecond resolution timer).

Please do not tag me in questions.  I review most new GeoNet content, and answer questions based on my ability to help, as my schedule permits. If I start getting tagged on a regular basis, I'll need to start avoiding questions where I've been tagged, just to discourage the practice.

- V

JayantaPoddar
MVP Esteemed Contributor

Sorry about that. I will keep the tagging thing in mind. Thanks for your suggestions.



Think Location
0 Kudos