Geometry to WKT

hii. i try to run these codes but i got an error shown below. i use oracle 10g.R2
why do i get this error.
select m.geometry.get_wkt() from mahal m
ORA-13199: ENGINEERING is not supported by geometry WKB/WKT generation.
ORA-06512: at "MDSYS.MD", line 1723
ORA-06512: at "MDSYS.MDERR", line 17
ORA-06512: at "MDSYS.SDO_UTIL", line 2439
ORA-06512: at "MDSYS.SDO_GEOMETRY", line 36
thanks

i run this code
SELECT c.ID, SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(c.geometry, 0.005)
FROM mahal c
and get this.
ID,SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(C.GEOMETRY,0.005)
380,13367 [Element <1>] [Ring <1>]
381,13367 [Element <1>] [Ring <1>]
382,13367 [Element <1>] [Ring <1>]
383,13349 [Element <1>] [Ring <1>][Edge <7>][Edge <8>]
384,TRUE
385,13367 [Element <1>] [Ring <1>]
386,13349 [Element <1>] [Ring <1>][Edge <1>][Edge <30>]
387,13349 [Element <1>] [Ring <1>][Edge <1>][Edge <4>]
388,13367 [Element <1>] [Ring <1>]
389,13367 [Element <1>] [Ring <1>]
390,13367 [Element <1>] [Ring <1>]
379,13367 [Element <1>] [Ring <1>]
378,13356 [Element <1>] [Coordinate <8>][Ring <1>]
852,13367 [Element <1>] [Ring <1>]
853,TRUE
854,13367 [Element <1>] [Ring <1>]
855,TRUE
856,13367 [Element <1>] [Ring <1>]
857,TRUE
858,13367 [Element <1>] [Ring <1>]
859,13367 [Element <1>] [Ring <1>]
860,13367 [Element <1>] [Ring <1>]
861,13356 [Element <1>] [Coordinate <5>][Ring <1>]
862,13367 [Element <1>] [Ring <1>]
863,13367 [Element <1>] [Ring <1>]
864,13367 [Element <1>] [Ring <1>]
865,TRUE
825,13367 [Element <1>] [Ring <1>]
823,13367 [Element <1>] [Ring <1>]
824,13349 [Element <1>] [Ring <1>][Edge <1>][Edge <20>]
826,13367 [Element <1>] [Ring <1>]
827,13356 [Element <1>] [Coordinate <4>][Ring <1>]
828,13367 [Element <1>] [Ring <1>]
829,13367 [Element <1>] [Ring <1>]
830,13367 [Element <1>] [Ring <1>]
831,13367 [Element <1>] [Ring <1>]
832,13367 [Element <1>] [Ring <1>]
833,13367 [Element <1>] [Ring <1>]
834,13367 [Element <1>] [Ring <1>]
835,13367 [Element <1>] [Ring <1>]
836,TRUE
837,13367 [Element <1>] [Ring <1>]
838,13367 [Element <1>] [Ring <1>]
839,13367 [Element <1>] [Ring <1>]
840,13367 [Element <1>] [Ring <1>]
841,13367 [Element <1>] [Ring <1>]
842,13367 [Element <1>] [Ring <1>]
843,13367 [Element <1>] [Ring <1>]
844,13367 [Element <1>] [Ring <1>]
845,TRUE
846,TRUE
847,13367 [Element <1>] [Ring <1>]
848,13367 [Element <1>] [Ring <1>]
849,13367 [Element <1>] [Ring <1>]
850,13367 [Element <1>] [Ring <1>]
851,13367 [Element <1>] [Ring <1>]
is there something wrong here?

Similar Messages

ORA-13199: 0D geometries are not supported by geometry WKB/WKT generation.

I want to get WKB data of some SDO_GEOMETRY field. I've tryed to use get_wkb function but when I execute statement like that
select c.geom.get_wkb() from ob c
I get error:
ORA-13199: 0D geometries are not supported by geometry WKB/WKT generation.
What does this error "means" and what should I do?
Thanks for answers.
Matej

Hello,
I get the same message on an Oracle 10.2.0.1.0 system.
ORA-19199: 0D geometries are not supported by geometry WKB/WKT generation.
ORA-06512: in "MDSYS.MD", Zeile 1723
I use following select:
select b.geom.GET_WKT() from bio2006 b where b.bio2006_ = 86
When I use another table this command works fine:
select a8.geom.GET_WKT() from multinet.mn_a8 a8 where a8.name = 'Aidhausen'
Both tables are filled by sqlldr (ctl & dat - files).
The both files look on the first view equal...
The meta data for bio2006 are equal to a8, here's the generated insert statement
INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID)
VALUES ('BIO2006', 'GEOM',
MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('X', -180.000000000, 180.000000000, 0.500000000),
MDSYS.SDO_DIM_ELEMENT('Y', -90.000000000, 90.000000000, 0.500000000)
8307);
Does anybody know the reason for the error message?
Thanks,
Matthias

