TTS SDO_UTIL.INITIALIZE_INDEX_FOR_TTS;

Dear friends,
I am trying to Initialize spatial indexes in a tablespace that was transported to another database.
I am trying it but it shows error as following
SQL> CALL SDO_UTIL.INITIALIZE_INDEX_FOR_TTS;
CALL SDO_UTIL.INITIALIZE_INDEX_FOR_TTS
ERROR at line 1:
ORA-06576: not a valid function or procedure name
if anybody knows about it pls tell me why this error is occuring.
Thanks & Regards
Chandrakishore Bankhede

Thanks Dear ,
for your immediate reply .....
As u suggest I have tried all the following combitation but still it does not work;
SDO_UTIL.INITIALIZE_INDEX*ES*FORTTS;
SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS;
SDO_UTIL.INITIALIZE_INDEX_FOR_TTS;
it gives same error....
Thanks & Regards
Chandrakishore Bankhede

Similar Messages

SDO_UTIL.PREPARE_FOR_TTS and Partitioned Indexes

Does this procedure work with partitioned indexes?
After executing this procedure on tablespace that contains the first partition of the partition index, the table SDO_INDEX_TTS_METADATA$ is empty. In addition, I can only run this procedure once, it fails for each subsequent tablespace which has a partition.
When I execute the procedure on a tablespace with a non partitioned index the SDO_INDEX_TTS_METADATA$ table is populated.

Thanks Dear ,
for your immediate reply .....
As u suggest I have tried all the following combitation but still it does not work;
SDO_UTIL.INITIALIZE_INDEX*ES*FORTTS;
SDO_UTIL.INITIALIZE_INDEXES_FOR_TTS;
SDO_UTIL.INITIALIZE_INDEX_FOR_TTS;
it gives same error....
Thanks & Regards
Chandrakishore Bankhede

How can I set Paul to be the default TTS voice?

Is there a way to set a TTS voice as the default so that it is always selected by default as the voice to use? I have all the voices installed and it currently defaults to Bridget - I guess because that is the first voice in the list. I normally use Paul but sometimes others so I want access to all the voices but would like the default to be Paul. I know that once I set Paul for the first slides, it defaults for that project for the rest of the slides, but I have to do this for every project and if I forget to set Paul then I have to go back and redo the slides. It would be nice if I could set the default to the voice I use the most often. I'm using Captivate 7.

j,
In the Finder, single-click on any text file, then type command-I (Get Info). You'll see an Open With... menu item. Select Pages from the list (if it's not in the list, navigate to it). Finally, click the Change All button. Use the same process for .doc files. Now, if you double-click on any of these files, it should open in Pages.
-Dennis

How to make a tts text-to-speech keyboard shortcut

Hi,
How do I make a tts text-to-speech keyboard shortcut
to control the OSX "Speech" available as a contextual menu
when you right-click selected text in Safari, TextEdit and other native apps
*Speech > Start Speaking*
*Speech > Stop Speaking*
I can get this far:
*System Preferences > Keyboard > Keyboard Shortcuts >*
I have low-vision and need this on as many as possible or all text running on my computer.
Less important: The "Speech" contextual menu is not available right-clicking text in Google Chrome. I could sure use it there too.
THANKS!

If you want it turned on permanently open Universal Access preferences, click on the Seeing tab, turn on VoiceOver. Click on the VoiceOver Application button for more configuration options.
There's also a shortcut option for TTS in the Speech preferences.

Is there a way to quickly make CC notes out of the TTS?

