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

Similar Messages

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

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

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

  • Affine transformation with vector data

    I want to use the SDO_UTIL.AFFINETRANSFORMS method to transform vector data in a sql statement.
    The example in the Spatial Developer's Guide is working so far. But if I change the SCALING parameter to TRUE I got a exception:
    Fehler beim Start in Zeile 2 in Befehl:
    SELECT SDO_UTIL.AFFINETRANSFORMS(
    geometry => MDSYS.SDO_GEOMETRY(2003, NULL, NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),
    MDSYS.SDO_ORDINATE_ARRAY(
    1.5,0,
    2.5,1,
    1.5,2,
    0.5,2,
    0.5,0,
    1.5,0)),
    translation => 'FALSE',
    tx => 0.0,
    ty => 0.0,
    tz => 0.0,
    scaling => 'TRUE',
    psc1 => NULL,
    sx => 0.5,
    sy => 0.5,
    sz => null,
    rotation => 'FALSE',
    p1 => NULL,
    line1 => NULL,
    angle => 0.0,
    dir => 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 => MDSYS.SDO_GEOMETRY(2002,0,NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),
    MDSYS.SDO_ORDINATE_ARRAY(2.5,0.0,2.5,2.0)),
    dirR => 0,
    planeR => 'FALSE',
    n => NULL,
    bigD => NULL
    ) FROM DUAL
    Fehlerbericht:
    SQL-Fehler: ORA-29532: Java call terminated by uncaught Java exception: java.lang.NullPointerException
    ORA-06512: at "MDSYS.SDO_UTIL", line 265
    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 methods TRANSLATION and REFLECTION are working - SCALING, ROTATION and SHEARING are not working.
    I test it on Oracle 11.1.0.7 on Windows XP and Windows Server 2003 R2.
    Maybe it's a similar problem which is described in Bug 9146920 on My Oracle Support.
    Has anybody had a similar problem?
    Regards,
    Cord

    Hi,-
    Please define psc1 instead of psc1 => NULL like:
    psc1 =>MDSYS.SDO_GEOMETRY(2001, NULL, NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1,1,1),
    MDSYS.SDO_ORDINATE_ARRAY(0,0)),if you want scaling with respect to origin.
    Define psc1 like:
    psc1 =>MDSYS.SDO_GEOMETRY(2001, NULL, NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1,1,1),
    MDSYS.SDO_ORDINATE_ARRAY(0.6,0)),if you want scaling with respect to another point (i.e., point *(0.6, 0)* which is) on your geometry.
    Please note that psc1 has to be on the geometry, and it can be any point
    other than the vertices of your geometry.
    Next, note also that you should _specify sz as zero even if you donot use it for 2D_ as you will see in the below examples.
    Hope that this helps and please let us know if you have further problems.
    I tried with (0,0) point for psc1 as follows:
    SELECT SDO_UTIL.AFFINETRANSFORMS(
    geometry => MDSYS.SDO_GEOMETRY(2003, NULL, NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),
    MDSYS.SDO_ORDINATE_ARRAY(
    1.5,0,
    2.5,1,
    1.5,2,
    0.5,2,
    0.5,0,
    1.5,0)),
    translation => 'FALSE',
    tx => 0.0,
    ty => 0.0,
    tz => 0.0,
    scaling => 'TRUE',
    psc1 =>MDSYS.SDO_GEOMETRY(2001, NULL, NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1,1,1),
    MDSYS.SDO_ORDINATE_ARRAY(0,0)),
    sx => 0.5,
    sy => 0.5,
    sz => 0.0,
    rotation => 'FALSE',
    p1 => NULL,
    line1 => NULL,
    angle => 0.0,
    dir => 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 => MDSYS.SDO_GEOMETRY(2002,0,NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),
    MDSYS.SDO_ORDINATE_ARRAY(2.5,0.0,2.5,2.0)),
    dirR => 0,
    planeR => 'FALSE',
    n => NULL,
    bigD => NULL
    ) FROM DUAL;
    SDO_UTIL.AFFINETRANSFORMS(GEOMETRY=>MDSYS.SDO_GEOMETRY(2003,NULL,NULL,MDSYS.SDO_
    SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1),
    SDO_ORDINATE_ARRAY(.75, 0, 1.25, .5, .75, 1, .25, 1, .25, 0, .75, 0))
    With (0.6,0) point for psc1, you will get:
    SELECT SDO_UTIL.AFFINETRANSFORMS(
    geometry => MDSYS.SDO_GEOMETRY(2003, NULL, NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),
    MDSYS.SDO_ORDINATE_ARRAY(
    1.5,0,
    2.5,1,
    1.5,2,
    0.5,2,
    0.5,0,
    1.5,0)),
    translation => 'FALSE',
    tx => 0.0,
    ty => 0.0,
    tz => 0.0,
    scaling => 'TRUE',
    psc1 =>MDSYS.SDO_GEOMETRY(2001, NULL, NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1,1,1),
    MDSYS.SDO_ORDINATE_ARRAY(0.6,0)),
    sx => 0.5,
    sy => 0.5,
    sz => 0.0,
    rotation => 'FALSE',
    p1 => NULL,
    line1 => NULL,
    angle => 0.0,
    dir => 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 => MDSYS.SDO_GEOMETRY(2002,0,NULL,
    MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),
    MDSYS.SDO_ORDINATE_ARRAY(2.5,0.0,2.5,2.0)),
    dirR => 0,
    planeR => 'FALSE',
    n => NULL,
    bigD => NULL
    ) FROM DUAL;
    SDO_UTIL.AFFINETRANSFORMS(GEOMETRY=>MDSYS.SDO_GEOMETRY(2003,NULL,NULL,MDSYS.SDO_
    SDO_GEOMETRY(2003, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1),
    SDO_ORDINATE_ARRAY(1.05, 0, 1.55, .5, 1.05, 1, .55, 1, .55, 0, 1.05, 0))Best regards
    baris

  • Rubber Sheeting

    Hi Every Body ,
    Can any body help me how to implement the Rubber Sheeting in Oracle Spatial 11G.

    Hi,-
    You are most welcome.
    If you have SDO_GEOMETRY which you could in your case with line geometries, you can use our Affine Transform function to do rubber sheeting. The only thing is that you need to know what kind of transform you need to use.
    Please let us know if you need further help with affine transforms i.e., SDO_UTIL.AFFINETRANSFORMS
    Best regards
    baris
    SDO_UTIL.AFFINETRANSFORMS(
         geometry IN SDO_GEOMETRY,
         translation IN VARCHAR2,
         tx IN NUMBER,
         ty IN NUMBER,
         tz IN NUMBER,
         scaling IN VARCHAR2,
         psc1 IN SDO_GEOMETRY
         sx IN NUMBER,
         sy IN NUMBER,
         sz IN NUMBER,
         rotation IN VARCHAR2,
         p1 IN SDO_GEOMETRY,
         line1 IN SDO_GEOMETRY,
         angle IN NUMBER,
         dir IN NUMBER,
         shearing IN VARCHAR2
         shxy IN NUMBER,
         shyx IN NUMBER,
         shxz IN NUMBER,
         shzx IN NUMBER,
         shyz IN NUMBER,
         shzy IN NUMBER,
         reflection IN VARCHAR2
         pref IN SDO_GEOMETRY,
         lineR IN SDO_GEOMETRY,
         dirR IN NUMBER,
         planeR IN VARCHAR2,
         n IN SDO_NUMBER_ARRAY,
         bigD IN SDO_NUMBER_ARRAY,
         ) RETURN SDO_GEOMETRY;
    Description
    Returns a geometry that reflects an affine transformation of the input geometry.
    Parameters
    geometry
        Input geometry on which to perform the affine transformation.
    translation
        A string value of TRUE causes translation to be performed; a string value of FALSE causes translation not to be performed. If this parameter is TRUE, translation is performed about the point at (tx,ty) or (tx,ty,tz).
    tx
        X-axis value for translation.
    ty
        Y-axis value for translation.
    tz
        Z-axis value for translation.
    scaling
        A string value of TRUE causes scaling to be performed; a string value of FALSE causes scaling not to be performed.
    psc1
        Point on the input geometry about which to perform the scaling. If scaling is TRUE, this geometry should be either a zero point (point geometry with 0,0 or 0,0,0 ordinates for scaling about the origin) or a nonzero point (point geometry with ordinates for scaling about a point other than the origin). If scaling is FALSE, psc1 can be a null value.
    sx
        X-axis value for scaling (about either the point specified in the psc1 parameter or the origin).
    sy
        Y-axis value for scaling (about either the point specified in the psc1 parameter or the origin).
    sz
        Z-axis value for scaling (about either the point specified in the psc1 parameter or the origin).
    rotation
        A string value of TRUE causes rotation to be performed; a string value of FALSE causes rotation not to be performed.
        For two-dimensional geometries, rotation uses the p1 and angle values. For three-dimensional geometries, rotation uses either the angle and dir values or the line1 and angle values.
    p1
        Point for two-dimensional geometry rotation about a specified point.
    line1
        Line for rotation about a specified axis.
    angle
        Angle rotation parameter for rotation about a specified axis or about the X, Y, or Z axis.
    dir
        Rotation parameter for x(0), y(1), or z(2)-axis roll. If the rotation parameter value is TRUE but the dir parameter is not used, specify a value of -1.
    shearing
        A string value of TRUE causes shearing to be performed; a string value of FALSE causes shearing not to be performed.
        For two-dimensional geometries, shearing uses the shxy and shyx parameter values. For three-dimensional geometries, shearing uses the shxy, shyx, shxz, shzx, shyz, and shzy parameter values.
    shxy
        Value for shearing due to X along the Y direction.
    shyx
        Value for shearing due to Y along the X direction.
    shxz
        Value for shearing due to X along the Z direction (three-dimensional geometries only).
    shzx
        Value for shearing due to Z along the X direction (three-dimensional geometries only).
    shyz
        Value for shearing due to Y along the Z direction (three-dimensional geometries only).
    shzy
        Value for shearing due to Z along the Y direction (three-dimensional geometries only).
    reflection
        A string value of TRUE causes reflection to be performed; a string value of FALSE causes reflection not to be performed.
        For two-dimensional geometries, reflection uses the lineR value for reflection about an axis and the pref value for the centroid for self-reflection. For three-dimensional geometries, reflection uses the lineR value for reflection about an axis; the dirR value for reflection about the yz, xz, and xy planes; the planeR, n, and bigD values for reflection about a specified plane; and the pref value for the centroid for self-reflection.
    pref
        Point through which to perform reflection.
    lineR
        Line along which to perform reflection.
    dirR
        Number indicating the plane about (through) which to perform reflection: 0 for the yz plane, 1 for the xz plane, or 2 for the xy plane. If the reflection parameter value is TRUE but the dirR parameter is not used, specify a value of -1.
    planeR
        A string value of TRUE causes reflection about an arbitrary plane to be performed; a string value of FALSE causes reflection about an arbitrary plane not to be performed.
    n
        Normal vector of the plane.
    bigD
        Delta value for the plane equation in three-dimensional geometries.
        For three-dimensional geometries, bigD = delta and n = (A,B,C) where n is the normal of the plane in three-dimensional space. Thus, the plane equation is:
        Ax+By+Cz+bigD = 3DDotProd(n,anypointonplane)+bigD = 0

  • AffineTransform - Is there a way to glean units of measurement for pixels?

    Assuming I get a pointer to a java.awt.geom.AffineTransform from:
    java.awt.geom.AffineTransform CurTransform = ((java.awt.Graphics2D)this.getMainFrame().getGraphics()).getDeviceConfiguration().getDefaultTransform();
    Assuming I've gotten the right AffineTransform... How do I get, or can I get, the scaling factor between horizontal pixels and vertical pixels for the current screen (or whatever device). In other words I want to place components... buttons, textboxes, etc. in a dialog box so that they are "square". i.e. 10 units in x look on the screen equal to 10 units in y.
    Once I know what the "square pixel scale factor" is I can then worry about making the units relative to whatever font size.
    This question is usually posed as "How do I get dialog units?". I haven't done that because of the "legacy problems" associated with what most people think dialog units come from. It is true that way back when dialog units were derived from a textmetrics ONLY, but unless I'm mistaken, Charles Petzold, was describing something that could only be gotten that way at that time (circa 1990).... The width of the fixed system font by the height of the fixed system font ended up being as close to a unit that was 8 units high looked like 8 units wide in the screen. The object of the exercise is to most importantly get units of measurement that translate to pixels and look "square" on the screen. Secondarily, but not unimportant, is to be a unit that has some relevance to the current font size. It's been a long time dialog units in windows maybe a 2:1 ratio. I made my own cDialogUnits so long ago I can't remember what the "standard windows" dialog unit is. In windows I can very easily get the screen dpi x and y, I think it's a devicecontext but Java's "devicecontext" only gives one dimension of the dpi?
    Also this query is mute if I was "painting" on a device. The units are for pixels NOT points and are (mostly) for placing controls on the screen. I am aware of and have used the various addPreferredGap and setAutoCreateContainerGaps available in a GroupLayout... Great gizmos but, still dialog units would be very handy for setting the prefered width of a textbox/label with too much text. (Note: dialog units are NOT for calculating the height of text... )
    I did search the sun forums for an answer first... It might be here I just didn't find it. It seems to be a question either avoided like the plague or considered a dumb question in Java.

    This might be OK?
    BE AWARE!! This is NOT a painting gizmo. It is used in conjunction with the Layout gizmos. It drives me crazy that the Layout gizmos have "default" gaps and spacers of some kind and yet ALL the tutorials immediately and unabashedly trash any "device independence" by mixing in pixel measurements... Not to mention I don't like the size of the gaps and spacing provided with the Layout gizmos anyway.
    Does anyone know if this will fail? I am aware of the caveats provided... "Information about the device is only as good as has been provided." However if there is bad information in the device info I doubt using these units will do anything much different that the end user experiences with the errant device anyway.
    AGAIN... This is NOT a painting gizmo. It's a helper when Laying out controls usually in conjunction with a Layout and only for spaces and gaps.
    public class DialogUnits
        private double m_x;
        private double m_y;
        public DialogUnits( java.awt.Graphics2D g2 )
            java.awt.GraphicsConfiguration gc = g2.getDeviceConfiguration();
            java.awt.geom.AffineTransform at = gc.getDefaultTransform();
            at.concatenate( gc.getNormalizingTransform() );
            double fs = g2.getFont().getSize2D();
            m_x = at.getScaleX() * fs;
            m_y = at.getScaleY() * fs;
        public int CalcX( double units )
            return (int)Math.round( ( units * m_x ) / 8.0 );
        public int CalcY( double units )
            return (int)Math.round( ( units * m_y ) / 8.0 );
        public int ContainerGapX()
            return this.CalcX( 8.0 );
        public int ContainerGapY()
            return this.CalcY( 8.0 );
        public int FontSize2dX( int crude_columns )
            return (int)Math.round( crude_columns * m_x );
        public int FontSize2dY( int crude_rows )
            return (int)Math.round( crude_line_height * m_y );
        public int X( int units )
            return this.CalcX( units );
        public int Y( int units )
            return this.CalcY( units );
        } // end of class DialogUnits

  • 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

  • How to set and read pixels?  AffineTransform?

    I understand how the AffineTransform class works but I don't see a way to set the color of and read the color of individual pixels in my JPanel. Any help will be apppreciated.

    you can't do that with AffineTransform. AffineTransform let's you translate/rotate/shear/scale before rendering, but you don't have access to pixel values.
    Try instead creating an empty bufferedimage, draw into it whatever you want and then you have access to the pixel values via bufferedImage.getRGB()/setRGB().
    or you get more basic and manipulate the WriteableRaster of your image directly.

  • 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