Sql to convert mdsys.geometry to wkt or wkb

I've been looking through the sdoapi for 10g (the only available now) for a way to convert a geometry column to wkt or wkb. There was a method with the old version (get_wkt and get_wkb). Does anyone know how to do it with the 10g sdoapi
Mike Smith

Our Java code actually does have a (protected) member variable or switch, representing whether the output by default should be big-endian or little-endian.
However, the SQL/mm standard does not define any parameter to determine the output encoding. Neither have we added any proprietary signature to that effect. Thus, the Java constructor sets the switch to "big-endian".
On the other hand, when the Java code reads WKB, the WKB specifies whether it is encoded in little-endian or in big-endian. This is why we can read both encodings.
If there is a requirement to also write both encodings, we could add a function specifying the output encoding.
Mike

Export Geometry to WKT or WKB but include ARCs too - Do not densify

Dear all,
I have been having some issues when exporting the spatial data to WKT or WKB. I can get the WKT without any problems but the issue is that all ARCs are not exported as ARCs but rather as line segments. Looks like during the export process there is some Densify process that gets run.
Can someone please help me if there is a way to export the ARCs as ARCs and do not densify.
WKT has support for Circular Arcs so there should be no problems.
And the second problem was that when i export to WKB this data can not be read by SQL Server or any other tool.
Any advice much apprciated.
Dan

Dan,
Without actual examples we cannot help you solve you problem.
Here are some tests I ran in Oracle and SQL Server.
Oracle Export
select a.name, a.geom.get_wkt() as text
from (select 'Line segment' as name,sdo_geometry (2002, null, null, sdo_elem_info_array (1,2,1), sdo_ordinate_array (10,10, 20,10)) as geom from dual union all
        select 'Line string' as name,sdo_geometry (2002, null, null, sdo_elem_info_array (1,2,1), sdo_ordinate_array (10,25, 20,30, 25,25, 30,30)) as geom from dual union all
        select 'Arc segment' as name,sdo_geometry (2002, null, null, sdo_elem_info_array (1,2,2), sdo_ordinate_array (10,15, 15,20, 20,15)) as geom from dual union all
        select 'Arc string' as name,sdo_geometry (2002, null, null, sdo_elem_info_array (1,2,2), sdo_ordinate_array (10,35, 15,40, 20,35, 25,30, 30,35)) as geom from dual union all
        select 'Closed arc string' as name,sdo_geometry (2002, null, null, sdo_elem_info_array (1,2,2), sdo_ordinate_array (15,65, 10,68, 15,70, 20,68, 15,65)) as geom from dual union all
        select 'Compound line string' as name,sdo_geometry (2002, null, null, sdo_elem_info_array (1,4,3, 1,2,1, 3,2,2, 7,2,1), sdo_ordinate_array (10,45, 20,45, 23,48, 20,51, 10,51)) as geom from dual union all
        select 'Closed mixed line' as name,sdo_geometry (2002, null, null, sdo_elem_info_array (1,4,2, 1,2,1, 7,2,2), sdo_ordinate_array (10,78, 10,75, 20,75, 20,78, 15,80, 10,78)) as geom from dual
       ) a;