Hello,
My project has TTS notes that are marked up with VTML tags. (For every line, I have at least 2 VTML tags to slow the speed of the spoken text because there is no way to change the spoken-text speed of the entire slide at once, let alone the entire project... : ( For this issue alone, I am looking at switching to Storyline.) Anyway, I also have CC notes, which are essentially identical to the TTS notes, but minus the tags.
Question: Is there a way to copy and paste the TTS notes to the CC notes without doing 1 line at a time? The problem with changing the notes under the heading "notes" is that you are changing both the TTS and CC notes at the same time, and for me these two will look very different. In the end, I need to keep the TTS notes with all of their tags, and I need to have CC notes, which of course do not have the tags. If I could, with a single click, copy and paste all of the TTS notes to CC notes, all I would have to do is delete all of the tags..
I am hoping that I am missing something that will make this a lot easier. Next time I will create the CC notes first, but originally the customer didnt want them..
Thanks for any help!

Hi
Here is the difference.
1. This doesn't work.
2. This works.
Sreekanth

Captivate 4 TTS Audio not playing in published or preview ok in edit

While viewing my project in published view, audio did not play on 5 of my 70 slides. (It worked fine previously). It played Ok in edit but no sound in preview or published. I tried to replace the audio using the Convert TTS button, and the audio would not replace the previous audio. Even removing the audio and dragging the new audio to the timeline would not work. I reinstalled Captivate 4 and TTS, and it seems to work fine on new a new projects but I can not seem to get it to fix my current project. Can anyone advise if I can fix those slides, or have I somehow corrupted those slides? It's a big project. Thanks in advanced

If I ever see dodgy behaviour like this on a slide, and it doesn't resolve easily with a reboot or republish, I just recreate the slides and delete the old ones. It's often far quicker to do this than muck around trying to fix them. If there is corruption in a slide, you don't want it anywhere in your project.

Errors in sdo_util on 12c

I have installed spatial on an Oracle 12C database and I am receiving the error below when using sdo_util.to_wktgeometry. Some of the other sdo_util functions work as expected. I checked the class files and they are all valid. Has anyone else encountered this error.
ORA-29531: no method structToWktJS in class oracle/spatial/util/Adapters
ORA-06512: at "MDSYS.SDO_JAVA_STP", line 350
ORA-06512: at "MDSYS.SDO_UTIL", line 2813
ORA-06512: at "MDSYS.SDO_UTIL", line 2836
29531. 00000 - "no method %s in class %s"
*Cause:    An attempt was made to execute a non-existent method in a
           Java class.
*Action:   Adjust the call or create the specified method.

I am not getting any error, as shown below, using a few excerpts from the online documentation. Can you run the same or similar script without error? Can you post a run of a test case that does produce the error for you?
SCOTT@orcl12c> set long 2000;
SCOTT@orcl12c> SELECT banner FROM v$version;
BANNER
Oracle Database 12c Enterprise Edition Release 12.1.0.1.0 - 64bit Production
PL/SQL Release 12.1.0.1.0 - Production
CORE    12.1.0.1.0    Production
TNS for 64-bit Windows: Version 12.1.0.1.0 - Production
NLSRTL Version 12.1.0.1.0 - Production
5 rows selected.
SCOTT@orcl12c> CREATE TABLE cola_markets
2    (mkt_id    NUMBER PRIMARY KEY,
3      name    VARCHAR2(32),
4      shape    SDO_GEOMETRY);
Table created.
SCOTT@orcl12c> INSERT INTO cola_markets VALUES
2    (2, 'cola_b',
3      SDO_GEOMETRY
4        (2003, NULL, NULL,
5         SDO_ELEM_INFO_ARRAY (1,1003,1),
6         SDO_ORDINATE_ARRAY(5,1, 8,1, 8,6, 5,7, 5,1)));
1 row created.
SCOTT@orcl12c> INSERT INTO user_sdo_geom_metadata (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES
2    ('cola_markets', 'shape',
3      SDO_DIM_ARRAY
4        (SDO_DIM_ELEMENT('X', 0, 20, 0.005),
5         SDO_DIM_ELEMENT('Y', 0, 20, 0.005)),
6      NULL);
1 row created.
SCOTT@orcl12c> CREATE INDEX cola_spatial_idx ON cola_markets(shape) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
Index created.
SCOTT@orcl12c> SELECT SDO_UTIL.TO_WKTGEOMETRY (shape) FROM cola_markets WHERE name = 'cola_b';
SDO_UTIL.TO_WKTGEOMETRY(SHAPE)
POLYGON ((5.0 1.0, 8.0 1.0, 8.0 6.0, 5.0 7.0, 5.0 1.0))
1 row selected.

Using SDO_UTIL.GETVERTICES() together with functions

Hi again
I'm having a problem here in my spatial database I trying to use the function
TABLE(SDO_UTIL.GETVERTICES(c.shape)) in order to get the coordinates of shapes. But I need to first extract data from spatial functions like the centroid function. How do I get these 2 functions to work together.
thanks very much
Thomaz

Hi Thomaz,
Maybe I missed your point, but what about the following:
select t.y, t.x, t.id
from your_geom_table,
table(
sdo_util.GETVERTICES(
sdo_geom.sdo_centroid(geom, 0.005)
) t
regards,
Thomas

Problems with TTS user dictionary with Captivate 8

Hi There, We have installed Captivate 8 on 2 machines at work. We need to use Neo Speech and will be looking to add and modify pronunciations. We are having some issues with TTS. Firstly on my machine I can modify words and save the dictionary but hear messages to say that this is the trial version of Neo Speech. Is there something else I need to install to avoid this?
My colleague cannot use the dictionary on her machine at all as when she tries to open the user dictionary it comes up with a message to say "TTS failed to load" although she has all the voices installed in the same way as mine. Does anyone else have this problem? Have any patches been released that our IT department need to install? Any help is gratefully received as we have a number of big projets with very short deadlines and these issues are really holding us up. Many thanks

Hi Janet,
Here is the workflow to change the pronunciation of a word for Bridget voice. you can follow same flow for others too.
1) open file. "C:\Program Files\Adobe Captivate Voices 8\VT\Bridget\M16\bin\UserDicBre.exe" in your case(win 32)
2) This will open following window.
3) Click on file open and select the default file. this will populate word information table on this window. above screen shot i have already selected the file.
4) if the word for which you want to change the pronunciation is already in the list then just select the word and click on Modify word and then just modify the pronunciation.
5) In case if you want to add your own word then use add word.
6) In case you want to override some spell pronunciation just add that word as new word with relevant pronunciation.
7) Once all the change is done, just click on File Save button and then click on close, if in case again it ask for save then again save it.
That's it.. you have successfully added/changed pronunciation for a word.
To test it just use TTS functionality of Captivate and generate an audio, or even you can spot test using read word functionality.
Hope above steps are helpful and for your colleague's system I am not sure what steps your IT team is opting to install that. In case if possible can you get exact steps. I prefer try in some fresh machine. Let me know whether the above steps are helpful.
Regards
Shriyansh
Adobe Engineering Team,

