SDE vs. Oracle Spatial
tmoo...@my-dejanews.com
ESRI's SDE vs. Oracle's Spatial (formerly SDO)? I am evaluating the two at
the moment and would appreciate hearing any comments.
I will gladly make a summary of comments to post back to the list (provided
that I get some comments ;-)
Regards,
Tom
-----------== Posted via Deja News, The Discussion Network ==----------
http://www.dejanews.com/ Search, Read, Discuss, or Start Your Own
Steve Stearns
using mostly SDE for all of our large production developments. SDE beats the
pants off of SDO in terms of operational speed. It's not even close. But then
again, you can query individual points within SDO using plain old SQL. The
spatial points within SDE exist as a "Blob" which is a variable vector of long
integers. You need the programmers API in order to make sense out of those
blobs. Thus, you get better flexibility with SDO, but far better speed with SDE.
Also, SDE comes with a wealth of spatial utilities and an API which makes it a
full GIS in its own right. I have seen folk develop a GIS system using only SDE
and a TC/TKL. SDO is only a point storage system, and you need to purchase a
suitable GIS in order to be able to use SDO. Curiously, ESRI software can use
SDO even though they are the developers of SDE. Also, SDE can also load and run
SDO-type covers, although you lose the speed advantages of SDE when you do so.
SDE can support "complex" spatial-types like network, dynamic segmentation,
multi-point, or polygon regions. SDO (at least the last version I played with)
is limited to the basic point-line-poly shapes.
Naturally, SDO is limited to Oracle, while SDE will use Oracle, Sybase,
Informix, DB2, etc. Likewise, the other GIS vendors besides ESRI are not too
fond of developing SDE drivers, although CAD vendors like AutoDesk and Intergraph
don't seem to have a problem with it.
There's probably a good market for both products, it just depends on what your
needs are.
Tom Moore
Steve Stearns <sste...@swbell.net> wrote:
> I've been trained on both SDE and SDO. My company (SBC Communications) is
> using mostly SDE for all of our large production developments. SDE beats the
> pants off of SDO in terms of operational speed. It's not even close. But
then
> again, you can query individual points within SDO using plain old SQL. The
> spatial points within SDE exist as a "Blob" which is a variable vector of long
> integers. You need the programmers API in order to make sense out of those
> blobs. Thus, you get better flexibility with SDO, but far better speed with
SDE.
Thanks for your reply Steve, your comments help a lot.
I imagine you must be describing the pre - 8.1.5 of Oracle Spatial (or the
product formerly known as SDE). I would like to compare the features of
object relational model of Oracle Spatial 8.1.5 to those of SDE (I suppose at
version 3.0.2). I guess I should have specified this in my initial post, but
I've been doing a bit of digging and now have a slightly better idea of the
situation.
The newly announced 8.1.5 version provides an object relational model which
stores geometry in an object field. This is closer to a blob than the
previous relational only format, but retains the benefits that you can get
full access to the geometry through SQL. I would be interested in knowing if
the object relational model has improved performance wrt to the previous
relational only model. Is anyone using this yet?
> Also, SDE comes with a wealth of spatial utilities and an API which makes it
a
> full GIS in its own right. I have seen folk develop a GIS system using only
SDE
> and a TC/TKL. SDO is only a point storage system, and you need to purchase a
> suitable GIS in order to be able to use SDO. Curiously, ESRI software can use
> SDO even though they are the developers of SDE.
What ESRI software can access Oracle Spatial? Is it only SDE or can other
tools get at it direct?
> Also, SDE can also load and
run
> SDO-type covers, although you lose the speed advantages of SDE when you do so.
> SDE can support "complex" spatial-types like network, dynamic segmentation,
> multi-point, or polygon regions. SDO (at least the last version I played
with)
> is limited to the basic point-line-poly shapes.
I believe that the 8.1.5 object relational model covers most of this. There
is a full set of geometry functions and operators that can be accessed
through SQL. The new version supports a broad range of OGIS conforming
feature types including multi-point and compound features. (Sorry, I don't
mean for this to sound like an Oracle commercial).
> Naturally, SDO is limited to Oracle, while SDE will use Oracle, Sybase,
> Informix, DB2, etc. Likewise, the other GIS vendors besides ESRI are not too
> fond of developing SDE drivers, although CAD vendors like AutoDesk and
Intergraph
> don't seem to have a problem with it.
> There's probably a good market for both products, it just depends on what
your
> needs are.
We would like to continue using the esri client toolset (ArcView, Arc/Info),
so connectivity is essential. I think this means that SDE is a requirement,
even if we adopt Oracle Spatial as the data store. Can anyone help me
understand better how this connection will work?
My unconfirmed opinion is that Oracle Spatial has a more flexible query
capability, in that it is all SQL and can be accessed through any ODBC
enabled tool. This would mean being able to pose mixed spatial-attribute
queries from client tools such as Microsoft Access. This would be a big win
for my clients organization, where many of the people who need to use the
database would not have sufficient skills to write queries using the SDE API.
Can anyone comment on the query abilities of SDE versus Oracle Spatial. For
example, how would you perform a spatial join or nested spatial query using
SDE? What can be done through an ODBC connection vs. what can only be done
by programming through the SDE API?
Thanks
Tom Moore
Spatial Planning Systems
email: tmoore at spatial dot ca
Dan Geringer
> I've been trained on both SDE and SDO. My company (SBC Communications) is
> using mostly SDE for all of our large production developments. SDE beats the
> pants off of SDO in terms of operational speed. It's not even close.
SDE 3.0.2 is the first version of SDE that integrates (SDO) also
known as Oracle Spatial Cartridge.
Unfortunately, SDE 3.0.2 has a serious bug in the creation of the
Spatial Cartridge index. SDE reverses the order of a critical concatenated
index (SDO_GID, SDO_CODE) on the _SDOINDEX table when it should be created
as (SDO_CODE, SDO_GID).
This will basically inactivate the Spatial Cartridge index and is probably
one of the causes for your poor performance.
I believe SDE is scheduled to fix this bug in their next release.
You can also manually apply this fix at the database level by
recreating the concatenated index yourself.
Another factor is that SDE 3.0.2 never calls the Spatial Cartridge
tuning utility (ESTIMATE_TILING_LEVEL) so it can create the
Spatial Cartridge index with appropriate parameters. SDE just uses
default values when it creates the index. You can override these
default values in the DBTUNE file.
Creating a spatial index with inappropriate values will cause poor
query performance the same way creating an SDE index with inappropriate
grid parameters will cause poor performance.
SDE performance with and without Spatial Cartridge are comparable. The new
spatial object model in Oracle 8i, known as Oracle Spatial, is even faster.
> But then
> again, you can query individual points within SDO using plain old SQL. The
> spatial points within SDE exist as a "Blob" which is a variable vector of long
> integers. You need the programmers API in order to make sense out of those
> blobs.
You are correct here. SDE without Spatial Cartridge stores it's
geometry as a proprietary formatted Blob in a LONG RAW column.
This limits flexibility and disables features in Oracle like
Distributed Database access.
As you mentioned, the only access method to the Blob is through the
SDE API, because SDE is the only application that understands the
proprietary format.
> Thus, you get better flexibility with SDO, but far better speed with SDE.
As I mentioned above, a poorly tuned index will generate poor performance
(SDE with Spatial Cartridge or without).
> Also, SDE comes with a wealth of spatial utilities and an API which makes it a
> full GIS in its own right. I have seen folk develop a GIS system using only SDE
> and a TC/TKL. SDO is only a point storage system, and you need to purchase a
> suitable GIS in order to be able to use SDO.
Oracle Spatial effectively manages spatial data and spatial indexes
inside the database server. The API for Oracle Spatial is SQL.
It can perform spatial analysis inside the database server without any other
GIS.
For example, an insurance company can generate a report that show them
all their clients that are within a flood zone in
a single SQL statement executed through SQL*Plus. No external GIS required.
To do this with SDE, you would have to write an application with the
SDE API. You can't execute the SDE API through SQL.
Neither SDE nor Oracle Spatial have drawing capability. Drawing is done with
an external application.
> Curiously, ESRI software can use
> SDO even though they are the developers of SDE. Also, SDE can also load and run
> SDO-type covers, although you lose the speed advantages of SDE when you do so.
> SDE can support "complex" spatial-types like network, dynamic segmentation,
> multi-point, or polygon regions. SDO (at least the last version I played with)
> is limited to the basic point-line-poly shapes.
Oracle Spatial does support more than point-line-poly shapes.
In the relational model, it supports multi-point, multi-line, multi-polygon,
heterogeneous collections and polygons with voids.
In the new Oracle 8i object model, there is also native support for
circles and circular arc data types.
The 8i Spatial object model can now perform the following complex functions and
analysis inside the database server through SQL:
- Buffer generation
- Area calculation
- Perimeter or line length calculations
- Polygon difference
- Polygon intersect
- Polygon union
- Polygon xor
>
> Naturally, SDO is limited to Oracle, while SDE will use Oracle, Sybase,
> Informix, DB2, etc. Likewise, the other GIS vendors besides ESRI are not too
> fond of developing SDE drivers, although CAD vendors like AutoDesk and Intergraph
> don't seem to have a problem with it.
You're correct that Oracle Spatial only works with Oracle.
To effectively manage spatial data in an enterprise, you want to store
your Spatial Data one time in a single repository. All edits and
queries should be performed against this single data store to maintain
data integrity.
If your single data store is inside Oracle, you will have much more
flexibility if the data is stored in Oracle Spatial than in the
SDE binary format.
Data in Oracle Spatial is open, and can be accessed with a number of different
vendor applications without data duplication. Interoperability
is now achievable.
If you use SDE with Oracle Spatial, you can also have this type
of interoperability which is not possible with the SDE binary
format.
I hope you find this information useful.
Thanks,
Dan Geringer
"The opinions stated here are mine and do not necessarily represent
those of Oracle Corporation."
Steve Stearns
Tom Moore wrote:
> <stuff deleted>
>
> I imagine you must be describing the pre - 8.1.5 of Oracle Spatial (or the
> product formerly known as SDE). I would like to compare the features of
> object relational model of Oracle Spatial 8.1.5 to those of SDE (I suppose at
> version 3.0.2). I guess I should have specified this in my initial post, but
> I've been doing a bit of digging and now have a slightly better idea of the
> situation
I do indeed have an older version. Dan Geringer's excellent response also goes into
a lot of the new functions (thanks, Dan). Perhaps some ESRI-employed reader will
pipe in with the latest SDE4.0 additions. Customers *like* choices, you know.
>
>
> <stuff deleted>
>
> > Also, SDE comes with a wealth of spatial utilities and an API which makes it
> a
> > full GIS in its own right. I have seen folk develop a GIS system using only
> SDE
> > and a TC/TKL. SDO is only a point storage system, and you need to purchase a
> > suitable GIS in order to be able to use SDO. Curiously, ESRI software can use
> > SDO even though they are the developers of SDE.
I should have been more specific here. Dan Geringer of Oracle points out that you
can display SDO with TK/TCL as well, and that SDE does not have draw functions any
more that SDO. That's correct. I was referring to those many spatial functions
that come bundled with the SDE API. Nobody wants to re-write their own polygonal
intersection routine. Again, see Dan G.'s response. It sounds like the SDO is
beginning to catch up with SDE3 (just in time for the SDE4 release).
>
>
> What ESRI software can access Oracle Spatial? Is it only SDE or can other
> tools get at it direct?
I have heard that there are ArcView drivers for "vanilla" SDO, but I do not have any
in my lab. With the unbundled dev-kit in Arc8.0, I can't see that anyone would have
trouble interfacing to something as straight-forward as SDO.
>
>
> > Also, SDE can also load and
> run
> > SDO-type covers, although you lose the speed advantages of SDE when you do so.
> > SDE can support "complex" spatial-types like network, dynamic segmentation,
> > multi-point, or polygon regions. SDO (at least the last version I played
> with)
> > is limited to the basic point-line-poly shapes.
>
> I believe that the 8.1.5 object relational model covers most of this. There
> is a full set of geometry functions and operators that can be accessed
> through SQL. The new version supports a broad range of OGIS conforming
> feature types including multi-point and compound features. (Sorry, I don't
> mean for this to sound like an Oracle commercial).
Don't apologize. Competition is good.
>
>
> > Naturally, SDO is limited to Oracle, while SDE will use Oracle, Sybase,
> > Informix, DB2, etc. Likewise, the other GIS vendors besides ESRI are not too
> > fond of developing SDE drivers, although CAD vendors like AutoDesk and
> Intergraph
> > don't seem to have a problem with it.
> > There's probably a good market for both products, it just depends on what
> your
> > needs are.
>
> We would like to continue using the esri client toolset (ArcView, Arc/Info),
> so connectivity is essential. I think this means that SDE is a requirement,
> even if we adopt Oracle Spatial as the data store. Can anyone help me
> understand better how this connection will work?
>
> My unconfirmed opinion is that Oracle Spatial has a more flexible query
> capability, in that it is all SQL and can be accessed through any ODBC
> enabled tool. This would mean being able to pose mixed spatial-attribute
> queries from client tools such as Microsoft Access. This would be a big win
> for my clients organization, where many of the people who need to use the
> database would not have sufficient skills to write queries using the SDE API.
> Can anyone comment on the query abilities of SDE versus Oracle Spatial. For
> example, how would you perform a spatial join or nested spatial query using
> SDE? What can be done through an ODBC connection vs. what can only be done
> by programming through the SDE API?
Well, most of the major relational vendors can interace with ODBC, but with those
SDE tables (unless you are using the SDO format) the spatial entities will only show
up as blobs. If you need to get back an (X,Y) set within a query from MS-Access,
then SDO is probably a better choice. SDE is a speed-freak, but you really do need
to be fluent with C,VB,Java, or some sort of programming language. As a developer,
that's not a problem for me, but would be daunting to most of my clients.
Incidently, the best SQL-based geo-query functionality I ever saw came with the
SystemHouse Vision product, which pre-dated both SDE/SDO (but I think it now runs
with SDO). Hopefully, someone from ESRI willl pipe in to counter Dan G., but I
tend to agree with your opinion that SDO has more flexibility. Good luck, and I'll
keep an eye on this thread. -Steve.
Mlettau
Oracle recently announced a partnership with MapInfo to develop web-based
mapping solution with Oracle8i and MapInfo products. How significant is this
development and how do MapInfo's web-based products compare with ESRI's?
Thanks
Michael Lettau
a...@kms.dk
Ministry of Agriculture has an comparisom of SDE and SDO.
regards
Anders Hvas
Bradley G. Smith
<deleted>
Thanks for the very useful information Dan. Much appreciated.
Brad
Barry Steele
Thank you very much for your response, it casts light on a topic that has
been somewhat clouded of late.
I am interested in your thoughts on the treatment of topology in a spatially
enabled RDBMS. TO explain, I was part of Dave Abel's team from the CSIRO's
Division of Information Technology which developed SIRO-DBMS, which has now
been commercialised by SpatialInfo into SDM. Our biggest issue was to build
the topological structure of objects into the definition of the object at
schema level rather than the current "on-the-fly" build methods.
My understanding is that is we have topology built during the delivery to
the client program, we severely restrict flexibility in two ways. Firstly,
all topological analysis must be carried out in either middleware or on the
client, which will then (#2 restriction) tend to be specific to that brand
of software. It would appear to me that if the database engine manages
topological rules (referential integrity, spatial integrity, connectivity,
etc) and provide a pre-defined topological model to the client, we provide a
better environment to allow true inter-operability between systems (spatial
and non-spatial)
Barry Steele
Dan Geringer wrote in message <370E29F9...@us.oracle.com>...
>Steve Stearns wrote:
>
>> I've <clipped>
Tom Moore
a...@kms.dk wrote:
> In the march issue of GeoInformatics Frits Cattenstart from the Dutch
> Ministry of Agriculture has an comparisom of SDE and SDO.
Thanks Anders
The link to this article is
http://www.geoinformatics.com/Issues/March99/Artikel%20Cattenstart.HTM
I took a read through it, and seems more of a critique of the OGC simple
feature spec than a comparison of the two systems.
A related link of interest is the OGIS simple feature specification for SQL
http://www.opengis.org/public/sfr1/sfsql_rev_1_0.pdf
This describes the objects and methods that SDE and SDO have just certified as
being conformant.
Tom
--
Tom Moore
Steve Stearns <sste...@swbell.net> wrote:
>
>
> Tom Moore wrote:
>
> > <stuff deleted>
> >
> > I imagine you must be describing the pre - 8.1.5 of Oracle Spatial (or the
> > product formerly known as SDE).
Ooops. Of course I meant that SDO was the former name for Oracle Spatial.
> I have heard that there are ArcView drivers for "vanilla" SDO, but I do not
have any
> in my lab.
Does anyone have any information about this? I turned the ArcView 3.1 box
inside out, checked the ESRI web site, but turned up nothing.
My guess is that this requires an extension that can only be provided by
ESRI. At a minimum, it involves sub-classing the database access
methods for Connection, QueryRef, and SColumn, and of course this is not
possible in Avenue.
>With the unbundled dev-kit in Arc8.0, I can't see that anyone
> would have
> trouble interfacing to something as straight-forward as SDO.
Thanks. When Arc8.0 is released I'll take a look at it.
Tom
--
Paul Hardy
> ...
> enabled RDBMS.
> It would appear to me that if the database engine manages
> topological rules (referential integrity, spatial integrity, connectivity,
> etc) and provide a pre-defined topological model to the client, we provide a
> better environment to allow true inter-operability between systems (spatial
> and non-spatial)
Certainly one of the major reasons that major mapping agencies have chosen
Laser-Scan's Gothic Object-Oriented spatial database is the topology support in
the database.
In Gothic you can have automatic creation and maintenance of stored topology in
the database, with topological rules and tolerances between pairs of object
classes defined in the versioned dataset schema. Topology types include
node-node, node-split-link, and link-split-link.
Integrity rules (spatial, referential and attributional) are defined as methods
on the object classes in the schema, and hence are applied by the database
regardless of which application is doing the modification (e.g. bulk load, data
capture, interactive edit, analysis).
Doing all this in the database, allows mixing of Unix or NT clients, with very
lightweight clients such as web browsers and still see a consistent topological
view of the data.
See http://www.Laser-Scan.com for more information on Gothic
A further point worth noting is that topology formation is one of those areas
of computation which looks easy, but the more you try and pin it down, the more
pathological cases creep out of the woodwork. Even simple concepts like "which
side of the line from A to B does point C lie?" become hard when:
* computer coordinates are discrete values not a continuous spectrum
* computer calculation (even IEEE floating point) is predictable but not exact
* coordinate ranges for datasets vary from a few metres for large-scale plans
to millions of metres for whole world mapping.
* coordinates in input lines and areas are often not well-behaved - point
distributions can be very uneven, with almost duplicated points, short hair
lines and sliver polygons the rule rather than the exception. This is
particularly true when data from different sources are merged.
* People expect to store coordinates their chosen space, which may be Lat/Long
on a specific datum (WGS84 or ETRF89, or NAD83, or ...) or may be metres (or
feet) on one of dozens of map projections.
* Input coordinates for topology snapping may be in any projection or datum
* Coordinates can include Z values as well as X and Y - people still want to
snap a forest edge to a lake edge along their shared common boundary, even
though the edge is really at two different heights.
* Lat/Long is not a cartesian space - it's a polar coordinate system
The result of all this is that topology formation on-the-fly is always going to
be at risk of failing due to these ambiguities and pathological cases. It's
much better to do the topology formation early on (as close to the operator
doing the capture as possible), and resolve such ambiguities once and for all.
--
Paul Hardy (PGH), Software Production Manager, Laser-Scan Ltd,
Science Park, Milton Rd, CAMBRIDGE, CB4 0FY, GB. Tel: +44 (0)1223 420414
Fax: 420044, Email: Pa...@LSL.co.uk, Web: http://www.Laser-Scan.com
Good judgement is the result of experience ...
... Experience is the result of bad judgement. (Fred Brooks)
bruce....@srs.gov
Oracle SDO. Our criteria included the ability to share data between Intergraph
and ESRI GIS systems (ArcInfo/ArcView/MGE/GeoMedia) as well as serve data to
non-gis users, via methods like WWW and ODBC. One big issue was the internal
format of the data in Oracle-blob verses relational tables. We found the blob
issues very restricting (required programmers and ESRI API to insert/extract
data outside of ESRI products). Also, the blob format could not be extended
outside of the GIS arena (WWW and ODBC and SQL*Plus) again without much
customization (our goal is to maximize off-the-shelf functionality).
In out efforts to intergrate the two vendor's GIS packages, SDE 3.0.2 was
used in conjunction with Oracle 7.3.4 and SDO. Although the ESRI doc's said
you can use SDO data inside SDE, we were not able to do it. Our test
methodology was to use GeoMedia (SDO compliant) to create a "layer" in SDO,
with all the requisite SDO tables. Then, using SDE, add the approriate info
into the SDE tables in order to have SDE "recognize" the foreign SDO table.
We never could make this work, and finally the SDE support people agreed it
was a bug that "might get fixed in SDE 4.x".
All our production databases are Oracle 7.x, and moving to SDE 4.x requires
(we were informed) Oracle 8.x, so for us, SDE was no longer an option. We
still have not transitioned to Oracle 8.x but expect to sometime after Y2K. I
did fool around with a product from GeoMicro, which REALLY intergrated our
needs well (ESRI shape file data and Oracle SDO data).
Since we never got SDE to work, we never even got to the issue of SDE vs SDO
performance
Bruce Reeves
Westinghouse
In article <7ec7vr$7es$1...@nnrp1.dejanews.com>,
tmoo...@my-dejanews.com wrote:
> Has anyone undertaken a comparative review of the strengths and weaknesses of
> ESRI's SDE vs. Oracle's Spatial (formerly SDO)? I am evaluating the two at
> the moment and would appreciate hearing any comments.
>
> I will gladly make a summary of comments to post back to the list (provided
> that I get some comments ;-)
>
> Regards,
>
> Tom
>
Scott Morehouse
understanding of the technologies involved as well as the fact that both
have changed significantly in the past year. I'll try to clarify some of
the issues in this note.
What is SDE?
============
SDE is a spatial data management and geoprocessing system. SDE defines a
geographic data model, together with a set of services for modelling
geographic features in a database. This data model is based on the concept
that geographic features are rows in a relational table containing a column
of type geometry. The services provided by SDE include: defining and
managing the integrity of the geometry type, functions on geometry, storage
and retrieval of geometry, spatial index management and query processing,
and integration with non-spatial columns and queries. These services are
exposed through the SDE API which define objects of type geometry,
connection, query, cursor, etc. This API is available for a number of
platforms: a C library, COM Automation objects, Avenue, and, soon, Java.
SDE is layered on top of a database management system. The database system
is responsible for storage of spatial and non-spatial data and indicies, for
query processing, short transaction management, and other data storage and
retrieval functions (like replication). In general, SDE adds functionality
for defining the spatial data type, for functions on spatial types, and for
query processing when spatial predicates are involved.
SDE is designed as an open API, which will run on a variety of underlying
database management systems. In some cases, the underlying DBMS has support
for spatial types and query processing. In those cases, SDE defers spatial
processing to the DBMS. If the underlying database system has no spatial
support at all, SDE will implement all of the spatial functionality. If the
underlying database has some functionality, SDE will implement some
functionality and defer the rest to the database engine. To achieve the
best performance and leverage core database technology, we try to defer as
much functionality to the database as possible. SDE is currently running on
Oracle, Informix, DB2, SQL Server, Sybase, MicroSoft Jet (Access), and even,
in a read-only mode, with ARC/INFO coverages and libraries.
What is the OGIS Simple Features Standard?
==========================================
The OGIS Simple Features Standard (http://www.opengis.org/techno/specs.htm )
defines a simple geographic data model. Like SDE, the OGIS simple feature
model is based on the concept that geographic features are rows (aka
features) in a relational table (aka feature collection) containing a column
(aka property) of type geometry. Since a primary objective of OGIS is
interoperability with "mainstream" IT development platforms, there are
several versions of the specification: for SQL/ODBC/JDBC, for COM/OleDB, and
for CORBA. Within the SQL specification, there are three variants of the
standard: as a true data type in the SQL language, as a well-known binary
structure (this is the method SDE uses for databases without integrated
spatial support), and as a normalized schema. The three variants are
necessary because not all database systems allow the SQL language to be
extended with new types and there are practical tradeoffs among them. The
OGIS SQL type standard is essentially the same as the draft ISO SQL 3
spatial type standard.
What is Oracle Spatial?
=======================
Oracle Spatial is an extension to the Oracle DBMS for spatial data. The
original Oracle spatial implementation, known as SDO (spatial data option),
consists of a normalized schema for representing polygons and polylines as a
set of rows in a geometry table, a spatial index mechanism, and a set of
stored procedures to perform queries and to manage the spatial index. In
the normalized implementation, a spatial object consists of a set of rows in
a geometry table and is queried through special stored procedures. This
model is essentially the "normalized" form of the OGIS SQL standard for
simple features.
At Oracle 8i, another mechanism for spatial data management has been added,
in which spatial information is represented as an actual SQL type. This new
type is based on the array column type added to the core Oracle engine. In
the type implementation, a spatial object consists of an array of numbers
and is queried through SQL select statements. Unfortunately, the Oracle 8i
Spatial type does not conform to the OGIS / SQL 3 type specification.
Other database management systems have also been extended to support spatial
types within the kernel of the relational database engine. ESRI has
developed spatial type extensions for Informix and DB2. These spatial type
comply with the OGIS and proposed SQL 3 standard for spatial types. These
extensions are included as a part of SDE for Informix and DB2. You can work
with these types directly through SQL, without the SDE API.
Why SDE vs. Oracle Spatial?
==========================
Ok, since SDE is a set of database neutral application services which can
exploit the capabilities of Oracle Spatial, where does this "SDE vs Oracle
Spatial" debate come from? It happens because SDE supports three different
implementations on Oracle:
- SDE on standard Oracle (binary geometry)
- SDE on Oracle Spatial (normalized geometry)
- SDE on Oracle 8i Spatial (geometry type)
(The 8i type implementation comes in the next SDE release.) Users often
compare the "standard Oracle binary" vs the "Oracle Spatial normalized"
implementations and, in many cases, the binary has significantly better
performance than the normalized implementation. Since there are other
benefits to the normalized implementation, this leads to confusion. The
performance difference makes sense when you think about fetching a single
geometry blob vs iterating a cusor over a geometry table. This is also part
of the reason that Oracle is moving to denormalized geometry types in 8i.
ESRI is adding support for the new Oracle 8i spatial types in SDE (see
http://www.esri.com/news/releases/99_1qtr/oracle8i.html). We expect that
this will significantly improve the performance of Oracle Spatial and help
to finally eliminate any dissonance between ESRI's spatial data management
strategy and Oracle's.
Hope this helps.
-Scott
Duncan Kinder
--
Regards,
Duncan C. Kinder
dcki...@mountain.net
Scott Morehouse <smore...@esri.com> wrote in message
news:7g7ehu$l95$1...@esri.esri.com...
Raj R. Singh
8.0.5 linux distribution. We're all still waiting
for the 8i linux release. Maybe that one will have it.
Duncan Kinder wrote:
> Is Oracle Spatial available on the Linux distribution of Oracle?