-- results
NAME                 TEXT
Line segment         LINESTRING (10.0 10.0, 20.0 10.0)
Line string          LINESTRING (10.0 25.0, 20.0 30.0, 25.0 25.0, 30.0 30.0)
Arc segment          CIRCULARSTRING (10.0 15.0, 15.0 20.0, 20.0 15.0)
Arc string           CIRCULARSTRING (10.0 35.0, 15.0 40.0, 20.0 35.0, 25.0 30.0, 30.0 35.0)
Closed arc string    CIRCULARSTRING (15.0 65.0, 10.0 68.0, 15.0 70.0, 20.0 68.0, 15.0 65.0)
Compound line string COMPOUNDCURVE ((10.0 45.0, 20.0 45.0), CIRCULARSTRING (20.0 45.0, 23.0 48.0, 20.0 51.0), (20.0 51.0, 10.0 51.0))
Closed mixed line    COMPOUNDCURVE ((10.0 78.0, 10.0 75.0, 20.0 75.0, 20.0 78.0), CIRCULARSTRING (20.0 78.0, 15.0 80.0, 10.0 78.0))
7 rows selectedNo densification there.
SQL Server Denali Import
Now, take the above WKT and import into SQL Server.
select geometry::STGeomFromText('LINESTRING (10.0 10.0, 20.0 10.0)',0).STAsText() as text union all
select geometry::STGeomFromText('LINESTRING (10.0 25.0, 20.0 30.0, 25.0 25.0, 30.0 30.0)',0).STAsText() as text union all
select geometry::STGeomFromText('CIRCULARSTRING (10.0 15.0, 15.0 20.0, 20.0 15.0)',0).STAsText() as text union all
select geometry::STGeomFromText('CIRCULARSTRING (10.0 35.0, 15.0 40.0, 20.0 35.0, 25.0 30.0, 30.0 35.0)',0).STAsText() as text union all
select geometry::STGeomFromText('CIRCULARSTRING (15.0 65.0, 10.0 68.0, 15.0 70.0, 20.0 68.0, 15.0 65.0)',0).STAsText() as text union all
select geometry::STGeomFromText('COMPOUNDCURVE ((10.0 45.0, 20.0 45.0), CIRCULARSTRING (20.0 45.0, 23.0 48.0, 20.0 51.0), (20.0 51.0, 10.0 51.0))',0).STAsText() as text union all
select geometry::STGeomFromText('COMPOUNDCURVE ((10.0 78.0, 10.0 75.0, 20.0 75.0, 20.0 78.0), CIRCULARSTRING (20.0 78.0, 15.0 80.0, 10.0 78.0))',0).STAsText() as text ;
-- results
LINESTRING (10 10, 20 10)
LINESTRING (10 25, 20 30, 25 25, 30 30)
CIRCULARSTRING (10 15, 15 20, 20 15)
CIRCULARSTRING (10 35, 15 40, 20 35, 25 30, 30 35)
CIRCULARSTRING (15 65, 10 68, 15 70, 20 68, 15 65)
COMPOUNDCURVE ((10 45, 20 45), CIRCULARSTRING (20 45, 23 48, 20 51), (20 51, 10 51))
COMPOUNDCURVE ((10 78, 10 75, 20 75, 20 78), CIRCULARSTRING (20 78, 15 80, 10 78))Can you provide us with similar examples where the process fails?
And the second problem was that when i export to WKB this data can not be read by SQL Server or any other tool.Let's try and solve the first problem before the second. Are Oracle and SQL Server both on the same hardware?
regards
Simon

Wkt tolerance err when intersecting geometry field from table

We have spatially enabled table with min/max latitude/longitdue with 1 degree cell data on which we perform queries comming from an application using well known text. Our WKT data is accurate to 4 decimal places.
In USER_SDO_GEOM_METADATA, SDO_TOLERENCE for lon and lat in DIMINFO column are set to .0000005, and SRID of 8307, and the spatial index for the table has been recreated (just in case).
When we execute the query:
SELECT geometry, SDO_UTIL.TO_WKTGEOMETRY(GEOMETRY) as GEO_WKT, KEY
WHERE SDO_RELATE(geometry,
SDO_UTIL.RECTIFY_GEOMETRY( SDO_GEOMETRY('POLYGON((-96.409 36.499, -93.557 36.499, -93.557 37.843, -93.409 37.843, -96.409 36.499))',8307),0.00005),
'mask=anyinteract') = 'TRUE'
The issue we come up against is that we receive the result where the geometry (at least as WKT outputs it) with the lat going no further north then 36.0 degrees (ex: POLYGON((96 35, 93 35, 93 36, 96 36, 96 35)) ).
However, if we change the lower left and lower right coordinates of my input WKT to 36.5, the intercect goes away, which tells me that there seems to be a .5 degree tolerence that is being used somewhere. What we are not sure about is exactly where it is coming from. Tolerence is set in the USER_SDO_GEOM_METADATA entry for the table and it is set on the input geometry when it's being rectified.
As a check, we have also redid the query by creating the geometry as a rectangle using an ordinate array and it performed exactly as expected. The only time the issue showes up is when the geometry is converted from a WKT string.
Does anyone have any ideas?
Thank You.

873523 ,
[1]
. . . .According to this, you need to use an optimized rectangle to spatial-query geodetic data. Rather than generate a geometry using WKT (as is done in your SQL), define the optimized rectangle as follows:
SELECT
    geometry,
    geometry.Get_WKT() Geo_WKT,
    Key
FROM
    &TableName
