Sdo_util.Getnumrings Documentation ?

Hi,
Has sdo_util.getnumrings ever been documented anywhere? It's there in my 10g MDSYS schema, and seems to work as the name suggests, but seeing a smidge of documentation would be reassuring.
Maybe there's a secret decoder ring for the documentation (http://download.oracle.com/docs/html/B14255_01/toc.htm) that reveals all kinds of hidden utilities.
Thanks!
Matt

The SQL examples I gave were simplified and not correct in all cases. The reason for this is that the predicate:
where b.column_value in (1003,1005,2003,2005)
...does not discriminate between the ordinate offset, etype and interpretation triplet that is a standard entry for sdo_elem_info_array. So, if an ordinate offset was either 1003, 1005, 2003 or 2005 it would incorrectly add to the count of rings.
The way to correctly query the sdo_elem_info_array is via a SQL pivot as follows:
SELECT count(*) as ringcount
  FROM (SELECT e.id,
               e.etype,
               e.offset,
               e.interpretation
          FROM (SELECT trunc((rownum - 1) / 3,0) as id,
                       sum(case when mod(rownum,3) = 1 then sei.column_value else null end) as offset,
                       sum(case when mod(rownum,3) = 2 then sei.column_value else null end) as etype,
                       sum(case when mod(rownum,3) = 0 then sei.column_value else null end) as interpretation
                  FROM TABLE(SDO_GEOMETRY(2007,  -- two-dimensional multi-part polygon with hole
                                          NULL,
                                          NULL,
                                          SDO_ELEM_INFO_ARRAY(1,1005,2, 1,2,1, 5,2,2,
                                                             11,2005,2, 11,2,1, 15,2,2,
                                                             21,1005,2, 21,2,1, 25,2,2),
                                          SDO_ORDINATE_ARRAY(  6,10, 10,1, 14,10, 10,14,  6,10,
                                                              13,10, 10,2,  7,10, 10,13, 13,10,
                                                            106,110, 110,101, 114,110, 110,114,106,110)).sdo_elem_info
                            ) sei
                 GROUP BY trunc((rownum - 1) / 3,0)
                ) e
       ) i
WHERE i.etype in (1003,1005,2003,2005);To create your own function in case you are worried about use of an undocumented Oracle function using the above is fairly trivial:
create or replace Function GetNumRings( p_geometry in mdsys.sdo_geometry )
  Return Number Deterministic
Is
  v_ring_count number := 0;
Begin
  SELECT count(*) as ringcount
    INTO v_ring_count
    FROM (SELECT e.id,
                 e.etype,
                 e.offset,
                 e.interpretation
            FROM (SELECT trunc((rownum - 1) / 3,0) as id,
                         sum(case when mod(rownum,3) = 1 then sei.column_value else null end) as offset,
                         sum(case when mod(rownum,3) = 2 then sei.column_value else null end) as etype,
                         sum(case when mod(rownum,3) = 0 then sei.column_value else null end) as interpretation
                    FROM TABLE(p_geometry.sdo_elem_info) sei
                   GROUP BY trunc((rownum - 1) / 3,0)
                  ) e
         ) i
   WHERE i.etype in (1003,1005,2003,2005);
  Return v_ring_count;