SDO_UTIL.PREPARE_FOR_TTS

I'm using this procedure as documented prior to exporting my metadata in preparation of transporting a tablespace to another database. I noticed that after this procedure is run, there is an addition parameter listed in the parameters column of ALL_INDEXES: TTS_TABLE=SDO_INDEX_TTS_METADATA$
If I run this procedure multiple times, as if I were going to transport this tablespace to yet another database, it placed yet another TTS_TABLE=SDO_INDEX_TTS_METADATA$ into the parameters column.
Does anyone out there know if this is a problem. Should I open a TAR on this problem.
I will be doing this at least 5 times (setting of 5 replica's of a master site) prior to turning on Advanced Replication.

Hi Paul,
I'm looking forward to hearing you work the term "fancy hat" into an explanation of this behavior.
I get the same behavior on 11.2.0.2. Tsk tsk on you for not mentioning your version. Back on 10.2.0.4 the same select statements yield:
ORA-06531: Reference to uninitialized collection
ORA-06512: at "MDSYS.SDO_UTIL", line 344
So the only nuance I can think of, which isn't really a nuance at all, is that getnumvertices isn't allowed for point types.
Matt

SDO_UTIL.FROM_WKTGEOMETRY doing some odd math

Hello,
Can anyone explain simply what's going on here with the WKT transformation? Why are the coordinates snapping to some kind of grid? How do I control this and where is this documented? Why would I want my coordinates to go from 14 digits of precision to 38 digits? I get the same results with the straightforward use of FROM_WKTGEOMETRY where the fucntion
{color:#008000}SELECT
MDSYS.SDO_GEOMETRY(
'GEOMETRYCOLLECTION(POLYGON((
-76.57573699951172 38.91845748333781,
-76.57571822404861 38.91807558545071,
-76.57517105340957 38.918440788391166,
-76.57573699951172 38.91845748333781
',8265)
from dual{color}
results in
{color:#008000}SDO_GEOMETRY
2004,
8265,
NULL,
SDO_ELEM_INFO_ARRAY
1,
1003,
1
SDO_ORDINATE_ARRAY
-76.57573699951171875,
38.91845748333781074279613676480948925018,
-76.575718224048614501953125,
38.91807558545070833133650012314319610596,
-76.575171053409576416015625,
38.9184407883911660519515862688422203064,
-76.57573699951171875,
38.91845748333781074279613676480948925018
{color:#000000}Thanks,
Paul{color}
{color}

Hello Siva,
Thanks for answering my question, I appreciate your time. I would argue that the primary problem here is the utter lack of any documentation concerning this issue by Oracle. I am glad that Oracle will correct this in "the next version". Does that include 10g or just 11g? Does that mean that these utilities will be converted from java into the core database or just rewritten better in java?
My organization serves basically as data middlemen and processors. We take data from various sources and then host it for services and analysis by our clients. The expectation is that we are not changing the source data beyond our documented processes (reprojection, etc). It not uncommon for a client to compare our output with the original data to see if we are following their specifications. As GIS professionals we value our ability to pass this scrutiny. I would argue that this java number jumble creates the impression of sloppiness. I do understand that this is meaningless in spatial terms.
Lets look at my triangle again:
Original valid WKT triangle from source
{color:#008000}-76.57418668270113{color} {color:#000080}38.91891450597657{color}
{color:#008000}-76.57484114170074{color} {color:#000080}38.91758725401061{color}
{color:#008000}-76.57661139965057{color} {color:#000080}38.91881851059802{color}
{color:#008000}-76.57418668270113{color} {color:#000080}38.91891450597657
{color}
After SDO_GEOMETRY conversion (results in invalid geometry)
{color:#008000}-76.57418668270112505069846520200371742249{color} {color:#000080}38.91891450597657353682734537869691848755{color}
{color:#008000}-76.57484114170074462890625{color} {color:#000080}38.91758725401061269622005056589841842651{color}
{color:#008000}-76.57661139965057373046875{color} {color:#000080}38.91881851059802244208185584284365177155{color}
{color:#008000}-76.57418668270112505069846520200371742249{color} {color:#000080}38.91891450597657353682734537869691848755
{color}
After correction via SDO_UTIL.RECTIFY_GEOMETRY
{color:#008000}-76.5741866827011{color} {color:#000080}38.9189145059766{color}
{color:#008000}-76.5766113996506{color} {color:#000080}38.918818510598{color}
{color:#008000}-76.5748411417007{color} {color:#000080}38.9175872540106{color}
{color:#008000}-76.5741866827011{color} {color:#000080}38.9189145059766
{color}
{color:#000000}So if we institute a test and autocorrection of badly converted geometries:
{color}<ul><li>geometries which convert properly get nutty precision added (out to 38 places in many case)</li>
<li>geometries which fail conversion and then are rectified actually lose precision</li>
</ul>
The issue here is explaining and documenting this so that clients are confident that we know what we are doing. If I pass someone two geometries with 14 digits of precision and they send me back one with 38 digits and a second with 12 digits I might wonder what the heck they are doing to my data. Is there any place where these issues are documented in depth by Oracle?
Thanks again for your time,
Paul

SDO_UTIL.TO_CLOB odd head scratcher

Hi folks,
I'll try to submit this to support but thought I should log it here in case anyone is interested.
Using Oracle 11.2.0.3.
I am still occasionally poking at the uber SDO_GEOMETRY issue (see Re: upgrading to uber SDO_GEOMETRY, looking for comments Anyhow one of the deal breakers has been the hassles to move geometries back and forth between uber-installed instances and regular instances. With datapump off the table, its kind of a bummer. Anyhow, I noticed that for reasons I cannot explain (any takers?) the following works to move SDO_GEOMETRY across a database link between uber and regular instances:
INSERT INTO local_table (shape)
SELECT
SDO_UTIL.FROM_CLOB(SDO_UTIL.TO_CLOB(a.shape))
FROM
remote_table@remote_instance a;I don't really understand why that works. But it does. Obviously over-sized geometries will fail if you try to move them to a regular instance. Performance is not too bad overall considering the deserialization and serialization taking place. I have not looked into what is occurring on what instance.
The only problem I found is a weird bug I think with the SDO_UTIL.FROM_CLOB for geometries with crazy precision.
SELECT
SDO_UTIL.TO_CLOB(SDO_GEOMETRY(2001,8265,NULL,SDO_ELEM_INFO_ARRAY(1,1,1),SDO_ORDINATE_ARRAY(-106.496121500000000992258719634264707565,43.01151182000000261496097664348781108856)))
FROM DUAL;When I plug the results into FROM_CLOB, I get
ORA-06502: PL/SQL: numeric or value error
ORA-06512: at "MDSYS.SDO_UTIL", line 3152
SELECT
SDO_UTIL.FROM_CLOB('2001||8265||NULL|NULL|NULL||1|1|1||-106.496121500000000992258719634264707565|43.01151182000000261496097664348781108856||')
FROM DUAL;Some kind of odd math bug I think. If I knock off 12 digits, then it works fine.
Cheers,
Paul

Paul,
As you know full well no one can measure the earth to the precision of the numbers of your 8265 SRIDed SDO_GEOMETRY.
Interestingly, the longitude in the example can't be represented in an Oracle NUMBER without loss of "precision" as can be seen following:
SELECT length('496121500000000992258719634264707565') as longPrecLength
FROM DUAL;
-- Results
LONGPRECLENGTH
36
-- The max precision for this longitude is 35.....
SELECT cast(-106.496121500000000992258719634264707565 as number(38,35)) as longitude
FROM DUAL;
-- Result
LONGITUDE
-106.49612150000000099225871963426470757
-- Trying to define 36 decimal digits throws an error
SELECT cast(-106.496121500000000992258719634264707565 as number(38,36)) as longitude
FROM DUAL;
-- Result
QL Error: ORA-01438: value larger than specified precision allowed for this column
01438. 00000 - "value larger than specified precision allowed for this column"
*Cause: When inserting or updating records, a numeric value was entered
that exceeded the precision defined for the column.
-- Try binary_double
SELECT cast(-106.496121500000000992258719634264707565 as binary_double) as longitude
FROM DUAL;
-- Results
LONGITUDE
-106.4961215I have no idea what 1/10^36 decimal degrees of longitude or latitude is in meters but it ain't measurable via any GPS/Surveying method I know! Perhaps CERN can help!
Thanks for the reference to my new article. It has been sitting on my computer hard disk now for well over 6 months. I often wonder how many people actually read my articles (just like I wonder if anyone uses GeoRaptor)!
To be honest, when I first started using Oracle SDO_GEOMETRY I met end users who constantly asked why the number of decimal digits was greater than they expected. So, 10+ years ago I wrote a coordinate rounding function. (Perception management?) I never thought about the saving of space (most say it doesn't matter today due to large, cheap, fast disks, and fast networks) nor about performance aspects. I think my article points the way forward for others to investigate and, I hope, share* their results and experiences.
regards
Simon

SDO_UTIL.FROM_KMLGEOMETRY and Java

Hello,
I'm trying to write a Java program that will parse a KML file, convert KML geometry coordinates into SDO_GEOMETRY coordinates, then insert appropriate records into the database.
I'm stuck on the 2nd part, converting KML into SDO_GEOMETRY. Here's my code:
private static void getSDOGeom(Connection con, String [] geomKML, JGeometry [] geomSDO) throws Exception {
CallableStatement s = con.prepareCall("{? = call SDO_UTIL.FROM_KMLGEOMETRY(?)}");
ResultSet rs = null;
for (int i = 0; i < geomKML.length; i++) {
s.registerOutParameter(1, JGeometry.GTYPE_POINT);
s.setString(2, "\'<Point><coordinates>" + geomKML[i] + "</coordinates></Point>\'");
rs = s.executeQuery();
geomSDO[i] = (JGeometry) s.getObject(1);
Here's my error message:
java.sql.SQLException: ORA-06550: line 1, column 13:
PLS-00382: expression is of wrong type
ORA-06550: line 1, column 7:
PL/SQL: Statement ignored
-then stack trace saying which line of my program caused the error - the executeQuery line.
It looks like my problem is from the JGeometry.GTYPE_POINT in the registerOutParameter method call. I've tried a number of items here to no effect. The geomKML array contains KML coordinates stripped from a KML/XML file, I had to put the <Point> and <coordinates> tags in because the XML parser isn't including them. I've converted coordinates directly in the database, so I know the KML input is correct. The geomSDO array is of the proper size, but is null. I'm not sure what I'm doing wrong and can't find anything like this in the forums. A DB guy here at work did some searching and said I should use JGeometry, but he's not sure why it isn't working either.
Anyone have any ideas?

Thanks for the help... my problem was the ResultSet. I didn't noticed until your most recent code example that you weren't using it, but were acting upon the CallableStatement directly for the getObject method. I was using CallableStatement wrong. I think I saw an example somewhere with the CallableStatement and the ResultSet both being used. Thanks for the STRUCT code too, I saw something about that in a forum post, but wasn't sure what it was doing... but my code doesn't work without it. I did have to track down the jar libraries and imports for STRUCT and OracleType, but that wasn't too difficult.
As to your other points, there is a bit of a misunderstanding because of the limited information I posted - I should have been more clear. This method is one method in a larger program - my database connection was already set up and working, though I thank you for being proactive and including it just in case. I was also printing out my KML coordinates to check to make sure they were ok and had already tested them in the database with a written procedure and knew they were working. The "\" was an escape character for a single quote, which I thought I needed to include because the input to FROM_KMLGEOMETRY needed to be surrounded by single quotes in the database testing. Your initial response also included them. I found that by removing them, my error went away - in fact, I didn't even notice they were there at first. Finally, the JGeometry array does indeed work and the array list isn't needed. I was hoping the array would work as it's more light weight and I'm able to pass the object by reference instead of by value, decreasing the overhead of my code. I was delighted to find that it did work once I fixed the ResultSet issue as previously mentioned. It is initialized elsewhere in my code to be the same size as the array with the KML geometry.
I don't add the comments above to rebuff you. I'm very glad to you provided extremely complete answers. You've helped me before. I add them in case someone else stumbles upon this thread in hopes that the information will be useful to them.
For posterity, Final code with related imports:
import java.sql.CallableStatement;
import java.sql.Connection;
import java.sql.DriverManager;
import oracle.spatial.geometry.JGeometry;
import oracle.jdbc.OracleTypes;
import oracle.sql.STRUCT;
private static void getSDOGeom(Connection con, String [] geomKML, JGeometry [] geomSDO) throws Exception {
CallableStatement s = con.prepareCall("{? = call SDO_UTIL.FROM_KMLGEOMETRY(?)}");
STRUCT geomSDO_STRUCT = null;
for (int i = 0; i < geomKML.length; i++) {
s.registerOutParameter(1, OracleTypes.STRUCT, "MDSYS.SDO_GEOMETRY");
// You could also add extrude, tessellate and altitudeMode
s.setString(2, "<Point><extrude>0</extrude><tessellate>0</tessellate>" +
"<altitudeMode>clampToGround</altitudeMode><coordinates>" + geomKML[i] +
"</coordinates><extrude>0</extrude><tessellate>0</tessellate>" +
"<altitudeMode>clampToGround</altitudeMode></Point>");
s.executeQuery();
geomSDO_STRUCT = (STRUCT) s.getObject(1);
geomSDO[i] = JGeometry.load(geomSDO_STRUCT);
s.close();
The libraries that I needed to add to the project at compile time (already had the jdbc driver loaded for runtime) are
sdoapi.jar (this is for JGeometry and other spatial related items) located <oracle home>/md/jlib/
ojdbc6.jar (this is where the STRUCT and OracleTypes are found) located <oracle home>/jdbc/lib/
Thanks,
Edit:
If you're trying to write SDO_GEOMETRY to a database, this thread will help.
ORA-00939: too many arguments for function
Edited by: J-rd-n on Sep 14, 2010 11:44 AM

SDO_UTIL.FROM_WKBGEOMETRY function

Hi there.
I have been struggling to convert WKB(Blobs) to SDO_GEOMETRY.
If I understand correctly there is some SDO functions that doesn't`t work in Oracle XE or should I rather say it has a differant syntax in XE than enterprise.
My problem is that I want to transform WKR(Blobs) to SDO_Geometry.
I tried the following procedure but to no avail.
CREATE OR REPLACE PROCEDURE IMIS_MAP_GEO.BLOB_TO_SDO
IS
CURSOR TCURS IS
SELECT SEQ,
SDO_GEOM.VALIDATE_GEOMETRY(SDO_UTIL.SIMPLIFY((SDO_UTIL.FROM_WKBGEOMETRY(A.GEOMETRY)),0.00000005),0.000001) AS "VALIDATION",
SDO_UTIL.SIMPLIFY((SDO_UTIL.FROM_WKBGEOMETRY(A.GEOMETRY)),0.00000005) AS GEOM
FROM LAND_PARCELS_REGD_ERVEN A
WHERE GEOMETRY IS NOT NULL;
BEGIN
FOR TROW IN TCURS LOOP
IF TROW."VALIDATION" = 'TRUE'
THEN
UPDATE LAND_PARCELS_REGD_ERVEN A
SET A.GEOMETRY_TEST = TROW.GEOM
WHERE A.SEQ = TROW.SEQ;
ELSE
DBMS_OUTPUT.PUT_LINE('GEOMETRY NOT VALID WITH ORA-' ||TROW."VALIDATION"|| ' ON SEQ'||TROW.SEQ);
END IF;
END LOOP;
END;
The values it returns is an blank GEOMETRY.
Any help would be appreciated.
Thanks in advance

Hi Siva.
Thanks for the reply.
Do you know of any workarounds?or is the only way to use Enterprise?
Thanks in advance,

SDO_UTIL.TO_WKTGEOMETRY crashes when processing collection

Hi folks,
Another weird WKT thing. I have what I think is a very reasonable collection comprising one polygon with a bunch of holes and one linestring. SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT says the geometry is valid. However when I attempt to convert the geometry to WKT, I get a generic java runtime error on 11.1.0.6 and a specific error on 10.2.0.4 of
ORA-29532: Java call terminated by uncaught Java exception: java.lang.RuntimeException: oracle.spatial.util.GeometryExceptionWithContext: Unsupported collection element: elemInfo type 2003
ORA-06512: at "MDSYS.SDO_UTIL", line 2495
ORA-06512: at "MDSYS.SDO_UTIL", line 2517
ORA-06512: at line 561
Why would a 2003 polygon not be supported in a collection?
Thanks!
Paul
Here is the procedure with the troublesome geometry:
DECLARE
sdo_example SDO_GEOMETRY;
str_validate VARCHAR2(16);
clb_wkt CLOB;
BEGIN
sdo_example := SDO_GEOMETRY
2004,
8265,
NULL,
SDO_ELEM_INFO_ARRAY
1,
1003,
1,
415,
2003,
1,
433,
2003,
1,
451,
2003,
1,
471,
2003,
1,
485,
2003,
1,
499,
2,
1
SDO_ORDINATE_ARRAY
-118.651784895553,
40.0356302970485,
-118.651814679249,
40.0354702026973,
-118.652439578073,
40.0350811147507,
-118.652528705644,
40.0347836130663,
-118.652707072544,
40.034600496421,
-118.652736912119,
40.034394580999,
-118.652439075159,
40.0340514258819,
-118.652885327685,
40.0333420933535,
-118.653688593409,
40.0326556154812,
-118.654491691494,
40.0317171775986,
-118.654967504199,
40.0308019855276,
-118.655086583104,
40.0308019855276,
-118.656514915289,
40.0300235861168,
-118.656574426802,
40.0297491067266,
-118.65636588505,
40.0294288062655,
-118.656514524134,
40.0290855952691,
-118.657198710953,
40.0283074752551,
-118.65853679798,
40.0261563994965,
-118.659012722444,
40.0254927762802,
-118.661333112647,
40.0238219276958,
-118.663593488424,
40.0215789862781,
-118.664129092038,
40.0215101987925,
-118.664575288685,
40.0213041157324,
-118.66549707452,
40.0202055834987,
-118.666181317218,
40.0197019987542,
-118.667371379835,
40.0192669220987,
-118.668144917742,
40.0188317895637,
-118.668620674568,
40.0183512271134,
-118.668620618688,
40.0181454234501,
-118.668055175498,
40.0180769153613,
-118.668054896102,
40.017596520549,
-118.667727275445,
40.0172533095526,
-118.66769737999,
40.0170245953538,
-118.668143520758,
40.0165439770242,
-118.668291992203,
40.0162236206838,
-118.66930368792,
40.0160858780745,
-118.669392703732,
40.0158800185318,
-118.668112675354,
40.0149196200629,
-118.668052884445,
40.0146449171552,
-118.668469520913,
40.0145990960844,
-118.669064915437,
40.0150336139464,
-118.669421984514,
40.015124920812,
-118.669511223843,
40.0150104798936,
-118.670104774349,
40.0126766227658,
-118.670162777119,
40.0103200227407,
-118.670281408989,
40.0099539012088,
-118.670727382119,
40.0093359873047,
-118.670786614235,
40.009061284397,
-118.670547897631,
40.0079631991981,
-118.670784714337,
40.006201490783,
-118.670516381675,
40.0054465048218,
-118.669949876778,
40.0035249255729,
-118.669830797873,
40.0032275915266,
-118.669681599996,
40.0025640800691,
-118.669473225882,
40.0024956278596,
-118.668938013423,
40.0028619170295,
-118.659718981608,
40.0101405941328,
-118.659719875677,
40.0119251013246,
-118.659185501409,
40.0141674839488,
-118.658234378912,
40.0164327771084,
-118.657877924509,
40.0177370012467,
-118.6580276253,
40.0193843246228,
-118.657968504943,
40.0204825215805,
-118.657849817193,
40.0209172070806,
-118.657492915755,
40.0213978254102,
-118.65677900112,
40.0220157951937,
-118.654458387399,
40.0235950016364,
-118.65377420058,
40.0243274123383,
-118.651543496741,
40.0273708813912,
-118.650472401271,
40.0282404759088,
-118.650145283528,
40.0289040991251,
-118.650324097463,
40.0294988789763,
-118.651723316505,
40.0304595009627,
-118.651574677421,
40.0312144869239,
-118.651098976475,
40.0321756118245,
-118.649462214297,
40.0327479840545,
-118.648896826986,
40.033091195051,
-118.648688508752,
40.0333200768878,
-118.648480190517,
40.0333200768878,
-118.648212193132,
40.0330227987208,
-118.647914579689,
40.0330686197917,
-118.647617022125,
40.033274591093,
-118.646278488063,
40.0358144754015,
-118.6440169947,
40.0384001807809,
-118.643243289155,
40.0389950723909,
-118.642469527731,
40.0393157081281,
-118.642231314042,
40.0392926858339,
-118.642231314042,
40.0393842720962,
-118.640564600529,
40.0399564766882,
-118.640118124485,
40.0401854144044,
-118.639016910043,
40.0412151032731,
-118.638570601637,
40.0417641738123,
-118.63827332347,
40.0432286040605,
-118.637916198514,
40.0437548758229,
-118.637410099199,
40.0441896172024,
-118.636160022155,
40.0447846764504,
-118.634046497323,
40.0456771256241,
-118.632826092216,
40.0465467201417,
-118.632826203975,
40.0466611051808,
-118.632022379458,
40.0472559967907,
-118.630265979582,
40.0479881839752,
-118.630027821772,
40.0481026807729,
-118.629611073545,
40.0481026807729,
-118.628866704661,
40.0479653851985,
-118.62776532258,
40.0481943229146,
-118.627021009576,
40.0484688023048,
-118.625979027249,
40.0484460035281,
-118.624460673423,
40.0485603885672,
-118.621632619283,
40.0494069049113,
-118.620233176724,
40.0496356749894,
-118.619578326566,
40.0496128203333,
-118.618833901803,
40.049429703688,
-118.61627362153,
40.0496584178867,
-118.615350773988,
40.0496584178867,
-118.614755323584,
40.0494066813939,
-118.614338519478,
40.0494753012414,
-118.613891875796,
40.049772691167,
-118.613326320847,
40.0498641097913,
-118.611926990047,
40.0495206752774,
-118.610766096453,
40.0490173140504,
-118.60969438631,
40.0483994001463,
-118.608860778097,
40.0484679082351,
-118.60752090293,
40.0495201723632,
-118.607133714881,
40.050275102445,
-118.606835822041,
40.0512360038282,
-118.60647830593,
40.0517850743673,
-118.606299715513,
40.0519224258211,
-118.605852792434,
40.0529976004846,
-118.605554899594,
40.053295102169,
-118.605376085659,
40.0536839107189,
-118.605346301963,
40.0542788023289,
-118.604482295381,
40.0560176002086,
-118.604303593205,
40.0567040222015,
-118.604303313808,
40.0574818069394,
-118.604660494643,
40.0579166041982,
-118.604660327005,
40.058854595046,
-118.605047179777,
40.0594495984146,
-118.604451282339,
40.0607078897234,
-118.603825880601,
40.0613026136953,
-118.603855496659,
40.0614856744613,
-118.604867974687,
40.0615545178263,
-118.605284890552,
40.0615088085141,
-118.606416503364,
40.0611199999642,
-118.607220495519,
40.0610744024108,
-118.60990041349,
40.0612347761588,
-118.610674510191,
40.0614178928041,
-118.611716604276,
40.0618528018216,
-118.612222815351,
40.0618986228924,
-118.613056591202,
40.0616927074704,
-118.614783710296,
40.0615098143425,
-118.615438672213,
40.0617845172502,
-118.615706613718,
40.0618073160269,
-118.617969727583,
40.0614871832039,
-118.618743880163,
40.0611897932782,
-118.618982093852,
40.0610295871684,
-118.619011877548,
40.0609152021293,
-118.619518088622,
40.0606406109804,
-118.620351976232,
40.0605719911328,
-118.621126072932,
40.060709398466,
-118.621870385937,
40.0605721028915,
-118.62300188699,
40.0598628821219,
-118.623537993519,
40.0596112015084,
-118.624758678022,
40.0590849856253,
-118.625979418404,
40.0586961211961,
-118.62770642574,
40.0584671834799,
-118.629195219387,
40.0580552967565,
-118.629731102399,
40.057803616143,
-118.630862379934,
40.0570256078878,
-118.631606692939,
40.0569340216254,
-118.631844906628,
40.0568424912424,
-118.632083120317,
40.0563848952069,
-118.633392876511,
40.0551263803807,
-118.634524377564,
40.0547374041927,
-118.635238906872,
40.0542339870864,
-118.636399688707,
40.0532500075297,
-118.637024811048,
40.0524262899623,
-118.637649709872,
40.0510764123912,
-118.638215208941,
40.0504584984871,
-118.639554804711,
40.049337223356,
-118.640953688476,
40.0487650746434,
-118.641727673418,
40.0483530761613,
-118.642293116608,
40.0476437995123,
-118.643275475663,
40.0472547115656,
-118.644108916238,
40.0471173042324,
-118.644257778839,
40.0471630135445,
-118.644645022767,
40.0475518779738,
-118.644883124698,
40.0475975872859,
-118.645151010324,
40.0475060010236,
-118.645508191159,
40.0470254944527,
-118.646400975609,
40.0460872242081,
-118.646847004618,
40.0447602012931,
-118.647352992175,
40.0444626996087,
-118.647412391929,
40.0438448974633,
-118.647322984961,
40.043661780818,
-118.647322482047,
40.0423120150056,
-118.647590200035,
40.0416026824772,
-118.647619816093,
40.0412823820162,
-118.647351874588,
40.0412595273601,
-118.64669702443,
40.0413968788139,
-118.646518489892,
40.0412826055336,
-118.646518378133,
40.0410309249201,
-118.647321811495,
40.0401613862819,
-118.647381323007,
40.0399783255159,
-118.64827388394,
40.0389028155763,
-118.650029501505,
40.0371636265411,
-118.650922006558,
40.0361338817929,
-118.651784895553,
40.0356302970485,
-118.627229495448,
40.0502077119433,
-118.627289006961,
40.0499102102589,
-118.628033319965,
40.0496585855248,
-118.628241694079,
40.0494755247588,
-118.628539419281,
40.049338173305,
-118.628747681635,
40.0494526142234,
-118.62877757709,
40.0498414786527,
-118.628271477775,
40.050138980337,
-118.627229495448,
40.0502077119433,
-118.643958209619,
40.040642395767,
-118.643719884171,
40.0403907151535,
-118.643719772412,
40.0399331749973,
-118.643957818463,
40.0396584720897,
-118.644315111057,
40.0395669975861,
-118.644464085417,
40.0397270919372,
-118.644285606758,
40.0405508095047,
-118.644166583732,
40.0406422840083,
-118.643958209619,
40.040642395767,
-118.648868216756,
40.0361571276045,
-118.648897888694,
40.0359512121825,
-118.649433604067,
40.035630688204,
-118.649522787517,
40.0354476833174,
-118.649701210297,
40.0353331865196,
-118.649909696169,
40.0354476833174,
-118.649820512719,
40.0358138048493,
-118.649612306243,
40.0360425749274,
-118.649255125408,
40.0362027810372,
-118.648868216756,
40.0361571276045,
-118.645177888293,
40.0381025114585,
-118.64520761611,
40.0378051215328,
-118.645505117795,
40.037370324274,
-118.645892026446,
40.0372329728202,
-118.645743387363,
40.0380109251961,
-118.645505285433,
40.0381254219939,
-118.645177888293,
40.0381025114585,
-118.61558870828,
40.0512142108799,
-118.615380390046,
40.050848089348,
-118.615648275672,
40.0504592249187,
-118.615886489361,
40.0504363143833,
-118.616005624145,
40.0505965204932,
-118.615975672811,
40.0511913003444,
-118.61558870828,
40.0512142108799,
-83.088467803182,
32.7318730307068,
-83.0882509912858,
32.7317356233736,
-83.08719420093,
32.7316896346647,
-83.0851351584685,
32.7310939048644,
-83.0836449678378,
32.7305898172058,
-83.0826968069475,
32.7299482663346,
-83.0813963267259,
32.7294212681406,
-83.0801230038707,
32.729008878503,
-83.0795269387943,
32.7289858562089,
-83.0794185328462,
32.7291002971273
str_validate := SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(sdo_example,0.5);
dbms_output.put_line(str_validate);
clb_wkt := SDO_UTIL.TO_WKTGEOMETRY(sdo_example);
END;

Hi Siva,
That makes sense that Oracle is using an older version of the WKT specification. But when I look at the documentation on these WKT functions, there is no mention of the specification used. For example, the GML converter specifies GML 2.0 right in the documentation. Do you know the version of WKT is currently supported by Oracle? Where is this documented? I should also note that it doesn't seem to mention anywhere that Oracle WKT functions are restricted to two-dimensional geometries only. Is this mainly a case of really poor documentation?
Anyhow, on page 21 of the current WKT specification 1.2, it states that GEOMETRYCOLLECTIONs:
A GeometryCollection is a geometric object that is a collection of some number of geometric objects.
All the elements in a GeometryCollection shall be in the same Spatial Reference System. This is also the Spatial
Reference System for the GeometryCollection.
GeometryCollection places no other constraints on its elements. Subclasses of GeometryCollection may restrict
membership based on dimension and may also place other constraints on the degree of spatial overlap between
elements.
Cheers and thanks for your help!
Paul

TTS SDO_UTIL.INITIALIZE_INDEX_FOR_TTS;

Similar Messages

Maybe you are looking for