WHERE
    SDO_ANYINTERACT(
        geometry,
        SDO_GEOMETRY(
            2003,
            8307,
            NULL,
            SDO_ELEM_INFO_ARRAY(1,1003,3),
            SDO_ORDINATE_ARRAY(
                -- lower left
                -93.557,37.843,
                -- upper right
                -96.409,36.499)
    ) = 'TRUE'[2]
. . . .The geometry you posted is a self-crossing polygon. If you can imagine it, it's the right-triangle formed by the arms of a clock at 6:15. It self-crosses at 6 o'clock.
Regards,
Noel

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_GEOMETRY displaying in Oracle SQL Developer (freezing)

Hi,
I am using Oracle SQL Developer (V 1.5.3) heavily at work, and have noticed some undesirable behaviour when the table's data tab is trying to display SDO_GEOMETRY. In this version (and subsequent ones) Developer tries to convert the geometry to WKT, instead of just displaying "sdo_geometry". I can see why this has been added in, however I am using many geometries that are quite large, and have extremely large sdo_ordinate_array/s . This is causing Developer to appear to be freezing while it runs the conversion, often hanging for many minutes at a time. I have briefly looked at V 2.1, and it appears to be the same.
Does anyone know if there is a check box option, or similar to switch this behaviour off? Limiting the number of rows returned has been suggested, but even when dealing with a STATES table the 9 rows needed for all 9 Australian states is far too large for a data tab display. If an option doesn't currently exist, it might be worth adding in to future versions of SQL developer.
regards, Jeff

Hello,
I´ve the same problem. I use version 3.0.03 (3.45) but I can´t find the possibility to change this option.
Can someone help me?
Thanks
Peter

Sdo_geometry bind variables in trace file

If I run trace on oracle spatial queries, how can I get the detailed information of the sdo_geometry objects (the content of the sdo_geometry objects, e.g. coordinates... ) in the queries?
Thanks!

Hi Rob
Haven't checked the bind variable issue specifically here, but just a by-pass-reflex-of-fixed-implementations, have you tried passing the geometry as WKT?
Obviously, this can also have some constraints on the varchar2 length etc, but depending on the type of geometries (and consequent length of the WKT) it might help you working around it.
Check this section for the appropriate sdo_geometry constructor based on a WKT input.
http://docs.oracle.com/cd/B19306_01/appdev.102/b14255/sdo_objrelschema.htm#CBBFGHAE
Just a thought
Luc

Get_Wkt() error

I have tried to convert the Oracle geometry into Well Known text through Get_WKT() and get_Wkb() method of SDO_GEometry but recieved following errors on this
ORA-13199: ENGINEERING is not supported by geometry WKB/WKT generation.
ORA-06512: at "MDSYS.MD", line 1723
ORA-06512: at "MDSYS.MDERR", line 17
ORA-06512: at "MDSYS.SDO_UTIL", line 2439
ORA-06512: at "MDSYS.SDO_GEOMETRY", line 36
Any help on this???
Paras

Can you post the geometry definition and the context in which your making the get_wkt() call. This helps us try and reproduce, and hopefully fix, your problem.
Oracle edition & version info is also helpful.
Steve

Get_WKB() Error

I get the following error when trying to query well known binary (or well known text) for data that I have loaded from shapefiles.
ORA-13199: 0D geometries are not supported by geometry WKB/WKT generation.
I have inserted a metadata record, per another forum post. That didn't help. when I query USER_SDO_GEOM_METADATA it seems to be correct:
TABLE_NAME,COLUMN_NAME,DIMINFO,SRID
PARNAL,GEO_LOCATION,((X, -180, 180, 0.05), (Y, -90, 90, 0.05), , ),2236
Any help is appreciated.

Hi RS,
Well you did say your data was 3D city modeling data. I mean you can certainly toss out the height dimension but wouldn't that kind of defeat the purpose of having a city model?
If the height is really not important you can remove the Z values on 10g using this tried and true function from Albert Godfrind:
Re: 3-D conversion to 2-D
As regards the larger issue, this has been around a while:
Re: WKT and Three Dimensional Coordinates? Nothing has changed?
Until the OGC folks incorporate the "extended" WKT formats into the Simple Features spec, I don't think Oracle is going to change anything.
On the other hand serializing sdo_geometry is not that difficult so you could just write or have someone write an extended WKB outputter.
Cheers,
Paul

WKT Contains Scientific Notation

I have a table with an SDO geometry column. Our data is stored in Web Mercator to simplify displaying maps on a web page. My team's preferred way of shuffling geometries around is via its WKT since this is human readable and widely used. So we are fetching the WKT directly from the database using the GET_WKT() method (right term?) on the SDO geoemtry.
The problem is that when coordinates exceed 10 million in magnitude, those coordinates are represented in E notation (see http://en.wikipedia.org/wiki/Scientific_notation#E_notation). I need to convert this WKT to a .NET object for use with a particular library, and while it supports conversion from WKT, it blows up on the E notation. I'd call it a bug with the library except for the fact that Oracle itself can't parse WKTs with E notation, either. SDO_UTIL.VALIDATE_WKTGEOMETRY returns FALSE for the WKT that GET_WKT() generated, and SDO_UTIL.FROM_WKTGEOMETRY throws an error. I've also tested that SDO_UTIL.SDO_UTIL.TO_WKTGEOMETRY returns the same WKT.
A large amount of code already depends on the geometry being in WKT format, which means that switching to another format would not be an easy change. For the moment, I'm parsing the WKT using SQL Server's geometry type (see http://msdn.microsoft.com/en-us/library/microsoft.sqlserver.types.sqlgeometry_methods.aspx), and then converting it back to a WKT without E notation using its STAsText() method.
Is there a way to force Oracle to not return E notation coordinates?
This is occurring in both of the following versions of Oracle:
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
"CORE     10.2.0.1.0     Production"
TNS for 32-bit Windows: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
"CORE     11.1.0.6.0     Production"
TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
Sample SQL:
The SRID in the following queries does not seem to exist out of the box in version 10 or Oracle. I ran these queries through Oracle SQL Developer.
Query:
SELECT MDSYS.SDO_GEOMETRY(2003,3785,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(-13426771.266146,5334024.8870015,-13425624.710722,5326534.0582305,-13412553.978887,5325922.5620044,-13412936.164029,5333719.1388884,-13426771.266146,5334024.8870015)).GET_WKT() FROM DUAL;
Result:
POLYGON ((-1.3426771266146E7 5334024.8870015, -1.3425624710722E7 5326534.0582305, -1.3412553978887E7 5325922.5620044, -1.3412936164029E7 5333719.1388884, -1.3426771266146E7 5334024.8870015))
Query:
SELECT SDO_UTIL.VALIDATE_WKTGEOMETRY(MDSYS.SDO_GEOMETRY(2003,3857,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(-13426771.266146,5334024.8870015,-13425624.710722,5326534.0582305,-13412553.978887,5325922.5620044,-13412936.164029,5333719.1388884,-13426771.266146,5334024.8870015)).GET_WKT()) FROM DUAL;
Result:
FALSE
Query:
SELECT SDO_UTIL.FROM_WKTGEOMETRY(MDSYS.SDO_GEOMETRY(2003,3785,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1),MDSYS.SDO_ORDINATE_ARRAY(-13426771.266146,5334024.8870015,-13425624.710722,5326534.0582305,-13412553.978887,5325922.5620044,-13412936.164029,5333719.1388884,-13426771.266146,5334024.8870015)).GET_WKT()) FROM DUAL;
Result:
ORA-29532: Java call terminated by uncaught Java exception: java.lang.RuntimeException
ORA-06512: at "MDSYS.SDO_UTIL", line 172
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.

Hello jpmc26,
I am going to guess that most of us live our lives between the 180s and have not really noticed this before. I would call it a bug that needs an SR opened but is the bug on the coming or the going? If you look in the Simple Features 1.2.1 specification on pages 52 and 53 they clearly say that an "approximate numeric literal" of mantissa + E + exponent is valid. However, Oracle Spatial does not support the 1.2.1 spec. Rather they support something akin to the 1.1.0 specification. On pages 28 and 29 of that version there is no mention of approximate numeric literals as it first shows up in the 1.2.0 specification.
So I would say either:
1) Oracle Spatial supporting only the 1.1.0 specification and not much interested in updating to current specifications, should remove the output of scientific notation from the SDO_UTIL.to_WKTGEOMETRY procedure (match 1.1.0 spec).
-or-
2) Oracle Spatial looking forward to future compatibility with new OGC standards, should add support for parsing scientific notation to the SDO_UTIL.from_WKTGEOMETRY procedure (prepare for 1.2.1 spec).
I guess its a policy decision on their side. Please update the posting as to what they say as I am curious about the topic.
Many folks have largely abandoned these java-based, outdated, OGC converters. Feel free to search the forum for complaints, myself being one of the complainers. When you said "a large amount of code already depends" on WKT, my first thought was that must be really slow. Writing your own SDO to WKT converter in PLSQL is really easy and I believe that's what most of us have done. The other direction is more challenging but doable - I need to rewrite mine but its works well enough for straightforward stuff.
Cheers,
Paul