Maybe you are looking for

  • IPod worked fine, sync'd fine, apps functioned BEFORE iTunes 8.2.1.6 update

    I got a new iPod Touch in March...16gb 2G. I have Windows XP. Everything's been working fine up until the last two iTunes updates. The new 8 has yielded the worst problems. I've noticed PRIOR to iTunes 8 that my downloaded apps stopped working. The f

  • Alternate Vendor

    Hi I need to replace group vendor with an alternate vendor for the paid invoices in the report. Could you please provide me the tables which could provide alternate vendor for the paid invoice? Thanks Davinder

  • Combo box in cascading bad performance

    Hi, I have 3 combobox cascade [province, states, city] And have 3 in ADF BC View Object, using bind variable to filter the SQL from the VO. The largest province has 174 states. The largest state has 73 cities. The selection of the province is 0 sec T

  • Trying to make a PXE install

    Hi, I want to learn how to make a PXE install and  I am using Virtualbox for that. I read the wiki but I can't make it work. I think the mistake is in my dhcp config file. See: #option definitios common to all supported networks... option domain-name

  • Opening an MHT file created 300+ tabs

    I opened an MHT file from XP SP3 Explorer into FireFox 9.0.1 which opened over 370 tabs which i can't delete other than individually. I thought of moving them to a new tab group and deleting that, but can't get into the tab group manager. I also dele