End GetNumRings;
SHOW ERRORSAnd, testing it:
SELECT GetNumRings(NULL) As RingCount FROM DUAL;
RINGCOUNT
0
1 rows selected
SELECT GetNumRings(SDO_GEOMETRY(2001,NULL,SDO_POINT_TYPE(10,10,10),NULL,NULL)) As RingCount FROM DUAL;
RINGCOUNT
0
1 rows selected
SELECT GetNumRings(SDO_GEOMETRY(2002,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(1,1,10,10))) As RingCount FROM DUAL;
RINGCOUNT
0
1 rows selected
SELECT GetNumRings(SDO_GEOMETRY(2003,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,1003,3),SDO_ORDINATE_ARRAY(1,1,10,10))) As RingCount FROM DUAL;
RINGCOUNT
1
1 rows selected
SELECT GetNumRings(SDO_GEOMETRY(2003,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,1003,3,5,2003,3),SDO_ORDINATE_ARRAY(1,1,100,100,20,20,40,40))) As RingCount FROM DUAL;
RINGCOUNT
2
1 rows selected
SELECT GetNumRings(SDO_GEOMETRY(2007,  -- two-dimensional multi-part polygon with hole
                                NULL,
                                NULL,
                                SDO_ELEM_INFO_ARRAY(1,1005,2, 1,2,1, 5,2,2,
                                                   11,2005,2, 11,2,1, 15,2,2,
                                                   21,1005,2, 21,2,1, 25,2,2),
                                SDO_ORDINATE_ARRAY(  6,10, 10,1, 14,10, 10,14,  6,10,
                                                    13,10, 10,2,  7,10, 10,13, 13,10,
                                                   106,110, 110,101, 114,110, 110,114,106,110)
        as RingCount
  FROM DUAL;
RINGCOUNT
3
1 rows selectedNote that the function did not need exception handling for NULL or non-polygon geometries as the answer returned from the SQL is correct.
Hope this helps.
regards
Simon
Edited by: sgreener on Dec 21, 2008 5:34 PM to add function and call examples.

Similar Messages

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

  • 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_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.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.SIMPLIFY seems to be rather unhappy with my polygon

    Hi folks,
    Not sure if this is a bug or just how things are. I have a polygon that is valid, looking like an upside Q - i.e. a ring-like polygon with a big hole in the middle. On 10.2.0.4, when I run SDO_UTIL.SIMPLIFY with a 20 meter threshold, it returns NULL. A threshold of 80 returns a line whilst a threshold of 10 returns a reasonable result. But NULL? I don't see anything in the documentation about this.
    Next I tried the exact same thing on 11.1.0.7 and rather than NULL, I get ORA-13199 instead. This seems like an improvement. So I assume what produces NULL on 10g throws an error on 11g. I guess we call that progress and move on - any plans to backport this behavior to 10g?
    But back to the results. Looking through
    http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_util.htm#sthref2702
    I don't see any mention that a legal function result can be ORA-13199. So is this a bug? Or are some threshold values "just not gonna" work and always return an error by design?
    Thanks!
    Paul
    SELECT
    SDO_UTIL.SIMPLIFY(
    SDO_GEOMETRY(
    2003,
    8265,
    NULL,
    SDO_ELEM_INFO_ARRAY(
    1,
    1003,
    1,
    63,
    2003,
    1
    SDO_ORDINATE_ARRAY(
    -80.6678363850029,
    27.1544468240932,
    -80.6676581190441,
    27.1544578908543,
    -80.6673811848868,
    27.1545404243406,
    -80.6669873181666,
    27.1546888239902,
    -80.6669011856599,
    27.154727424447,
    -80.6667227848805,
    27.1548484903997,
    -80.6666243193133,
    27.1549804918455,
    -80.6665567184542,
    27.1551016239273,
    -80.6665443185942,
    27.1552556914498,
    -80.6666181177095,
    27.1555144243224,
    -80.6667779183997,
    27.1559106917256,
    -80.6668025185416,
    27.1560536914105,
    -80.6668271189153,
    27.1560868245381,
    -80.6668579182135,
    27.1560866907775,
    -80.6669009855045,
    27.1560592917636,
    -80.6669071190522,
    27.1559382250141,
    -80.6669871190558,
    27.1559106906018,
    -80.6673439852962,
    27.1559052909276,
    -80.6673931847717,
    27.1558888246279,
    -80.6674363186955,
    27.1558722246153,
    -80.6675469848459,
    27.1557622244607,
    -80.6678731857396,
    27.155575091261,
    -80.6679839844916,
    27.1554870246634,
    -80.6680947191472,
    27.1553660239724,
    -80.668279384442,
    27.1550798248074,
    -80.66834698489,
    27.1549642916886,
    -80.6683593847143,
    27.1548432242984,
    -80.6683101849162,
    27.1547276237897,
    -80.6681687190595,
    27.1545734909874,
    -80.6679841179111,
    27.1544468907341,
    -80.6678363850029,
    27.1544468240932,
    -80.6670609857901,
    27.1558170906695,
    -80.6669317858199,
    27.1558172245472,
    -80.6668271853341,
    27.1557840250493,
    -80.6666919857747,
    27.1552446911476,
    -80.6667105183963,
    27.155134623902,
    -80.6668213180802,
    27.1549420246816,
    -80.6670549849476,
    27.154793491146,
    -80.6674795852521,
    27.1546338906477,
    -80.6678303186443,
    27.154556890968,
    -80.6679287847641,
    27.1545568916289,
    -80.6681071851569,
    27.1546450245379,
    -80.6681933180075,
    27.1547606247241,
    -80.6682117191289,
    27.1548872243023,
    -80.6681931847942,
    27.1549532242227,
    -80.6681809185176,
    27.1549918246254,
    -80.6678917187281,
    27.1553990242445,
    -80.6677069852055,
    27.155542091489,
    -80.667479384833,
    27.1556740913815,
    -80.667270184745,
    27.1558170915238,
    -80.6670609857901,
    27.1558170906695
    ),20,0.001) from dual

    Hi folks,
    Not sure if this is a bug or just how things are. I have a polygon that is valid, looking like an upside Q - i.e. a ring-like polygon with a big hole in the middle. On 10.2.0.4, when I run SDO_UTIL.SIMPLIFY with a 20 meter threshold, it returns NULL. A threshold of 80 returns a line whilst a threshold of 10 returns a reasonable result. But NULL? I don't see anything in the documentation about this.
    Next I tried the exact same thing on 11.1.0.7 and rather than NULL, I get ORA-13199 instead. This seems like an improvement. So I assume what produces NULL on 10g throws an error on 11g. I guess we call that progress and move on - any plans to backport this behavior to 10g?
    But back to the results. Looking through
    http://download.oracle.com/docs/cd/B28359_01/appdev.111/b28400/sdo_util.htm#sthref2702
    I don't see any mention that a legal function result can be ORA-13199. So is this a bug? Or are some threshold values "just not gonna" work and always return an error by design?
    Thanks!
    Paul
    SELECT
    SDO_UTIL.SIMPLIFY(
    SDO_GEOMETRY(
    2003,
    8265,
    NULL,
    SDO_ELEM_INFO_ARRAY(
    1,
    1003,
    1,
    63,
    2003,
    1
    SDO_ORDINATE_ARRAY(
    -80.6678363850029,
    27.1544468240932,
    -80.6676581190441,
    27.1544578908543,
    -80.6673811848868,
    27.1545404243406,
    -80.6669873181666,
    27.1546888239902,
    -80.6669011856599,
    27.154727424447,
    -80.6667227848805,
    27.1548484903997,
    -80.6666243193133,
    27.1549804918455,
    -80.6665567184542,
    27.1551016239273,
    -80.6665443185942,
    27.1552556914498,
    -80.6666181177095,
    27.1555144243224,
    -80.6667779183997,
    27.1559106917256,
    -80.6668025185416,
    27.1560536914105,
    -80.6668271189153,
    27.1560868245381,
    -80.6668579182135,
    27.1560866907775,
    -80.6669009855045,
    27.1560592917636,
    -80.6669071190522,
    27.1559382250141,
    -80.6669871190558,
    27.1559106906018,
    -80.6673439852962,
    27.1559052909276,
    -80.6673931847717,
    27.1558888246279,
    -80.6674363186955,
    27.1558722246153,
    -80.6675469848459,
    27.1557622244607,
    -80.6678731857396,
    27.155575091261,
    -80.6679839844916,
    27.1554870246634,
    -80.6680947191472,
    27.1553660239724,
    -80.668279384442,
    27.1550798248074,
    -80.66834698489,
    27.1549642916886,
    -80.6683593847143,
    27.1548432242984,
    -80.6683101849162,
    27.1547276237897,
    -80.6681687190595,
    27.1545734909874,
    -80.6679841179111,
    27.1544468907341,
    -80.6678363850029,
    27.1544468240932,
    -80.6670609857901,
    27.1558170906695,
    -80.6669317858199,
    27.1558172245472,
    -80.6668271853341,
    27.1557840250493,
    -80.6666919857747,
    27.1552446911476,
    -80.6667105183963,
    27.155134623902,
    -80.6668213180802,
    27.1549420246816,
    -80.6670549849476,
    27.154793491146,
    -80.6674795852521,
    27.1546338906477,
    -80.6678303186443,
    27.154556890968,
    -80.6679287847641,
    27.1545568916289,
    -80.6681071851569,
    27.1546450245379,
    -80.6681933180075,
    27.1547606247241,
    -80.6682117191289,
    27.1548872243023,
    -80.6681931847942,
    27.1549532242227,
    -80.6681809185176,
    27.1549918246254,
    -80.6678917187281,
    27.1553990242445,
    -80.6677069852055,
    27.155542091489,
    -80.667479384833,
    27.1556740913815,
    -80.667270184745,
    27.1558170915238,
    -80.6670609857901,
    27.1558170906695
    ),20,0.001) from dual

  • SDO_UTIL.SIMPLIFY - 101 Uses (almost)

    SDO_UTIL.SIMPLIFY
    “Simplifies the input geometry, based on a threshold value, using the Douglas-Peucker algorithm.”
    This is an understated description if there is one. This function can do much more for you than just simplify the geometry, it will also convert arcs to line stings, eliminate duplicate verticies, and correct many overlapping edge polygon problems.
    I “discovered” this additional functionality while trying to get a process down to import reference ESRI shapefile data (GeoBase CIP's) stored in state-plane format into OS (Oracle Spatial) using Lat/Long. Most of the problems I encountered were due to overlapping polygon edges, duplicate verticies, and arcs in line strings. At first, I discreetly defused these issues by finding the errors (with code) and then fixing them based on the returned error codes. This was painfully slow and a real pain to code.
    Then I took a look at the incoming data, and determined that many times, the drafters (possibly from a CAD to GIS conversion) really went overboard and included many times more points than necessary for the accuracy I was interested in for the reference data. I looked at several of the simplify options and since I wanted to simplify the data in-place using an update statement, I choose this one. Then once, I ran the simplify command out of order by accident (before the arc/duplicate/overlap routine). Not only did it simply the data, it also “fixed” all the other problems as well!
    So – note to Oracle staff – great job! You might want to update the documentation to mention all the things it does while simplifying the data, as this is VERY useful for migrating troublesome data. However, I noticed that it can overtake all the memory (and take forever to run) on your database box if you make the mistake of specifying the same values for threshold and tolerance. The docs do state that the tolerance “Must not be greater than threshold.”, but I'd add that they also should not be the same.
    As always, YMMV...
    Bryan

    tdsacilowski wrote:
    All together there are about 20 machines that display a page that has one of the above 5 second refreshes. The application is also public; there is no authentication. From my understanding about how APEX handles sessions there is a max session length (8 hours in my case) even for public sessions. As a page is rendered, a hidden form variable is created called p_instance and the AJAX calls send this to the server to process the request within the active session. In theory, the application shouldn't be generating a lot of new sessions since once a page is loaded it is used simple to display an updating value. In other words, there's no user interaction. No page reloads, no new items being set in session state.
    no interaction, 24/7 uptime, refreshing every 5s, and it is all public.....
    I'd almost look at a slightly different architecture.
    option one:
    have a basic, static web page that calls an APEX REST service.
    This html file and any neccessary css, js files will reside on the same webserver as the APEX listener, but in a different WAR file.
    option two:
    make a simple java swing app using JDBC to connect directly to the database.
    use Oracle Wallet technology so you don't have to hardcode the name/password in plain text.
    have the DBA create an account with very limited access and a profile to guarantee it will never suck-up DB resources.
    *** IIRC -- the OCI version includes the capability of triggering an event (in Java) when a table gets update. ****
    APEX is a very good tool.
    But, for your case, it sounds like it is overkill for your requirements.
    MK

  • Java Exception with SDO_UTIL.FROM_WKTGEOMETRY

    Anyone have any idea why the following is not working?
    INSERT INTO "OBJECT_EVENT" ("title", GEOMETRY) VALUES ( 'testPoly', SDO_UTIL.FROM_WKTGEOMETRY('POLYGON((-76.57418668270113 38.91891450597657 0, -76.57484114170074 38.91758725401061 0, -76.57661139965057 38.91881851059802 0, -76.57418668270113 38.91891450597657 0))'));This is producing the following error:
    ERROR at line 1:
    ORA-29532: Java call terminated by uncaught Java exception:
    java.lang.RuntimeException: -2
    ORA-06512: at "MDSYS.SDO_UTIL", line 137I'm a n00b with Oracle Spatial and there's so much documentation I can't find anything that references this issue. Which usually means I have something all wrong.
    Thoughts? Help?
    Thanks so much!

    Nick,
    So does that mean the JTS download at spatialdbadvisor.com is the latest codebase you've contributed? i.e. Do I have your latest work? If not I'll redownload once you update. If so, I'll play around with the .sh script and see if I can't get it working. The current download is still called JTS. At some point the name will change, probably to something like JSC4O (Java Spatial Companion 4 Oracle)... I may drop the "Companion" but I don't want people thinking I am trying to replace SDO_GEOMETRY
    like ESRI does or Jaspa aspires to. All I want to do is make the SDO_GEOMETRY experience for users a little easier in those areas where gaps appear between releases that users need plugged but the Oracle release/license cycle isn't flexible enough.
    I often update the JTS library as I find bugs or add new functionality. For example, I release a version a few days ago which contained:
       * ST_LineMerger
       * Takes set of linestring geometries and constructs a collection of linear components
       * that form maximal-length linestrings. The linear components are returned as a MultiLineString.
       * @param p_resultSet  : RefCur_T : Ref Cursor of Linestring Geometries 
       * @param p_precision  : int   : Number of decimal places of precision when comparing ordinates.
       * @return STRUCT      : Collection of linear sdo_geometries as MultiLineString.
       * @throws SQLException
       * @history Simon Greener, January 2012, Original Coding
       * @copyright  : Licensed under a Creative Commons Attribution-Share Alike 2.5 Australia License.
       *               http://creativecommons.org/licenses/by-sa/2.5/au/
      Function ST_LineMerger(p_resultSet in &&defaultSchema..JTS.refcur_t,
                             p_precision in number)
        Return mdsys.sdo_geometry
               Deterministic;Also, I am improving/tuning my XSV exporter right now so those changes will go up.
    As each goes up I modify this page: http://www.spatialdbadvisor.com/source_code/223/geoprocessing-package-documentation
    I believe the latest version has some modifications to the install.sh script after your comments. Perhaps you might want to look at that version before starting?
    regards
    Simon

  • Sdo_util.from_gml311geometry returns Message:Invalid Polygon

    The following query executed on 11.2.0.3 returns an exception:
    SELECT sdo_util.from_gml311geometry('<gml:Surface srsName="urn:ogc:def:crs:EPSG::28992" xmlns:gml="http://www.opengis.net/gml"><gml:patches><gml:PolygonPatch><gml:exterior><gml:LinearRing><gml:posList srsDimension="2" count="7">83665.185 437483.078 83655.784 437479.597 83667.002 437448.834 83669.197 437449.752 83673.781 437451.666 83676.38 437452.753 83665.185 437483.078</gml:posList></gml:LinearRing></gml:exterior></gml:PolygonPatch></gml:patches></gml:Surface>') FROM dual;
    ORA-29532: Java call terminated by uncaught Java exception: java.lang.RuntimeException: Message:Invalid Polygon
    Description:
    ORA-06512: at "MDSYS.SDO_UTIL", line 227
    Is surface not supported?
    How do I insert <code> tags as I used to?

    Hi Rene,
    It sure would be easier if that error message said something like "Surface not supported".  I think that Oracle Spatial only supports "Simple Geometric Primitives" (section 9.2) in the 3.1.1 specification whereas Surface is an "additional" geometric primitive in section 10.2.  The Oracle documentation does not mention such details so I think you'd need to submit an SR to get a definitive answer.   I've never tested each and every primitive to see if each one works or not, but I'd guess its just the simple ones that work.
    Your GML snippet works just fine in PostGIS
    SELECT ST_AsText(ST_GeomFromGML('<gml:Surface srsName="urn:ogc:def:crs:EPSG::28992" xmlns:gml="http://www.opengis.net/gml"><gml:patches><gml:PolygonPatch><gml:exterior><gml:LinearRing><gml:posList srsDimension="2" count="7">83665.185 437483.078 83655.784 437479.597 83667.002 437448.834 83669.197 437449.752 83673.781 437451.666 83676.38 437452.753 83665.185 437483.078</gml:posList></gml:LinearRing></gml:exterior></gml:PolygonPatch></gml:patches></gml:Surface>'));
    which is running JTS under the covers.  So one option is to use JTS in Oracle as Simon Greener does
    http://www.spatialdbadvisor.com/oracle_spatial_tips_tricks
    If that is not a fit, coding your own GML reader using PLSQL and XMLTYPE is not that hard to do and gives you the ability to work around any oddities in the incoming GML.
    Cheers,
    Paul

  • Issue with creation of custom layouts using SAP Help Documentation

    Hi Experts,
    My requirement is to create a home custom page layout (using web dynpro) in Composite Environment. The default options available in CE are not useful for me. I set out to make a custom layout using the following this SAP Help Documentation: [          Creating a Web Dynpro Page Layout (SAP Library - Using the Portal as a Frontend)|https://cw.sdn.sap.com/cw/docs/DOC-102846]
    I have followed the instructions and followed all the steps, yet I fail to see the application in CE. The custom page layout is not displayed neither in options and is not available any where.
    Please let me know if anybody followed these steps and have got any success.
    Thanks in advance
    Srikant

    Hi
    Can somebody let me know if they have implemented a customised solution of creation of page layouts using Web Dynpro - as per the steps suggested by SAP.
    Thanks in advance
    Srikant

  • Web Services API Documentation?

    Hello,
    I was looking for documentation regarding OLM web services, since I'd need to perform a few simples queries from an external software. Could you please point me in the right direction?
    Thanks....

    Hi,
    Please see "Oracle Learning Management Implementation Guide" manual, Page 11-54 -- Publicly Callable Business Process APIs in OLM. Also see "Oracle Integration Repository User Guide".
    Oracle Learning Management Implementation Guide & Oracle Integration Repository User Guide
    http://www.oracle.com/technetwork/documentation/applications-089559.html
    Oracle Integration Repository
    http://irep.oracle.com/index.html
    Thanks,
    Hussein

  • Where is Creative Cloud written documentation?

    I can find videos but they are a poor substitute for professionally prepared documentation. Where is Adobe's documentation of Creative Cloud services?

    Hi Ted,
    Help content for the individual products can be accessed from here http://helpx.adobe.com/support.html?promoid=KAWQK#
    Go the More Products section for an overall product list. Many of the products have a PDF version of the help which can be downloaded from the product specific help page.
    -Dave

  • Mobile iPhone Application for SAP B1 Documentation

    SAP releases the following statement on their landing page for their customers about using iPhone App in version 8.8.  Direct copy and paste:
    I am already using SAP Business One. Are there any requirements to be able to use this app?
    You need to be running SAP Business One version 8.8 with a professional user license. Before you start using the app, make sure your SAP partner configures the mobility settings in SAP Business One.
    Where is the documentation that is the checklist for installing and getting the mobile app up and running?  You know, the usual documentation from step A to Z - go to Add-ons and do this, go to User and do this, etc.   All I can find are videos/documents that are marketing oriented.  I have the user guide "Setting Up Mobile Scenario in 8.8", but it is woefully lacking in several steps (ie, it says some fields are mandatory, but SAP does not even mention what "code" column is supposed to mean).
    Anyone else have any luck digging out the pertinent information from SAP sites which SAP should have prominently highlighted to its partners before rolling this out?  Where can I find it?
    This all seems to be a rather disconnected roll-out.
    Thanks in Advance - Zal

    Here is part of the answer - Go here:  https://websmp203.sap-ag.de/sbo-swcenter
    Until it is changed, select "Updates" (not the other areas stated in some documentation, videos, and threads) and select "SAP Business 8.8", then "B1 8.8 Integration Component", and then it can be downloaded.
    I will add more info as the process goes along, if there is anything more...
    TIA - Zal

Maybe you are looking for

  • JDev 9i or 10g for a new project??

    Hi, I plan to use Linux, BC4J, Struts and JSP (or ADF) in a new project which should be productive in June 2004. I'm really uncertain which version to use. I think 904 is a stable release, but lacks the easy web development of ADF. But is 10g is not

  • HT1338 trying to update my iphone software

    trying to update my iphone it says in my software update

  • HT4628 Connected but can't get online.

    On my iMac, I keep getting the msg "This webpage is not available" even though I'm definitely connected through my wifi. My ipad is working fine. Any ideas? This happened overnight. Thanks people. I really want to avoid having to spend $$ on this if

  • How to get music from someone else's itunes library onto your

    How to get music from someone else's itunes library onto your

  • Constant crash on G5 with decklink

    my system: G5 dual 2,7, OSX 10.4.6, 4.5 GIG RAM APERTURE 1.1.1 i have the complete final cut studio installed. video card is a decklink HD. apperture would be a great piece of software, if it would not crash all the time. and i really mean: ever some