How do you create a buffer of a geometry in SQL Server 2012?

Hello,
I am new to SQL Server 2012 and spatial data. I built a geometry object of coordinates from a polygon that I stored in a database. The code is below:
DECLARE @digb GEOMETRY;
SET @digb = GEOMETRY::STGeomFromText('POLYGON ((-79.927138 40.362654, -79.91883 40.364224, -79.915966 40.361067, -79.917897 40.359266, -79.927398 40.360142, -79.927138 40.362654))', 4269);
I am using SRID 4269 (Latitude/Longitude NAD83). I have no issues getting this geometry to load properly when the query is executed. (shown below)
My problem is that I am unable to create a valid buffer of 150 feet on this geometry. I have tried using these 3 statements below (I assumed BufferWithCurves() would be the one that would work); however, ALL of them returned to an invalid buffer of
the polygon (shown below):
- DECLARE @digbb GEOMETRY = @digb.STBuffer(2);
- DECLARE @digbb GEOMETRY = @digb.BufferWithCurves(2)
- DECLARE @digbb GEOMETRY = @digb.BufferWithTolerance(@BufferSize,250.0,1);
Does anyone have any idea of how creating this buffer of a geometry object (polygon mentioned above) in SQL Server 2012?
Thanks in advance for any help.
Nick

