topic Re: ST_Geometry vs SDO_Geometry? in Geodatabase Questions

ST_Geometry vs SDO_Geometry?

JayantaPoddar — Thu, 18 Feb 2016 06:58:44 GMT

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

Re: ST_Geometry vs SDO_Geometry?

George_Thompson — Thu, 18 Feb 2016 12:46:22 GMT

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 Data Enterprise GIS

Re: ST_Geometry vs SDO_Geometry?

Anonymous User — Thu, 18 Feb 2016 16:19:24 GMT

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

Re: ST_Geometry vs SDO_Geometry?

JayantaPoddar — Thu, 18 Feb 2016 17:04:41 GMT

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?

Re: ST_Geometry vs SDO_Geometry?

VinceAngelo — Thu, 18 Feb 2016 17:16:17 GMT

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

Re: ST_Geometry vs SDO_Geometry?

George_Thompson — Thu, 18 Feb 2016 17:16:59 GMT

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

Re: ST_Geometry vs SDO_Geometry?

JayantaPoddar — Thu, 18 Feb 2016 18:25:44 GMT

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

Re: ST_Geometry vs SDO_Geometry?

JayantaPoddar — Fri, 19 Feb 2016 07:26:23 GMT

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

Re: ST_Geometry vs SDO_Geometry?

Anonymous User — Fri, 19 Feb 2016 08:38:11 GMT

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

Jesús

Re: ST_Geometry vs SDO_Geometry?

VinceAngelo — Fri, 19 Feb 2016 17:01:01 GMT

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

Re: ST_Geometry vs SDO_Geometry?

MarcoBoeringa — Tue, 23 Feb 2016 20:19:50 GMT

One thing already mentioned in the other posts here, but that I would like to emphasize more, is the fact that ArcGIS for Desktop and ArcGIS for Server are almost completely database platform independed as regards to the user functionality offered from within the software packages. This is one of the major achievements of ESRI regarding database support in GIS, and often under-appreciated or not well understood by people less familiar with ESRI software.

Essentially, you can simply swap out any database platform and replace it with another, e.g. throw out Oracle and install Microsoft SQL Server. Or throw out SQL Server and replace it with PostGIS, DB2 or any of the other supported platforms.

You can even "mix" database platforms. Replicate from an Oracle to a SQL Server database, or even to a "simple" File Geodatabase...

ArcGIS for Desktop or Server simply don't care, you can keep doing what you did yesterday on the old platform if you make a switch! (and that is a great thing). ESRI really is on its own with such diverse database platform support, yet unified user experience.

The only "but" is that you need to stay within the ESRI Geodatabase context... Start messing at the database level, and of course you will need to be fully aware of the multitude of differences between database platforms, even if all of them are supposed to "talk" "standard" SQL.