Package oracle.spatial.geometry

hi guys,
do you know how to install the Oracle Spatial Java Class Library?
i'm using Jdeveloper 10g.
thank you

Hi Angelo,
Assuming that you have the jar files, you could add the spatial library to your project properties by right clicking the mouse on the project node, going to Project Properties, Libraries (under Profiles, Development), and then creating a new library name pointing to the spatial library files (jar files).

Similar Messages

Java.lang.ClassNotFoundException: oracle.spatial.geometry.JGeometry

I have installed UIM 7.2.2 on Oracle Linux 5.6_64 bit. There was no error message during the installation. But we are getting java.lang.ClassNotFoundException: oracle.spatial.geometry.JGeometry exception during runtime, specially while opening UIM home page in the browser.
Any suggestion?
Thanks,
Molay

Hi,
Please let me know the iPlanet service pack number that you are using.
Thanks
Ganesh .R
Developer Technical Support
Sun Microsystems
http://www.sun.com/developers/support

Oracle Spatial(Locator) Java Library

Hello,
I understand that Oracle Database in XE version includes Oracle Locator (limited version of Oracle Spatial). I would like to access to spatial data in JAVA application.
As far as I know oracle.spatial.geometry package is included in sdoapi.jar file which I'm unable to find in 11g XE beta installation. Can I download it separately somewhere or it is in different jar?
Or those functions are not avaible in XE version?
Thanks

Hi,
For this kind of activity, it might be best to use Oracle Spatial (rather than locator) which includes
LRS (Linear Referncing System). Linear Referencing allows you to use measure information
(such as start measure/end meaure) to return spatial data without duplicating spatial data in
multiple tables.
If you can elaborate on what data you have (do you have a table with geometry data for the highways?),
we might be able to outline what you need to do.
Dan

[Q] Oracle Spatial Java Class Library: classes missing ?

Hello !
We are using Oracle 9.2.0.4 with Spatial features and we'd like to use the Java Library to get access to the object Geometries. We have downloaded the Spatial Java Library at:
http://www.oracle.com/technology/software/products/spatial/index.html
The "sdo_java_040319.zip" file contains "sdoutl.jar", "sdotopo.jar, "sdonm.jar" and "sdoapi.jar". *BUT* "sdoapi.jar" only contains the "oracle.spatial.geometry.JGeometry" class !
Nothing about the "oracle.sdoapi.*",
"oracle.sdoapi.geom", "oracle.sdoapi.adapter", ...
"oracle.sdoapi.sref" !
Where are they ?
Thank you for your replies

The JGeometry class is it.
It's all you need with the new, supported sdoapi.
The javadoc for JGeometry has an example of its usage.

SDE's Efficiency Depends on Oracle Spatial?

Hello Everyone,
I came to hear an argument recently that if we install ESRI's ArcSDE on top of the Oracle Spatial the server throughput declines drastically!!!
How much truthful this statement is???
null

Srikrishna,
ESRI's SDE only ever executes
primary filter searching against
Oracle Spatial tables.
"ArcSDE uses the Oracle Spaital SDO_FILTER
function to perform the primary spatial query. ArcSDE performs secondary filtering
of the SDO_GEOMETRY based on the spatial
relationship requested by the application"
Quoted from: Spatial queries, Appendix D Oracle Spatial geometry type, ArcSDE Configuration and Tuning Guide for Oracle,
ArcInfo 8.1
IMHO this would mean that as the Oracle
Spatial boys continue the performance and
scalability improvements they have shown
in 8.1.7 and 9i (via R+ trees, improved
query optimisations etc), then
ESRI's SDE will become a bottleneck for
ESRI-based GIS applications.
I can't see ESRI changing this attitude
to Oracle secondary filtering in a hurry
(or until at least their approach is shown
to be slow).
Also, you can't use the aggregation
operators in 9i with arcSDE 8.1 as
it stands. Something I doubt will change
in a hurry as well.
regards
Simon

Is there a function in Oracle Spatial 11g to move/translate geometry?

Hello Everybody,
I am new to Oracle Spatial. I wanted to know if there is any function to move/translate a geometry in Oracle Spatial 11g? PostGIS has a function named ST_Translate to achieve the same.
Regards,
Shiva Shankar

Hi
There is an SDO_UTIL.AFFINETRANSFORMS function in the SDO_UTIL Package (Utility)
Note, that Simon Greener & Siva Ravada have published an excellent book ("Applying and Extending Oracle Spatial") that contains examples (in Chapter 7) of easy to use wrappers for this:
http://www.packtpub.com/applying-and-extending-oracle-spatial/book
Luc

Oracle spatial 11g - 3D-Geometry and KML-Export

