Top 5 Recent Articles
- Algorithms (13)
- All (407)
- Biography (1)
- Blog (44)
- Business Requirements (1)
- Commentary (1)
- Customers (2)
- Data Models (1)
- Education (2)
- GeoRaptor (5)
- Image Processing (2)
- Import Export (5)
- Licensing (2)
- Linear Referencing (3)
- Manifold GIS (3)
- Mapping (1)
- MySQL Spatial (7)
- Networking and Routing (including Optimization) (3)
- Open Source (16)
- Oracle Spatial and Locator (178)
- PostGIS (33)
- Published Articles (1)
- Recommendations (1)
- Services (1)
- Software Change Log (1)
- Source Code (35)
- Space Curves (9)
- Spatial Database Functions (101)
- Spatial DB comparison (1)
- Spatial XML Processing (10)
- SQL Server Spatial (General) (83)
- SQL Server Spatial (LRS) (38)
- Standards (1)
- Stored Procedure (15)
- Tessellation or Gridding (9)
- Tools (2)
- Training (2)
Support for ESRI’s ST_GEOMETRY
The following article results from customers downloading the free source code (eg for Oracle SDO_GEOMETRY) on this site without fully understanding that the code is not for ESRI’s ST_GEOMETRY spatial type and then requesting changes to the source code to support that foreign type.
So, to be clear, all of the source code, products and examples that are made available on this website only deal with the spatial types that are provided by the main database vendors and their products.
In summary, these are supported:
- MySQL SPATIAL data type;
- PostGIS’s GEOMETRY and GEOGRAPHY types for PostgreSQL;
- SQL Server’s GEOMETRY and GEOGRAPHY types.
- Oracle’s SDO_GEOMETRY, ST_GEOMETRY and other objects.
At no stage has this site ever attempted to provide free code or product for ESRI’s ST_GEOMETRY implementation for these databases.
The reasons I do not support ESRI’s spatial type are as follows:
- I cannot afford an ESRI license that would allow me to use and develop solutions and tools for it;
- Access to the main database vendors’ database products is covered by free development licenses.
- All the main vendor spatial types are already supported in the ESRI software stack;
- Given my computer science training and expertise in databases, I view their extensible data types as being approximate implementations of relational domains. As such, IMHO, it is the responsibility of the database vendor to provide such extensibility in their products.
- Hence, IMO, ESRI’s data type is, in effect, for ESRI’S software stack and users and not for universal, ubiquitous access by any other software;
- The current database implementations IMHO all provide a better implementation of a spatial type system, which are tightly integrated into the architecture of the host database. For example, Oracle’s and SQL Server’s spatial types are better integrated into the Oracle kernel than any external procedure-based system.
- Customer and technical support is split between database vendor and ESRI (blame game);
These points are my opinion based on experience and education.
However, if one wants to use some of my code then it is possible via use of the Open GIS (OGC) WKT and WKB export/import functions. One example will suffice:
-- Assume shape is an SDE.ST_GEOMETRY object... SELECT rownum AS fid, SDE.ST_GeomFromText( CODESYS.ST_Translate( p_geometry=> SDO_GEOMETRY(SDE.ST_AsText(a.shape),ST_SRID(a.shape)) p_tolerance => 0.005, p_deltaX => 200.0, p_deltaY => 100.0 p_deltaZ => NULL, p_mbr => NULL ), SDE.ST_SRID(a.shape) ) AS movedShape FROM <my Table> a;
Be careful with SRID values as ESRI’s and Oracle’s may not be the same.
-- Oracle SELECT * FROM cs_srs WHERE srid = <value>; -- ESRI SELECT * FROM sde.spatial_references WHERE srid = <value>;
I hope this is helpful to those who find themselves in this situation.