3D sdo_util.reverse_linestring

Hello,
Does anyone know how is it possible to reverse a non-LRS 3D geometry (SDO_GTYPE = 3002)?
The User Guide (for 10g and 11g) says that's only possible for non-LRS 2D geometries (SDO_GTYPE = 2002)...
Thanks in advance.

sdo_util.reverse_linestring doesn't seem to work for 3002. You could always convert into into an LRS geometry, then use SDO_LRF.REVERSE_GEOMETRY_3D and then convert it back again. Or you could roll your own reverse function.
idle> select * from v$version;
BANNER
Oracle Database 10g Express Edition Release 10.2.0.1.0 - Product
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
5 rows selected.
idle> SELECT sdo_util.reverse_linestring(
  2  SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY (1,2,1), SDO_ORDINATE_ARRAY (10,10, 20,20, 30,30))) "This works"
  3  FROM dual;
This works(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
SDO_GEOMETRY(2002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(30, 30, 20, 20, 10, 10))
1 row selected.
idle>
idle> SELECT sdo_util.reverse_linestring(
  2  SDO_GEOMETRY(3002, NULL, NULL, SDO_ELEM_INFO_ARRAY (1,2,1), SDO_ORDINATE_ARRAY (10,10,5, 20,20,4, 30,30,3)) ) "This does not work"
  3  FROM dual;
This does not work(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
SDO_GEOMETRY(3002, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(10, 10, 5, 20, 20, 4, 30, 30, 3))
1 row selected.

Similar Messages

  • Implementation in SQLJ doesn't work Call of a Function

    My problem is that a PL/SQL stored procedure works fine but the implemented supposed to be same Java SQLJ procedure doesn't behave in the same way??
    Help would be greatly appreciated. thanks
    The code line where the application throws an exception is:
    In PL/SQL:
    lo_geometry := lsl_topo_rwo.get_geom(li_manifold_id, pi_topo_id);
    In JAVA:
    #sql lo_geometry = { VALUES (LSL_TOPO_RWO.get_geom(:li_manifold_id, :li_topo_id)) };
    Error Message: Invalid Column Type:
    java.sql.SQLException: Ungültiger Spaltentyp
         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:124)
         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:161)
         at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:226)
         at oracle.jdbc.driver.OracleStatement.get_internal_type(OracleStatement.java:3162)
         at oracle.jdbc.driver.OracleCallableStatement.registerOutParameterInternal(OracleCallableStatement.java:120)
         at oracle.jdbc.driver.OracleCallableStatement.registerOutParameter(OracleCallableStatement.java:261)
         at oracle.jdbc.driver.OracleCallableStatement.registerOutParameter(OracleCallableStatement.java:341)
         at GN_10.GN_10_Oracle.reverse_geometry(GN_10_Oracle.sqlj:1698)
    PL/SQL Code:
    PROCEDURE reverse_geometry( pc_table      VARCHAR2,
                   pi_topo_id      NUMBER ) IS
         lo_geometry           MDSYS.SDO_GEOMETRY;
         lo_rev_geometry          MDSYS.SDO_GEOMETRY;
         li_manifold_id               NUMBER;
         BEGIN
                   lsl_topo_manifold.get_manifold_id_from_name(pc_table, li_manifold_id);
         IF li_manifold_id IS NOT NULL THEN
         lo_geometry := lsl_topo_rwo.get_geom(li_manifold_id, pi_topo_id);
         IF lo_geometry IS NOT NULL THEN
         lo_rev_geometry := SDO_UTIL.REVERSE_LINESTRING(lo_geometry);
         lsl_topo_rwo.set_geom(li_manifold_id, pi_topo_id, lo_rev_geometry);
                   END IF;
              END IF;
         END;
    JAVA Code:
    if (li_manifold_id != 0)
    Object lo_geometry = null;
    Object lo_rev_geometry = null;
    int li_topo_id = get_topo_id( pc_table, lc_topo_id_col, pi_id );
    if ( li_topo_id != -1 && li_topo_id != 0 )
    try
    #sql lo_geometry = { VALUES (LSL_TOPO_RWO.get_geom(:li_manifold_id, :li_topo_id)) };
    if ( lo_geometry != null )
    #sql lo_rev_geometry = { VALUES (SDO_UTIL.REVERSE_LINESTRING(:IN lo_geometry)) };
    #sql { CALL LSL_TOPO_RWO.set_geom( :li_manifold_id, :li_topo_id, :lo_geometry ) };
    else
    } // end if ( lo_geometry != null )
    } catch (SQLException ex)
    // Eine SQLException ist aufgetreten
    ex.printStackTrace();
    }

    Thank you for your help, it did put me on the right track.
    you probably meant by to create a type in the database:
    CREATE OR REPLACE TYPE geom AS OBJECT
    geoloc MDSYS.SDO_GEOMETRY
    and then to work with this ?
    Well, I couldn't figure out how to use this back in the Java code to recuperate the object, but this helped me anyway to change my function call:
    from
    #sql lo_geometry = { VALUES (LSL_TOPO_RWO.get_geom(:li_manifold_id, :li_topo_id)) };
    to
    #sql { select (LSL_TOPO_RWO.get_geom(:li_manifold_id, :li_topo_id)) into: lo_geometry from dual };
    and to check on the contents by creating a JGeometry Object:
    STRUCT lo_test = ( STRUCT ) lo_geometry;
    JGeometry lo_geo = JGeometry.load(lo_test);
    I don't know if this is proper or recommended but for the moment I need this to work and it does the job for me?!
    Thanks again,
    kind regards
    Marco

  • 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

  • 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.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

  • 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

  • SDO_UTIL.AFFINETRANSFORMS

    I have the following parameters for 2D affine transformation:
    Two translation:
    tx=2754.3661 and ty = -237.0731
    and rotation in radians: -.001016214498072193185827329
    Is this specification correct:
    SDO_UTIL.TO_WKTGEOMETRY(SDO_UTIL.AffineTransforms (
    geometry =>myGeometry,
    translation => 'TRUE', tx => 2754.3661, ty => -237.0731, tz => 0.0,
    scaling => 'FALSE', psc1 => NULL, sx => 0.0, sy => 0.0, sz => 0.0,
    rotation => 'TRUE',
    p1 => MDSYS.SDO_GEOMETRY(2001, NULL, MDSYS.SDO_POINT_TYPE(0, 0, NULL), NULL, NULL), line1 => NULL,
    angle => -.001016214498072193185827329,
    dir => -1,
    shearing => 'FALSE', shxy => 0.0, shyx => 0.0, shxz => 0.0, shzx => 0.0, shyz => 0.0, shzy => 0.0,
    reflection => 'FALSE', pref => NULL, lineR => NULL, dirR => -1, planeR => 'FALSE', n => NULL, bigD => NULL
    Thanks.
    BTW, in PostGIS it works correctly:
    ST_Affine (myGeometry, cos(rotation), sin(rotation), -sin(rotation), cos(rotation), tx, ty));
    Edited by: qwe14450 on 13-Jul-2012 15:03

    Qwe (for Qwe must be your name),
    It is tricky to get this function to work as the error message thrown when you get the parameters wrong is useless.
    ORA-29532: Java call terminated by uncaught Java exception: java.lang.Exception: Invalid parameter for affine transform
    ORA-06512: at "MDSYS.SDO_UTIL", line 266
    29532. 00000 -  "Java call terminated by uncaught Java exception: %s"
    *Cause:    A Java exception or error was signaled and could not be
               resolved by the Java code.
    *Action:   Modify Java code, if this behavior is not intended.The thing I kept yelling at the screen was "what parameter is invalid"!!!!!
    But I got this to work:
    select mdsys.sdo_geometry(2002,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(2.0,2.0,2.0,4.0,8.0,4.0,12.0,4.0,12.0,10.0,8.0,10.0,5.0,14.0)) as geomm from dual;
    select SDO_UTIL.AffineTransforms (
            geometry => mdsys.sdo_geometry(2002,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(2.0,2.0,2.0,4.0,8.0,4.0,12.0,4.0,12.0,10.0,8.0,10.0,5.0,14.0)),
            translation => 'TRUE',
              tx => 2754.3661,
              ty => -237.0731,
              tz => 0.0,
            rotation => 'TRUE',
              p1 => MDSYS.SDO_GEOMETRY(2001, NULL, MDSYS.SDO_POINT_TYPE(0, 0, NULL), NULL, NULL),
              angle => -0.001016214498072193185827329, /*cogo.radians(45),*/
              dir => -1,
              line1 => NULL,
            scaling    => 'FALSE', psc1 => NULL, sx => 0.0, sy => 0.0, sz => 0.0,
            shearing   => 'FALSE', shxy => 0.0, shyx => 0.0, shxz => 0.0, shzx => 0.0, shyz => 0.0, shzy => 0.0,
            reflection => 'FALSE', pref => NULL, lineR => NULL, dirR => -1,
            planeR     => 'FALSE', n => null, bigD => null
      from dual;
    -- Result
    SDO_GEOMETRY(2002,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(2756.36813139595,-235.075133461338, 2756.3701638246,-233.07513449403, 2762.37016072653,-233.081231779969, 2766.37015866114,-233.085296637262, 2766.37625594708,-227.085299735337, 2762.37625801246,-227.081234878044, 2759.38032441879,-223.078188300459))Note the reference to /*cogo.radians(45),*/.... I have a function Radians in a package called Cogo that I use to convert from degrees (360) to radians:
    Create   Function radians(p_degrees in number)
        Return number
      Is
         c_PI  NUMBER(16,14) := 3.14159265358979;
      Begin
        Return p_degrees * (c_PI / 180.0);
      End radians;
    /If this helps, please award points.
    regards
    Simon

  • SDO_UTIL.APPEND strips away LRS dimensions

    Hi folks,
    Checking over the forum it seems I did note this issue in passing a year ago
    https://community.oracle.com/message/11033886#11033886
    But it came out to bite me today.  It does seem true that I flog poor old SDO_UTIL.APPEND every-so-often and perhaps I should find other interests.
    I am thinking this is probably a "feature" and a small blurb should be added to the documentation for the function.  SDO_UTIL.APPEND simply says of itself, "Appends one geometry to another geometry to create a new geometry."
    There is no mention of what types of geometries you should or should not feed to it.
    However feeding LRS geometries to SDO_UTIL.APPEND is a bad idea (see below) as the function destroys the LRS dimension from the SDO_GTYPE producing a 3D geometry.  I guess that I should be using SDO_LRS.CONCATENATE_GEOM_SEGMENTS though I am not interested in this case in merging the geometries, I just want to house them together in a multi-geometry.  I think this is what SDO_UTIL.APPEND was meant for.
    Assuming this is just a feature, perhaps Oracle could add a note on the SDO_UTIL.APPEND page that the function is not valid for LRS geometries?  Or is this a bug? 
    Cheers,
    Paul
    ON 11GR2:
    SELECT
    SDO_UTIL.APPEND(
        SDO_GEOMETRY(3302,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(1,1,1, 2,2,2))
       ,SDO_GEOMETRY(3302,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(3,3,3, 4,4,4))
    FROM dual;
    RESULT:
    SDO_GEOMETRY(3006,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1,7,2,1),SDO_ORDINATE_ARRAY(1,1,1,2,2,2,3,3,3,4,4,4))

    Paul,
    My take on append, is that it will just stuff the first and the second geometries together with no logic applied. So although your example result geometry just happens to work out, there is no logic given to the measure portion of the LRS. The measure can be a distance, say meters for Lat/Lon - or it can be some arbitrary scale such as the percentage of a city block going from 0 to 1. Since append would have no knowledge of how your two line stings are to be stuck together, you could easily wind up with:
    SELECT
    SDO_UTIL.APPEND(  
        SDO_GEOMETRY(3302,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(3,3,3, 4,4,4)),
        SDO_GEOMETRY(3302,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(1,1,1, 2,2,2))
    FROM dual;
    RESULT:
    SDO_GEOMETRY(3006,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1,7,2,1),SDO_ORDINATE_ARRAY(3,3,3,4,4,4,1,1,1,2,2,2))
    ...that of course is completely invalid as the measure is not progressing in order:
    SELECT
    SDO_LRS.VALIDATE_LRS_GEOMETRY(
       SDO_GEOMETRY(3306,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1,7,2,1),SDO_ORDINATE_ARRAY(3,3,3,4,4,4,1,1,1,2,2,2))
    FROM
    dual;
    RESULT ON 11.2.0.4.2: 13335
    ORA-13335 LRS segment is not defined
    Cause: The given start or end measures are not defined, or some assigned measures in between are not in an ascending order.
    Action: An LRS geometric segment is defined if its start and end measure are assigned (non-null). Any other measures assigned on the segment must be in an ascending order.
    Bryan
    PS - Yes, I agree on the error message - or more so, on checking for valid inputs to start with. However, I do get the idea that doing so on something that is called millions or billions of times in a row, can cause it to run slightly slower. All in all, I'd personally rather have validity checks that a routine that runs 2% faster and can give me invalid answers.

  • SDO_UTIL.FROM_WKTGEOMETRY seems ignorant of ring rotation

    Hello,
    Back with more WKT issues. The OGC WKT spec does not enforce any kind of ring rotation on its polygons. However Oracle SDO_GEOMETRY does. When SDO_UTIL.FROM_WKTGEOMETRY converts a WKT polygon it doesn't seem to correct the ring rotation - it just leaves the rings rotated exactly as in the WKT resulting in invalid SDO_GEOMETRY polygons. Wouldn't this be a bug? I can't find anywhere in the SDO_UTIL documentation where we are told to always runs RECTIFY_GEOMETRY after the conversion.
    Simple Example:
    {color:#008000}SELECT SDO_UTIL.VALIDATE_WKTGEOMETRY('
    POLYGON((
    -76.57418668270113 38.91891450597657,
    -76.57484114170074 38.91758725401061,
    -76.57661139965057 38.91881851059802,
    -76.57418668270113 38.91891450597657
    ))') FROM dual
    {color}
    returns TRUE though ring is clockwise - okay for WKT.
    But when we convert it to SDO_GEOMETRY, the ring is still clockwise and throws an error
    {color:#008000}SELECT SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(
    SDO_GEOMETRY('
    POLYGON((
    -76.57418668270113 38.91891450597657,
    -76.57484114170074 38.91758725401061,
    -76.57661139965057 38.91881851059802,
    -76.57418668270113 38.91891450597657
    ))',8265),0.0001) FROM dual
    {color}
    returns {color:#ff0000}13367 [Element &lt;1&gt;] [Ring &lt;1&gt;]
    {color}{color:#000000}
    So is this a bug or a feature? Does all WKT polygons coming into Oracle need to have their rings prerotated and if so, why would VALIDATE_WKTGEOMETRY not warn us of the problem.
    Cheers,
    Paul
    {color}

    Paul,
    In case you are not aware:
    SELECT SDO_MIGRATE.TO_CURRENT(
    MDSYS.SDO_GEOMETRY('POLYGON((-76.57418668270113 38.91891450597657,-76.57484114170074 38.91758725401061,-76.57661139965057 38.91881851059802,-76.57418668270113 38.91891450597657))',8265)
    ,SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -99999.00000, 99999.00000, 0.0001),SDO_DIM_ELEMENT('Y', -99999.00000, 99999.00000, 0.0001)))
    FROM dual
    ---produces:
    MDSYS.SDO_GEOMETRY(2003, 8265, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1), MDSYS.SDO_ORDINATE_ARRAY(-76.5741866827011,38.9189145059766,-76.5766113996506,38.918818510598,-76.5748411417007,38.9175872540106,-76.5741866827011,38.9189145059766))
    ---thus:
    SELECT SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(
    MDSYS.SDO_GEOMETRY(2003, 8265, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1), MDSYS.SDO_ORDINATE_ARRAY(-76.5741866827011,38.9189145059766,-76.5766113996506,38.918818510598,-76.5748411417007,38.9175872540106,-76.5741866827011,38.9189145059766))
    ,0.0001) FROM dual
    ---produces: TRUE
    r,
    dennis

  • SDO_UTIL Missing Functions?

    Folks,
    I am accessing a 10.2.0.1 SE database at a client site and when I describe the SDO_UTIL package I don't get all the functions in 10.2.0.1 that I use when developing my PL/SQL packages (for download at my website).
    SQL*Plus: Release 10.2.0.1.0 - Production on Fri Feb 9 09:06:27 2007
    Copyright (c) 1982, 2005, Oracle. All rights reserved.
    Connected to:
    Oracle Database 10g Release 10.2.0.1.0 - 64bit Production
    SQL> desc sdo_util
    FUNCTION APPEND RETURNS SDO_GEOMETRY
    Argument Name Type In/Out Default?
    GEOMETRY1 SDO_GEOMETRY IN
    GEOMETRY2 SDO_GEOMETRY IN
    FUNCTION EXTRACT RETURNS SDO_GEOMETRY
    Argument Name Type In/Out Default?
    GEOMETRY SDO_GEOMETRY IN
    ELEMENT NUMBER IN
    RING NUMBER IN DEFAULT
    FUNCTION GETVERTICES RETURNS VERTEX_SET_TYPE
    Argument Name Type In/Out Default?
    GEOMETRY SDO_GEOMETRY IN
    FUNCTION REMOVE_DUPLICATES RETURNS SDO_GEOMETRY
    Argument Name Type In/Out Default?
    GEOMETRY SDO_GEOMETRY IN
    DIM SDO_DIM_ARRAY IN
    FUNCTION REMOVE_DUPLICATE_VERTICES RETURNS SDO_GEOMETRY
    Argument Name Type In/Out Default?
    GEOMETRY SDO_GEOMETRY IN
    TOLERANCE NUMBER IN
    FUNCTION TRUNCATE_NUMBER RETURNS NUMBER
    Argument Name Type In/Out Default?
    VALUE NUMBER IN
    NO_OF_DIGITS NUMBER IN
    In particular, I am looking for CONCAT_LINES() and RECTIFY_GEOMETRY.
    Any pointers?
    regards
    Simon Greener

    Dan,
    This explains it. I am running 10.2.0.1 on my laptop and have all the functions etc.
    I have seen this error:
    ORA-04063: type body "MDSYS.SDO_INDEX_METHOD_9I" has errors
    at many sites but never quite got to the bottom as to why it occurred was occuring on 10g databases! I always assumed the _9I thing was a short term carry over.
    Now I know!
    Mate, I am really well. Thankfully, reasonably busy, though things were a bit quiet when I got back from Europe (last October). It was great to meet you though it would have been nice to have had a chance to catch up over a drink/dinner but you had to fly back to the USA. I have started down the OCP track which, on top of everything else, is keeping me out of mischief!
    I hope all is going well with you. We should drop each other an email off line...
    regards
    S

Maybe you are looking for

  • 10.6.8 update - currupted my finder - mac pro

    Hi update from 10.67 to 10.6.8 has caused finder to not launch the window that shows device places recent docs etc also context menu is currupted with names like N31,N68, BN50, LB1 and N220 etc etc etc , clicking on about mac returns nothing and I ca

  • Can't connect Macbook Air 10.8.5 to new Officejet 6700

    I don't have a CD drive, so I'm trying to set-up via instructions from the internet. Thus, far, I've uninstalled the previous HP printer, downloaded the suggested download multiple times--with no luck. There is no connection between my computer and t

  • Search for users in a particular LDAP through Web Dynpro code...

    Hi Experts, Let me try explaining my problem. In my project we are using two ADAM LDAPs. One for storing internal users and the other for storing external users. I have configured the portal to connect to both the LDAPs. I am able to search for the u

  • New Nano Owner Lost

    OK so my girlfriend bought me the new 2nd gen Nano for Christmas. Totally digging it until today! I was deleting music off of iTunes and after I finished I plugged the Nano in to update it. The only catch is My Computer and iTines do NOT recognize th

  • Locking content in InDesign

    HI, Is it possible to 'lock' or deny access to edit text (or other) elements in InDesign so that I could send an InDesign doc to a third party, and only allow them access to only the elements I'm happy for them to change. For example. Want them to be