Hi,
I'm currently working with an Oracle Spatial 11g - database and there with 2d- and 3d-geometries. With this Version you can extrude 2d's to 3d's and calculate their volumes. This works fine.
The problem is to save the extruded areas as 3d-geometries in a specific table. Enclosed you will find the SQL-Code of the current workflow:
*1. Create tables for the 2d- and 3d-geometries (incl. metadata and spatial index)*
-- table for 3d-geometry
CREATE
TABLE ta_geb(
geom MDSYS.SDO_GEOMETRY
,area NUMBER(12,3)
-- metadata 2D
INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES
     'ta_geb',
     'geom',
MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('X',4439900.00, 4440020.00, 0.005),
MDSYS.SDO_DIM_ELEMENT('Y', 5664050.00, 5664130.00, 0.005)
31468
-- spatial index 2D
CREATE
INDEX ta_geb_index ON ta_geb(geom) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
-- table for 3d-geometry
CREATE
TABLE ta_3dgeb(
geom3d MDSYS.SDO_GEOMETRY
-- metadata 3D
INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES
     'ta_3dgeb',
     'geom3d',
MDSYS.SDO_DIM_ARRAY
(     MDSYS.SDO_DIM_ELEMENT('X',4439900.00, 4440020.00, 0.005),
     MDSYS.SDO_DIM_ELEMENT('Y', 5664050.00, 5664130.00, 0.005),
     MDSYS.SDO_DIM_ELEMENT('Z', 0, 200, 0.005)
31468
-- spatial index
CREATE
INDEX ta_3dgeb_index ON ta_3dgeb(geom3d) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('SDO_INDX_DIMS=3');
*2. insert 2d-geomtry*
INSERT
INTO
ta_geb
VALUES
MDSYS.SDO_GEOMETRY(
2003
,31468
,NULL
,MDSYS.SDO_ELEM_INFO_ARRAY(
1
,1003
,1
,MDSYS.SDO_ORDINATE_ARRAY(
     4439975.91,5664077.07,
          4439967.98,5664072.06,
          4439975.33,5664060.42,
          4439983.26,5664065.43,
          4439975.91,5664077.07
,null --area
*3. calculate volume of the extruded area*
SELECT SDO_GEOM.SDO_VOLUME(SDO_UTIL.EXTRUDE(
     GEOM,
     SDO_NUMBER_ARRAY(0),
     SDO_NUMBER_ARRAY(10),
     'false', --validation
     0.005),0.005)
from ta_geb;
This works fine so far. Now I wanna insert the extruded geometry (now 3D) in the table ta_3dgeb. All my attempts were in vain...
*4. insert extruded geomtry*
INSERT
INTO
ta_3dgeb
select
SDO_UTIL.EXTRUDE(
          GEOM,
          SDO_NUMBER_ARRAY(0),
          SDO_NUMBER_ARRAY(10),
          'false', --validation
          0.005)
from ta_geb;
I got the following error message after executing this Code:
ORA-29875: failed in the execution of the ODCIINDEXINSERT routine
ORA-13365: layer SRID does not match geometry SRID
ORA-06512: in "MDSYS.SDO_INDEX_METHOD_10I", line 709
ORA-06512: in "MDSYS.SDO_INDEX_METHOD_10I", line 225
Then I tried to change something on the metadata and spatial indices, wihtout success. Does anyone has advices to solve the problem??
Afterwards I would like to export the 3d-geometry in a KML file to visualize it in Google Earth. Therefore oracle provides a tool. But I didn't managed it to export the geometry. Any hints for the KML export or are there any other tools alternatively??
Thanks for any suggestions!
Regards

Extrude does not automatically populate the SRID for the resulting geometry as there may not be a 3D equivalent of the 2D SRID defined
in the DB.
So the extruded geometry comes out without the SRID. In your case, since you are creating an index on the ta_3dgeb table
before inserting the extruded data, it is causing this failure.
So drop the index on the ta_3dgeb table and do the inserts into it.
Then you can manually update the geometries with the SRID if there is a corresponding 3D SRID for 31468.
Otherwise, you can use 31468.
siva

Oracle Spatial - inserts/updates to geometry tables

I am getting the following errors when inserting into an SDO_GEOMETRY object type:
java.sql.SQLException: ORA-29877: failed in the execution of the ODCIINDEXUPDATE routine
ORA-13000: dimension number is out of range
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 8
ORA-06512: at "MDSYS.SDO_IDX", line 86
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 83
ORA-06512: at line 1
I have looked in the Oracle Spatial User Guide for 8i and have not been able to find much on the information above.
Any help from inviduals with more expertise in this area would be great. If I need to provide more information please do indicate this as well
Thanks,
Faroon.

Hi,
The number of dimensions in the object being inserted may be
out of the valid range ( 2 to 4).
Or the diminfo in the user_sdo_geom_metadata for this
layer has been changed the after the index is created.
Check these two places first to make sure the dimensionality
is in the valid range.
The error is raised on index updated when the dimensionality
of the object being updated is not in the valid range.
siva

Loading shapefiles into Oracle Spatial

Fellow Oracle Spatiallers!
Currently we edit Oracle Spatial data by checking data out into a shapefile,
making our changes off-line, and reloading the shapefile back into Oracle.
Instead of using the Oracle Spatial supplied tool, we decided to purchase
a utility called the "Spatial Loader" from a company called Geometry Pty Ltd
(http://www.geometryit.com). There are a number of reasons why we decided to
go that way which might become evident from the command line parameters of
this utility:
Usage: Shp2Spt [Arguments] [Options]
OR
Usage: Java com.geometryit.spatialloader.oracle.AdvancedJavaSpatialTranslator [Arguments] [Options]
[Arguments] must specify these values:
-o create
type of operation to perform
create creates a new table, must not exist already
recreate creates a new table, may exist already
init drops existing table, creates a new one
append appends data onto existing table
-f <shape_file>
the shape file or project to translate
-l <table,column>
target table and column for the geometry data
-D <database>
target database name
-u <username>
username for RDBMS
-p <password>
password for RDBMS
[Options] values are not necessarily required:
-s <server_name>
name of server with database
-port <port_number>
the port to connect to on the server
-ufi <column_name>
specify the name of the UFI field (unique ID)
-seq <sequence_name>
specify the sequence to use for the spatial data unique IDs
-a none
attributes mode
none no attributes will be transferred
all all attribtues will be transfered as found
file= file containing lines of the form:
<shape_attribute><space/tab><rdbms_column>
where
<shape_attribute> selects the column to be output
<rdbms_column> name of the column in RDBMS
-srid <id>
specify the Spatial Reference ID for the spatial data
(this must be set to use Spatial Reference Transformations)
-i [<level>] or -i rtree
create an index for the generated table
the <level> parameter is an optional integer
representing the depth of the quadtree created
if rtree is specified, the index created will be
an rtree
-c <commit_interval>
number of rows to commit after
-t <tolerance>
tolerance value for metadata
-r none
used to determine number of decimal places to round vertices to
if you use the tolerance-parameter option, specify the -t parameter before -r
-igc
ignore geometry collections
-sgc
split geometry collections
-sgd f
split geometry direction [forward | reverse]
-update-metadata <true/false>
update the Oracle Spatial Metadata table after loading data
-validate <true/false>
perform Oracle Spatial validation after loading data
-v
verbose mode on
-h or -?
display this help message
The main things I like about this tool are:
1. One step (no conversion to sqlloader form followed by a call to the sqlloader).
2. The ability to round the coordinates of the shapes in the shapefile by applying
the XY tolerance values held in the SDO_GEOM_METADATA table.
This is quite important because our editing package - due to double/single precision
issues - can actually move coordinates but those movements are sub the precision of
the actual data. By rounding to the nominate precision we can detect situations where
no actual change to the shape (and its attributes) was made and thus not create superfluous
revisions within the database.
3. It will correctly re-wind the coordinates of the outer/inner shells of polygons. This is
important as ESRI shapefiles are agnostic on the winding order: an outer shell coordinates
can be listed in either clockwise or anti-clockwise order.
4. You can specify the primary key (UFI) column (numeric) and an Oracle Sequence number such
that each new shape loaded can have its UFI assigned from that sequence.
Because of this flexibility, and the excellent support (it is a purchasable product) from the
developers, I can heartily recommend this loader to fellow Spatiallers. It is worth every
penny I spent on it. Try the free version on their website and if, like me, you like it,
purchase it!
regards
Simon

Hi Shuan,
As part of the zip file created for the next training course to be posted for Oracle Spatial on OTN (within the next few weeks) there is a free (unsupported, undocumented) version of a shape to sdo converter. This should work, but it is unsupported. It will create a layer that then needs to be migrated into 8.1.6 format.
If you need it quite soon send email to [email protected] and I can get it to you.
Hope this helps,
dan

Oracle Spatial Performance with 10-20.000 users

Does anyone have any experience when Oracle Spatial is used with say 20.000 concurrent users. I am not interested in MapViewer response time, but lets say there is:
- an app using 800 different tables each having an sdo_geometry column
- the app is configured with different tables visible on different view scales
- let's say an average of 40-50 tables is visible at any given time
- some tables will have only a few records, while other can hold millions.
- there is no client side caching
- clients can zoom in/out pan.
Anwers I am interested in:
- What sort of server would be required
- How can Oracle serve all that data (each Refresh renders the map and retrieves the data over the wire as there is no client side caching).
- What sort of network infrastructure would be required.
- Can clients connect to different servers and hence use load balancing or does Oracle have an automatic mechanism for that?
Thanks in advance,
Patrick

Patrick, et al.
There are lots of things one can do to improve performance in mapping environments because of a lot of the visualisation is based on "background" or read-only data. Here are some "tips":
1. Spatially sort read-only data.
This tip makes sure that data that is close to each other in space are next to each other on disk! Dan gave a good suggestion when he referenced Chapter 14, "Reorganize the Table Data to Minimize I/O" pp 580- 582, Pro Oracle Spatial. But just as easily one can create a table as select ... where sdo_filter() where the filtering object is an optimized rectangle across the whole of the dataset. (This is quite quick on 10g and above but much slower on earlier releases.)
When implementing this make sure that the created table is created such that its blocks are next to each other in the tablespace. (Consider tablespace defragmentation beforehand.) Also, if the data is READ ONLY set the PCTFREE to 0 in order to pack the data up into as small a number of blocks as possible.
2. Generalise data
Rendering spatial data can be expensive where the data is geometrically detailed (many vertices) esp where the data is being visualised at smaller scales than it was captured at. So, if your "zoom thresholds" allow 1:10,000 data to be used at 1:100,000 then you are going to have problems. Consider pre-generalising the data (see sdo_util.simplify) before deployment. You can add multiple columns to your base table to hold this data. Be careful with polygon data because generalising polygons that share boundaries will create gaps etc as the data is more generalised. Often it is better to export the data to a GIS which can maintain the boundary relationships when generalising (say via topological relationships).
Oracle's MapViewer has excellent on-the-fly generalisation but here one needs to be careful. Application tier caching (cf Bryan's comments) can help here a lot.
3. Don't draw data that is sub-pixel.
As one zooms out objects become smaller and smaller until they reach a point where the whole object can be drawn within a single pixel. If you have control over your map visualisation application you might want to consider setting the SDO_FILTER parameter "min_resolution" flag dynamically so that its value is the same as the number of meters / pixel (eg min_resolution=10). If this is set Oracle Spatial will only include spatial objects in the returned search set if one side of a geometry's MBR is greater than or equal to this value. Thus any geometries smaller than a pixel will not be returned. Very useful for large scale data being drawn at small scales and for which no selection (eg identify) is required. With Oracle MapViewer this behaviour can be set via the generalized_pixels parameter.
3. SDO_TOLERANCE, Clean Data
If you are querying data other than via MBR (eg find all land parcels that touch each other) then make sure that your sdo_tolerance values are appropriate. I have seen sites where data captured to 1cm had an sdo_tolerance value set to a millionth of a meter!
A corollary to this is make sure that all your data passes validation at the chosen sdo_tolerance value before deploying to visualisation. Run sdo_geom.validate_geometry()/validate_layer()...
4. Rtree Spatial Indexing
At 10g and above lots of great work went in to the RTree indexing. So, make sure you are using RTrees and not QuadTrees. Also, many GIS applications create sub-optimal RTrees by not using the additional parameters available at 10g and above.
4.1 If your table/column sdo_geometry data contains only points, lines or polygons then let the RTree indexer know (via layer_gtype) as it can implement certain optimizations based on this knowledge.
4.2 With 10g you can set the RTree's spatial index data block use via sdo_pct_free. Consider setting this parameter to 0 if the table/column sdo_geometry data is read only.
4.3 If a table/column is in high demand (eg it is the most commonly used table in all visualisations) you can consider loading (a part of) the RTree index into memory. Now, with the RTree indexing, the sdo_non_leaf_tbl=true parameter will split the RTree index into its leaf (contains actual rowid reference) and non-leaf (the tree built on the leaves) components. Most RTrees are built without this so only the MDRT*** secondary tables are built. But if sdo_non_leaf_tbl is set to true you will see the creation of an additional MDNT*** secondary table (for the non_leaf part of the rtree index). Now, if appropriate, the non_leaf table can be loaded into memory via the following:
ALTER TABLE MDNT*** STORAGE(BUFFER_AREA KEEP);
This is NOT a general panacea for all performance problems. One should investigate other options before embarking on this (cf Tom Kyte's books such as Expert Oracle Database Architecture, 9i and 10g Programming Techniques and Solutions.)
4.4 Don't forget to check your spatial index data quality regularly. Because many sites use GIS package GUI tools to create tables, load data and index them, there is a real tendency to not check what they have done or regularly monitor the objects. Check the SDO_RTREE_QUALITY column in USER_SDO_INDEX_METADATA and look for indexes with an SDO_RTREE_QUALITY setting that is > 2. If > 2 consider rebuilding or recreating the index.
5. The rendering engine.
Whatever rendering engine one uses make sure you try and understand fully what it can and cannot do. AutoDesk's MapGuide is an excellent product but I have seen it simply cache table/column data and never dynamically access it. Also, I have been at one site which was running Deegree and MapViewer and MapViewer was so fast in comparison to Deegree that I was called in to find out why. I discovered that Deegree was using SDO_RELATE(... ANYINTERACT ...) for all MBR queries while MapViewer was using SDO_FILTER. Just this difference was causing some queries to perform at < 10% of the speed of MapViewer!!!!
6. Consider "denormalising" data
There is an old adage in databases that is "normalise for edit, denormalise for performance". When we load spatial data we often get it from suppliers in a fairly flat or normalised form. In consort with spatial sorting, consider denormalising the data via aggregations based on a rendering attribute and some sort of spatial unit. For example, if you have 1 million points stored as single points in SDO_GEOMETRY.SDO_POINT which you want to render by a single attribute containing 20 values, consider aggregating the data using this attribute AND some sort of spatial BUCKET or BIN. So, consider using SDO_AGGR_UNION coupled with Spatial Analysis and Mining package functions to GROUP the data BY <<column_name>> and a set of spatial extents.
6. Tablespace use
Finally, talk to your DBA in order to find out how the oracle database's physical and logical storage is organised. Is a SAN being used or SAME arranged disk arrays? Knowing this you can organise your spatial data and indexes using more effective and efficient methods that will ensure greater scalability.
7. Network fetch
If your rendering engine (app server) and database are on separate machines you need to investigate what sort of fetch sizes are being used when returning data from queries to the middle-tier. Fetch sizes for attribute only data rows and rows containing spatial data can be, and normally are, radically different. Accepting the default settings for these sizes could be killing you (as could the sort_area_size of the Oracle session the application server has created on the database). For example I have been informed that MapInfo Pro uses a fixed value of 25 records per fetch when communicating with Oracle. I have done some testing to show that this value can be too small for certain types of spatial data. SQL Developer's GeoRaptor uses 100 which is generally better (but this one can modify this). Most programmers accept defaults for network properties when programming in ADO/ODBC/OLEDB/JDBC: just be careful as to what is being set here. (This is one of the great strengths of ArcSDE: its TCP/IP network transport is well written, tuneable and very efficient.)
8. Physical Format
Finally, while Oracle's excellent MapViewer requires data its spatial data to be in Oracle, other commercial rendering engines do not. So, consider using alternate, physical file formats that are more optimal for your rendering engine. For example, Google Earth Enterprise "compiles" all the source data into an optimal format which the server then serves to Google Earth Enterprise clients. Similarly, a shapefile on local disk to the application server (with spatial indexing) may be faster that storing the data back in Oracle on a database server that is being shared with other business databases (eg Oracle financials). If you don't like this approach and want to use Oracle only consider using a dedicated Oracle XE on the application server for the data that is read only and used in most of your generated maps eg contour or drainage data.
Just some things to think about.
regards
Simon

Simon Greener's Morton Key Clustering in Oracle Spatial

Hi folks,
Apologies for the rambling. With mattyschell heading for greener open source big apple pastures I am looking for new folks to bounce ideas and code off. I was thinking this week about the discussion last autumn over spatial clustering.
https://community.oracle.com/thread/3617887
During the course of the thread we all kind of pooh-poohed spatial clustering as not much of solution, myself being one of the primary poohers. Yet the concept certainly remains as something to consider regardless of our opinions. The yellow book, the Greener/Ravada book, Simon's recent treatise (http://download.oracle.com/otndocs/products/spatial/pdf/biwa_2015/biwa2015_uc_comparativeperformance_greener.pdf), they all put forward clustering such that at the very least we should consider it a technique we should be able as professionals to do - a tool in the toolbox whether or not it always is the right answer. I am mildly (very mildly) curious to see if Kothuri, Godfrind and Beinat will recycle their section on spatial clustering with the locked-down MD.HHENCODE into their 12c revision out this summer. If they don't then what is the replacement for this technique? If they do then we return to all of our griping about this ancient routine that Simon implies may date back to the CHS and their hhcode indexes - at least its not written in Java!
Anyhow, so I've been in the midst this month of refreshing some of the datasets I manage and considering clustering the larger tables whilst I am at it. Do I really expect to see huge performance gains?   Well... not really. But it does seem like something that should be easy to accomplish, certainly something that "doesn't hurt" and shows that I am on top of things (e.g. "checks the box"). But returning to the discussion from last fall, just what is the best way to do this in Oracle Spatial?
So if we agree to ignore poor old MD.HHENCODE, then what? Hilbert curves look nifty but no one seems to be stepping up with the code for them. And this reroutes us back around to Simon and his Morton key code.
http://www.spatialdbadvisor.com/oracle_spatial_tips_tricks/138/spatial-sorting-of-data-via-morton-key
So who all is using Simon's code currently? If you read that discussion from last fall there does not seem to be anyone doing so and we never heard back from Cat Person on either what he decided to do or what his name is.
I thought I could take a stab at streamlining Simon's process somewhat to make things easier for myself to roll this onto many tables. I put together the following small package
https://github.com/pauldzy/DZ_SDO_CLUSTER/tree/master/Packages
In particular I wanted to bundle up the side issues of how to convert your lines and polygons into points, automate things somewhat and provide a little verification function to see what results look like. So again nothing that Simon does not already walk through on his webpage, just make it bit easier to bang out on your tables without writing a separate long SQL process for each one.
So for example to use Simon's Morton key logic, you need to know the extent envelope of the data (in order to define a proper grid). So if its a large table, you'd want to stash the envelope info in the metadata. You can do this with the update_metadata_envelope procedure or just suffer through the sdo_aggr_mbr each time if you don't want to go that route (I have one table of small watershed polygons that takes about 9 hours to run sdo_aggr_mbr upon). So just run things at the sql prompt
SELECT
DZ_SDO_CLUSTER.MORTON_UPDATE(
    p_table_name => 'CATCHMENT_NP21'
   ,p_column_name => 'SHAPE'
   ,p_grid_size => 1000
FROM dual;
This will return the update clause populated with the values to use with the morton_key wrapper function, e.g. "morton_key(SHAPE,160.247133275879,-17.673722530871,.0956820001136141,.0352063207508021)". So then just paste that into an update statement
UPDATE foo
SET my_morton_key = dz_sdo_cluster.morton_key(
    SHAPE
   ,160.247133275879
   ,-17.673722530871
   ,.0956820001136141
   ,.0352063207508021
Then rebuild your table sorting on the morton_key. I just use the TOAD rebuild table tool and manually add the order by clause to the rebuild script. I let TOAD do all the work of moving the indexes, constraints and grants to the new table. I imagine there are other ways to do this.
The final function is meant to be popped into Oracle mapviewer or something similar to show your family and friends the results.
SELECT
dz_sdo_cluster.morton_visualize(
    'NHDPLUS'
   ,'NHDFLOWLINE_NP21_ACU'
   ,'SHAPE'
   ,'OBJECTID'
   ,'100'
   ,10000
   ,'MORTON_KEY'
FROM dual;
Look Mom, there it is!
So anyhow this is first stab at things and interested in feedback or suggestions for improvement. Did I get the logic correct? Don't spare my feelings if I botched something. Note that like Simon I passed on the matter of just how to determine the proper grid size. I've been using 1000 for the continental US + Hawaii/PR/VI and sitting here this morning I think that probably is too large. Of course it depends on the size of the geometries and thus the density of the resulting points. With water features this can vary a lot from place to place, so perhaps 1000 is okay. What would the algorithm be to determine a decent grid size? It occurs to me I could tell you the average feature count per morton key value, okay well its about 10. That seems small to me. So I could see another function in this package that returns some kind of summary on the results of the keying to tell you if your grid size estimate was reasonable.
Cheers and Happy Saturday,
Paul

I've done some spatial clustering testing this week.
Firstly, to reiterate the purpose of spatial clustering as I see it: spatial clustering can be of benefit in situations where frequent window based spatial queries are made. In particular it can be very useful in web mapping scenarios where a map server is requesting data using SDO_FILTER or SDO_ANYINTERACT and there is a need to return the data as quickly as possible. If the data required to satisfy the query can be squeezed into as few blocks as possible, then the IO overhead is clearly reduced.
As Bryan mentioned above, once the data is in the buffer cache, then the advantage of spatial clustering is reduced. However it is not always possible to get/keep enough of the data in the buffer cache, so I believe spatial clustering still has merits, particularly if it can be implemented alongside spatial partitioning.
I ran the tests using an 11.2.0.4 database on my laptop. I have a hard disk rather than SSD, so the effects of excessive IO are exaggerated. The database is configured with the default 8kb block size.
Initially, I created a table PARCELS:
create table parcels (
id            integer,
created_date date,
x            number,
y            number,
val1          varchar2(20),
val2          varchar2(100),
val3          varchar2(200),
geometry      mdsys.sdo_geometry,
hilbert_key number);
I inserted 2.8 million polygons into this table. The CREATED_DATE is the actual date the polygons were captured. I populated val1, val2 and val3 with string values to pad the rows out to simulate some business data sitting alongside the sdo_geometry.
I set X,Y to the first ordinate of the polygon and then set hilbert_key = sdo_pc_pkg.hilbert_xy2d(power(2,31), x, y).
I then created 4 tables to base the tests upon:
PARCELS_RANDOM: Ordered by dbms_random.random - an absolute worst case scenario. Unrealistic, but worthwhile as a benchmark.
PARCELS_BASE_DATE: Ordered by CREATED_DATE. This is probably pretty close to how the original source data is structured on disk.
PARCELS_RTREE: Ordered by RTree. Achieved by inserting based on an SDO_FILTER query
PARCELS_HILBERT: Ordered by the hilbert_key attribute
As a first test, I counted the number of blocks required to satisfy an SDO_FILTER query. E.g.
select count(distinct(dbms_rowid.rowid_block_number(rowid)))
from parcels_rtree
where sdo_filter(geometry,
                sdo_geometry(2003, 2157, null, sdo_elem_info_array(1, 1003, 3),
                                sdo_ordinate_array(644232,773809, 651523,780200))) = 'TRUE';
I'm assuming dbms_rowid.rowid_block_number(rowid) is suitable for this.
I ran this on each table and repeated it over three windows.
Results:
So straight off we can see that the random ordering gave pretty horrific results as the data required to satisfy the query is spread over a large number of blocks. The natural date based clustering was far better. RTree and Hilbert based clustering reduced this by a further 50% with Hilbert just nosing out RTree.
Since web mapping is the use case I am most likely to target, I then setup a test case as follows:
Setup layers in GeoServer for each of the tables
Used a script to generate 1,000 random squares over the extent of the data, ranging from 200m to 500m in width and height.
Used JMeter to make a WMS request for a png of the each of the 1,000 windows. JMeter was run sequentially with just one thread, so it waited for each request to complete before starting the next. I ran these tests 3 times to balance out the results, flushing the buffer cache before each run.
Results:
Again the random ordering performed woefully bad - somewhat exacerbated by the quality of the disk on my laptop. The natural date based clustering performed far better. RTree and hilbert based clustering further reduced the time by more than half.
In summary, the results suggest that spatial clustering is worth the effort if:
the data is not already reasonably well clustered
you've got a decent quantity of data
you're expecting a lot of window based queries which need to be returned as quickly as possible
you don’t expect to be able to fit all the data in the buffer cache
When it comes to deciding between RTree and Hilbert (or Morton/z-order or any other space filling curve method).... I found that the RTree method can be a bit slow on large datasets, although this may not matter as a one off task. Plus it requires a spatial index on the source table to start off with. The key based methods are based on an xy, so for lines and polygons there is an intermediate step to extract an xy. I would tend to recommend this approach if you also partition the data based on a subset of the cluster key.
Scripts are available here: https://github.com/john-otoole/oracle_spatial_cluster_test
John

Accessing Oracle spatial objects (SDO_GEOMETRY) through ODBC/OLEDB

Hello.
I tried googling and reading through these forums and Oracle documentation, but I'm still uncertain on this question:
Are Oracle spatial objects (of type SDO_GEOMETRY) accessible through ODBC and/or OLE DB drivers? Can I retrieve them with SELECT clause? Can I write them to database?
I'm limited to these options because I'm developing Delphi application based on ADO and it must work with different DB servers. However I certainly don't want to implement different ways of accessing database for each server.
If geometry objects aren't suported by ODBC/OLEDB, is there any way to convert SDO_GEOMETRY to (and from) BLOB or string or whatever, so I can read and write them like a normal data field?
Thanks in advance.
Edited by: user13816863 on 25.01.2011 20:35
Edited by: user13816863 on 25.01.2011 21:57

The SDO_UTIL package has lots of options to help output spatial data to other formats, and you may be able to use some of them to help.
Some that come to mind are:
SDO_UTIL.TO_WKTGEOMETRY
SDO_UTIL.TO_GMLGEOMETRY
SDO_UTIL.TO_KMLGEOMETRY
This is covered in chapter 32 of the Oracle® Spatial Developer's Guide 11g Release 2 (11.2).

SDO_NN with Oracle Spatial

Hello,
although the description of my problem is a bit long, I hope you could help me.
I would like to compute the nearest neighbor of a point being located on the surface of the unit sphere.
For that query, I would like to take advantage of the features provided by Oracle Spatial (10g).
Table spatial_test contains the columns point_name, x, y, z, ra, dec where:
point_name is the primary key
x, y, z are the coordinates of the points on the unit sphere (so x^2+y^2+z^2=1)
ra, dec are the the concerning spherical coordinates where the following conditions hold: x=cos(dec)*cos(ra) , y=cos(dec)*sin(ra), z=sin(dec).
For computing the nearest neighbor of a point with point_name='point1' the query without using Oracle Spatial is:
select * from(
select
acos(t1.x*t2.x+t1.y*t2.y+t1.z*t2.z) as distance, t1.*
from spatial_test t1,
spatial_test t2
where t2.point_name='point1'
and t1.name != t2.name
order by dist
where rownum<2;
For taking advantage of Oracle Spatial, I have to prepare my data doing the following five steps:
1. add a column to of type SDO_GEOMETRY to table spatial_test
2. insert values to that table
3. update table user_sdo_geom_metadata
4. create the spatial index
5. execute the following query on the amended table spatial_test:
SELECT t1.point_name name1, t2.point_name name2 FROM spatial_test t1, spatial_test t2
WHERE SDO_NN(t2.geom, t1.geom, 'sdo_num_res=2') = 'TRUE'
and t1.point_name = 'point1'
and t1.point_NAME != t2.point_name
As mentioned in the User Guide for Oracle Spatial, only two dimensional objects are supported.
So, if I insert tuples in the following form to my table:
insert into spatial_test (point_name, x, y, z, geom) values (..., ..., ..., ...,
SDO_GEOMETRY(3001,
NULL, --SDO_SRID is null, so no coordinate system is associated with the geometry
SDO_POINT_TYPE(x_value, y_value, z_value),
NULL,
NULL));
I won't get the correct results. I assume that the z_value is just ignored. Am I right with that assumption?
For using Oracle Spatial, I have to use the equivalent just using two dimensions. Since ra, dec is another representation for x, y, z, I tried to do the same, just using ra and dec. But here, my results also differ from the ones computed with my own computation of the nearest neighbor.
Here an minimal example which shows my problem:
CREATE TABLE spatial_test(
point_name varchar(20) PRIMARY KEY,
x float,
y float,
z float,
ra float,
dec float,
geom SDO_GEOMETRY);
-- INSERT POINTS --
insert into spatial_test(point_name, x, y, z, ra, dec, geom) values ('point1', -0.00472924, 0.110927216, 0.99381728, 92.44125, 83.62542,
SDO_GEOMETRY(2001, -- 2 dimensions, last dimension is the measure, geometry type 01 = point
NULL, --SDO_SRID is null, so no coordinate system is associated with the geometry
SDO_POINT_TYPE(92.44125, 83.62542, null),
NULL,
NULL));
insert into spatial_test(point_name, x, y, z, ra, dec, geom) values ('point2', -0.00239923, 0.112814014, 0.993613226, 91.21833, 83.52097,
SDO_GEOMETRY(2001, -- 2 dimensions, last dimension is the measure, geometry type 01 = point
NULL, --SDO_SRID is null, so no coordinate system is associated with the geometry
SDO_POINT_TYPE(91.21833, 83.52097, null),
NULL,
NULL));
insert into spatial_test(point_name, x, y, z, ra, dec, geom) values ('point3', -0.00701052, 0.122780703, 0.992409065, 93.26792, 82.93584,
SDO_GEOMETRY(2001, -- 2 dimensions, last dimension is the measure, geometry type 01 = point
NULL, --SDO_SRID is null, so no coordinate system is associated with the geometry
SDO_POINT_TYPE(93.26792, 82.93584, null),
NULL,
NULL));
-- UPDATA user_sdo_geom_metadata --
INSERT INTO user_sdo_geom_metadata
(TABLE_NAME,
COLUMN_NAME,
DIMINFO,
SRID)
VALUES (
'spatial_test',
'geom',
MDSYS.SDO_DIM_ARRAY(
MDSYS.SDO_DIM_ELEMENT('ra', 0.0, 360.0, 0.0000000000001),
MDSYS.SDO_DIM_ELEMENT('dec', -90.0, 90.0, 0.0000000000001)
NULL -- no specific coordinate system should be associated with the geometries.
-- CREATE THE SPATIAL INDEX --
CREATE INDEX spatial_test_idx
ON spatial_test(geom)
INDEXTYPE IS MDSYS.SPATIAL_INDEX;
Now I could execute the following queries which should both compute the nearest neighbor of 'point1'.
This is the statement computing the nearest neighbor without Oracle Spatial:
select * from(
select
acos(t1.x*t2.x+t1.y*t2.y+t1.z*t2.z) as distance, t2.point_name p1, t1.point_name p2
from spatial_test t1,
spatial_test t2
where t2.point_name='point1'
and t1.point_name != t2.point_name
order by distance
where rownum<2;
RESULT:
DISTANCE P1 P2
,003005107 point1 point2
With the following statement, I compute the nearest neighbor of 'point1' using Oracle Spatial:
SELECT t1.point_name name1, t2.point_name name2 FROM spatial_test t1, spatial_test t2
WHERE SDO_NN(t2.geom, t1.geom, 'sdo_num_res=2') = 'TRUE'
and t1.point_name = 'point1'
and t1.point_NAME != t2.point_name;
RESULT:
NAME1 NAME2
point1 point3
As you see, unfortunately, the two results differ.
Could you please tell me, what I understood wrong in using Oracle Spatial?
In addition, what kind of coordinate system is assumed if it isn't specified in my SDO_GEOMETRY? Which kind of distance is computed using sdo_nn (euclidean distance, ...)?
Would be glad, if you could tell how to reach the same results for my nearest neighbors using Oracle Spatial.
Regards,
Ina

I would like to compute the nearest neighbor of a
point being located on the surface of the unit
sphere.That would be a spherical 3D computation. Currently, OS does not work well with 3D such as spheres, sorry. I know R2 was supposed to improve on this for cubes and pyramids, but to be honest; I havent had time to go back and test the simple cube operations. With 10gR1, for most of the operators and functions 2,2,3 and 2,2,5 are same point. I know this is something that is being worked on, possibly Dan can comment further.
See for more info:
Re: 3D Polygon
For now, if you have your own routines, Id use them as a package instead. If you need help there, let us know and well try to point you in the right direction or help you to translate the code to PL/SQL.
Bryan

Help define the requirements for an Oracle Spatial management tool

Hi,
We are developing a tool that, we hope, will be indispensable for all Oracle Spatial and Locator dbas/users. We've released version 1.0, but we need your help to define the requirements for the next version.
What features would you like to have in a management tool for your spatial databases?
The features we've got so far:
1. Viewing of vector data in a map + attributes
2. Loading from shapefiles
3. Exporting to shapefiles
4. Validating metadata, indexes and spatial data.
We are adding editing of vectors in the next version - basic stuff for add, update and delete.
But there must be a lot more. What do you find difficult to do in Oracle Spatial/Locator? What would you like in a tool such as this?
Any feedback either to myself or the forum is much appreciated.
cheers,
Andrew
[email protected]
PS If you like to have a look at what we have done so far, go to http://www.geometryit.com/products/spatialConsole.php

Andrew knows what I have asked for but for others to think about and to start
the ball rolling, here's what they are:
1. Ability to enter own SQL commands but with PARAMETERS for attributes
and shapes as in the following examples:
SELECT ...
FROM my_spatial_table a
WHERE a.ATTRIBUTE = :attr
AND MDSYS.SDO_RELATE(a.shape,:polygon,'mask=anyinteract') = 'TRUE'
When executed the attribute value is asked for via a input box (data type?)
and the user is asked to define the SDO_GEOMETRY for the :polgygon parameter via mouse clicks on the screen.
Similarly, this would work for INSERT, UPDATE and DELETE...
INSERT INTO my_spatial_table (shape) values(:polygon)
The data type of an attribute parameter could be determined in two ways:
a) By querying the Oracle catalog;
b) By using a "PARAMETERS" command before the query as follows
PARAMETERS name type [(size)] [, name type [(size)] ...]
The PARAMETERS declaration has these parts:
name     The name of the parameter.
type     The type of the parameter.
size     The size of the parameter in characters or bytes.
2. When executing an SQL SELECT statement I would like the tool
to suggest the HINTS that are needed to improve performance.
3. Following on from 2, I would like to Tick an option that would return the
EXPLAIN PLAN that the query optimizer used when executing my query.
4. The tool has to support ALL Oracle's spatial vector data types.
5. It would be nice to be able to work with GeoRasters. Since Spatial Console
imports/exports shapefiles why not the same for rasters. However, the problem
with supporting foreign data formats is WHERE DO YOU STOP!!!!!
6. You could allow for the styling of the Spatial Console to be stored in the MapViewer catalogs or use the MapViewer catalogs when styling an Sdo_Geometry if it exists (I note that your tool extracts the SDO_METADATA
why not the MapViewer metadata as well)?
regards
S.

How do I know if a function is included in Oracle Spatial or in Locator ?

Hi,
Is there a document that lists which spatial packages are licensed as Locator and which are licence as spatial?
Tamas

Its all listed in Appendix B of the Oracle Spatial Developer's Guide. It varies a little from release to release so you'll need to check the guide for the database release you're on.
John

Package oracle.spatial.geometry

Similar Messages

Maybe you are looking for