Hi Nick,
BTW, please do ask questions on the forum, that's what it's for. I only meant "if my explanation in that specific answer was unclear, let me know and I'll clarify". Feel free to start a new thread for each topic because that way, it's
might be easier for folks to search on.
Specific answers:
I haven't worked directly with the MapInfo loader but if you're working with SQL Server, I assume what they may be doing is looking for "geodesic SRIDs" that SQL Server supports (the ones listed in sys.spatial_reference_systems) and loading those
as geography, else geometry. That may be a good thing to do.
If you want to decide yourself, here's some (short) background.
Only SQL Server (I think PostGIS might have added it) has separate geography and geometry types. Everyone else always uses "geometry" and gives you (maybe) the ability to convert between SRIDs in the database. SQL Server doesn't have
this built-in; you'd need to use a library like PROJ4.
You can use geometry type to refer to geodesic SRIDs, but it doesn't have a way to "take the area using spatial instances in decimal degrees and come up with meters". So, if you only use it to display on a map, it will display correctly.
Or close enough. Same with intersects, intersection and the like. But anything like area, distance, or, in your case buffer using a specific number of meters, you need to use geography. You could have gotten somewhat similar-looking
results with geometry by making your input to STBuffer a sufficiently small fraction, but it would be a guess on your part, not a "150 feet" buffer.
You can't CAST/CONVERT between geometry and geography because they didn't want people to assume that these would do SRID conversion. However, there is a codeplex library "SQL Server Spatial Tools" (http://sqlspatialtools.codeplex.com/) that
has two methods: VacuousGeometryToGeography and vice-versa, that does the equivalent (but optimized) of taking one type, spitting it out in well-known text format, then using it to initialize the other type. Or you can do this in your own code.
In general, geography is for anything geodesic; geometry is for planar or projected coordinate systems (e.g state plane coordinate systems in US, that don't use Long/Lat). But geography is slightly slower in calculations (like intersects) because it's more
complex than simple Euclidian geometry. And folks in other platforms are used to using "geometry" and having the platform do the (sometimes fairly expensive) conversions on-the-fly. Or maybe you don't care about the area, distance, etc.
Even in the geography type, WKT specifies (Long Lat) not (Lat Long). This is because the OGC standard doesn't distinguish and calls things (X Y), and if you think about it, (X Y) is (Long Lat) not (Lat Long). The SQL Server geography-specific method MakePoint
has latitude first as a parameter. OGC or SQL/MM standard methods and property names start with "ST" in SQL Server (e.g. STIntersects); SQL Server-specific methods and properties do not (e.g. MakePoint, ReorientObject).
Finally, attempting to do spatial calculations with unlike SRIDs (e.g. intersects between SRID 4269 and 4326 instance) returns NULL.
One more post coming on this thread with some info/links.
Cheers, Bob

Creating a point geometry with coordinate transformation using JDBC

If I execute the following SQL statement using a tool such as TOAD then I get a correct value for the point in the oracle column.
INSERT INTO node (id, position) VALUES (53, SDO_CS.TRANSFORM(SDO_GEOMETRY(2001, 26910, SDO_POINT_TYPE(489535.0, 5457841.0, NULL), NULL, NULL), 4269))
Point geometry:
(2001, 4269, (-123.143865452971, 49.2732377100255, ), , )
If I execute the same statement using JDBC in a Statement or PreparedStatement the Point in the oracle column has 0,0 for the coordinates.
Point: geometry
(2001, 4269, (0, 0, ), , )
In both cases the SQL is exactly the same.
my JDBC code is
String insertSql = "INSERT INTO node (id, position) VALUES (" + id
+ ", SDO_CS.TRANSFORM(SDO_GEOMETRY(2001, " + geometrySrid
+ ", SDO_POINT_TYPE(" + coordinate2d.x + ", " + coordinate2d.y
+ ", NULL), NULL, NULL), " + srid + "))";
Statement insertStatement = connection.createStatement();
try {
insertStatement.execute(insertSql);
} finally {
JdbcUtils.closeStatement(insertStatement);
connection.commit();
Any ideas why this is happening?
I've tried to do the coordinate transformation in a separate call and pass in the STRUCT returned from that, using JGeometry to create a STRUCT for the value, using a WKT geometry and none of these approaches seem to work

Paul,
I have seen this work using JGeometry and STRUCT objects with PreparedStatements. Here's some sample code that seems to work just fine:
ResultSet rs = null;
try {
PreparedStatement ps =
getConn().prepareStatement("select SDO_CS.TRANSFORM(?, ?) from dual");
/* constucts JGeometry objects using simple points (doubles) and SRID
* Per the Javadoc, JGeometry objects can be constructed using the same
* notation and signature as SDO_GEOMETRY objects -
* JGeometry(int gtype, int srid, double x, double y, double z, int[] elemInfo, double[] ordinates) */
JGeometry j_geom1 = new JGeometry(-122.4, 37.8, 8265);
int newSRID = 4269;
//convert JGeometry instances to DB STRUCT
STRUCT obj1 = JGeometry.store(j_geom1, getConn());
ps.setObject(1, obj1);
ps.setInt(2, newSRID);
rs = ps.executeQuery();
while (rs.next()) {
//System.out.println(rs.getString(1));
STRUCT st = (oracle.sql.STRUCT) rs.getObject(1);
JGeometry j_geom = JGeometry.load(st);
System.out.println(j_geom);
ps.close();
rs.close();
conn.close();
} catch (Exception e) {
System.err.print(e);
Hope this helps.
-Justin

Extended WKT notation in Oracle Spatial

Hi,
I have a AutoCAD spatial filter condition as follows,
GEOM ENVELOPEINTERSECTS GeomFromText('POLYGON XYZ ((-60 45 0, 40 15 0, 30 15 0, -60 48 0, -60 33 0))').
When I try to get the geometry in Oracle Spatial as below,
Select SDO_UTIL.from_WKTGEOMETRY('POLYGON XYZ ((-60 45 0, 40 15 0, 30 15 0, -60 48 0, -60 33 0))') from dual;
I am getting an error as "[Error] Execution (2: 8): ORA-29532: Java call terminated by uncaught Java exception: java.sql.SQLException: oracle.spatial.util.GeometryExceptionWithContext: java.lang.RuntimeException: Opening parentheses missing -3
     at oracle.spatial.util.WKT$WKTInputStream.readStartList(WKT.java:223)
     at oracle.spatial.util.WKBasis.readStartList(WKBasis.java:1542)
     at oracle.spatial.util.WKBasis.toJGeometry_WKB_POLYGON(WKBasis.java)
     at oracle.spatial.util.WKBasis.toJGeometry(WKBasis.java:1077)
     at oracle.spatial.util.WKBasis.toJGeometry(WKBasis.java:1033)
     at oracle.spatial.util.WKBasis.toSTRUCT(WKBasis.java:148)
     at oracle.spatial.util.Adapters.wktToSTRUCT2(Adapters.java:208)
     at oracle.spatial.util.Adapters.wktToSTRUCT(Adapters.java:198)
     at oracle.spatial.util.Adapters.wktToSTRUCT(Adapters.java:188)
ORA-06512: at "MDSYS.SDO_UTIL", line 187"
Validating the geometry gives null,
SQL> Select SDO_UTIL.validate_WKTGEOMETRY('POLYGON XYZ ((-60 45 0, 40 15 0, 30 15 0, -60 48 0, -60 3
3 0))') from dual;
SDO_UTIL.VALIDATE_WKTGEOMETRY('POLYGONXYZ((-60450,40150,30150,-60480,-60330))')
null null
What am I doing wrong here? Also what is the equivalent sdo_util funtion for ENVELOPEINTERSECTS?
Thanks.
Ananda

Hi folks,
We talked in the past that a lot of this confusion could be mitigated if the Oracle documentation just stated clearly what version of the OGC specification the WKT functions support. Been a bit of talk on the forum recently on various OGC support issues and it strikes me as being kind of unproductive since nothing has changed in terms of OGC support since... I guess since the GML 3.1.1 functions were released with 11gR1. Is that correct? And before that? So the situation could be termed as being "very stable". :)
Oracle Spatial WKT functionality (as of 11.2.0.3) pretty simply only supports the Simple Features 1.1 specification. End of story. Be nice if it said so here:
http://docs.oracle.com/cd/E11882_01/appdev.112/e11830/sdo_util.htm#SPATL1234
I'll try this weekend to submit an enhancement request for that as I don't think anyone else has.
Meanwhile most of us either use Simon's JTS solution or long ago coded our own readers/writers in PLSQL.
I've been trying to think of ways we could somehow inspire more forum users to submit SRs on the issues they bring up here. I am as lazy as the next person on the matter. Maybe some kind of point rewards for putting in SRs? I am not looking for folks to just knee-jerk submit SRs to every posting, but clearly there are some communities of interest (GML users for example) that could document their collective concerns through metalink.
Cheers,
Paul

Is it a good idea to use oracle database to process the geometry data?

I am working on a map related project. Here are the stops I need to do.
1. load geometry information from a table with spatial filter and other conditions (where clause)
2. get the points from the geometry column (sdo_geometry)
3. transform the coordinates
4. encoding the coordinates
5. output
We have a third party applicaiton that can do both #2 and #3. However the process is slow. Some quick tests show that all the steps from #1 to #4 can be done within oracle and the speed is faster. My concern is if it is a good approach to use oracle, a database server, to do all the data processing that can be done and normally shoudl be done on a web server.
Any adivce please?
(BTW, we use oracle 10g on windows 2008R2 64bit, and we may upgrate to 11g in about a year.)

Hi Simon,
Thanks for your help.
Yes all the steps can be done within the database side (Oracle). However I could do the same (extracting the coordinates from the sdo_geometry column, transforming the coordinates and encoding the coordinates) in .net code (web server side) by making use of the new verison of the odp.net. So I have to make a decision now to choose which approach to go, relying on Oracle server to do all the data processing or .net code. I am pretty sure Oracle can process a single request fairly quick, but if tens or even more concurrent requests for the process, I have concerns over the performance or reliability of the database server, especially the server is (a kind of ) beyond of our control (in control of the midware, IS and network team). Somebody said database is just a database and for data storing and retrieving, but may not for processing the data.
Here is more information regarding what we are doing. We use Google Map API to disply parcels. Each time the map is loaded, panned, zoomed, or refreshed (and so on), we need to query the database with spatial filter and some other criteria. The result will be tens or up to handreds of parcels containing hundreds to thousands of coordinates that are extracted from the parcel table that has a sdo_geometry column. We are expecting tens to hundreds of these requests every minute.
Now I am trying to chain every step together and do some tests using both appoachs in order to see which way is more effient and promising. I am guessing there won't be too much difference in terms of the performance for some simple testing unless I run some load testing, or if somebody like you guys can help me out.
1. load geometry information from a table with spatial filter and other conditions (where clause)
Regarding the issues you asked:
====================================
I assume you mean something like: Yes
CREATE TABLE load_table AS SELECT ID, GEOM FROM base_table where SDO_INSIDE(....) = 'TRUE';
2. get the points from the geometry column (sdo_geometry)
I assume you mean something like: Yes
SELECT ID, v.x, v.y FROM load_table l, TABLE(sdo_util.getVertices(l.geom)) t;
(See last comment about data.)
The problem is that we need a lot more information on what it is that you want to do in steps 3 - 5.
3. Transform the coordinates.
What sort of transformation? Rotation, Shift, Scale, Coordinate rounding? Transform from UTM to LatLng
4. Encoding the coordinates
What do you mean by this? Write them out as WKT/KML/GML? Google map encoded polylines
5. Output
Again, output to what, where? A new table? A shapefile? A text file? JSONP formatted data
Also, if you can provide a single sdo_geometry object + data and some example SQL it would help as well.
Here is an example where I take a geometry, rotate it (cf 3. Transform), extract vertices (2. get points), encode it (4. Encoding), and then output to screen (5. Output).
WITH myGeom As (
SELECT 1 as id,
MDSYS.SDO_GEOMETRY(2006, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1,5,2,1), MDSYS.SDO_ORDINATE_ARRAY(355600.52, 5407396.19, 361365.32, 5408106.36, 356488.27, 5409242.37, 357437.46, 5406457.67)) as geom
FROM DUAL
SELECT g.id || ',' || t.x || ',' || t.y as csv
FROM myGeom g,
TABLE (sdo_util.getVertices(
GEOM.Rotate(p_geometry => g.geom,
p_tolerance => 0.005,
p_rotatePt => MDSYS.SDO_Point_Type(357437.46,5406457.67,NULL),
p_rotation => 45 ))) t;
-- Results
CSV
1,355474.91,5405822.39
1,359049.08,5410400.89
1,354797.2,5407755.57
1,357437.46,5406457.67
Now show us what it is you want to do!!
Edited by: James Dong on May 31, 2012 11:41 AM

Geometry to WKT

Similar Messages

Maybe you are looking for