Bug in SDO_CS.TRANSFORM

Hey,
Is this bug fixed on 10.2.0.3 ?
Can any one tell me which patch level i need?
select SDO_CS.TRANSFORM(SDO_CS.TRANSFORM(SDO_GEOMETRY(2001,
31467,
NULL,
SDO_ELEM_INFO_ARRAY(1,1,1),
SDO_ORDINATE_ARRAY(3480000, 5500000)),
4326),
31467)
from dual;
ORACLE 10.2.0.3
last patch 5557962 2006/11/09
SDO_CS.TRANSFORM(SDO_CS.TRANSFORM(SDO_GEOMETRY(2001,31467,NULL,SDO_ELEM_INFO_ARRAY(1,1,1),SDO_ORDINATE_ARRAY(3480000,5500000)),4326),31467)
MDSYS.SDO_GEOMETRY(2001,31467,null,MDSYS.SDO_ELEM_INFO_ARRAY(1,1,1),MDSYS.SDO_ORDINATE_ARRAY(1155332745513930000000000000000000000000,-853409188568400000000000000000000000000000000))
works fin on Oracle 11g1
SDO_CS.TRANSFORM(SDO_CS.TRANSFORM(SDO_GEOMETRY(2001,31467,NULL,SDO_ELEM_INFO_ARRAY(1,1,1),SDO_ORDINATE_ARRAY(3480000,5500000)),4326),31467)
MDSYS.SDO_GEOMETRY(2001,31467,null,MDSYS.SDO_ELEM_INFO_ARRAY(1,1,1),MDSYS.SDO_ORDINATE_ARRAY(3480000.00785713,5500000.00191051))
tschau and thanks
Andreas

Good question, we found the bug.
Is this fixed in 10.3.0.2 or is a upgrade necessary to 10.2.0.4?
ALTER SESSION SET NLS_NUMERIC_CHARACTERS=".,";
select SDO_CS.TRANSFORM(SDO_CS.TRANSFORM(SDO_GEOMETRY(2001,
31467,
NULL,
SDO_ELEM_INFO_ARRAY(1,1,1),
SDO_ORDINATE_ARRAY(3480000, 5500000)),
4326),
31467)
from dual;
ALTER SESSION SET NLS_NUMERIC_CHARACTERS=",.";
select SDO_CS.TRANSFORM(SDO_CS.TRANSFORM(SDO_GEOMETRY(2001,
31467,
NULL,
SDO_ELEM_INFO_ARRAY(1,1,1),
SDO_ORDINATE_ARRAY(3480000, 5500000)),
4326),
31467)
from dual;
ALTER SESSION SET succeeded.
SDO_CS.TRANSFORM(SDO_CS.TRANSFORM(SDO_GEOMETRY(2001,31467,NULL,SDO_ELEM_INFO_ARRAY(1,1,1),SDO_ORDINATE_ARRAY(3480000,5500000)),4326),31467)
MDSYS.SDO_GEOMETRY(2001,31467,null,MDSYS.SDO_ELEM_INFO_ARRAY(1,1,1),MDSYS.SDO_ORDINATE_ARRAY(3480000.00764764,5500000.00013957))
1 rows selected
ALTER SESSION SET succeeded.
SDO_CS.TRANSFORM(SDO_CS.TRANSFORM(SDO_GEOMETRY(2001,31467,NULL,SDO_ELEM_INFO_ARRAY(1,1,1),SDO_ORDINATE_ARRAY(3480000,5500000)),4326),31467)
MDSYS.SDO_GEOMETRY(2001,31467,null,MDSYS.SDO_ELEM_INFO_ARRAY(1,1,1),MDSYS.SDO_ORDINATE_ARRAY(1155332745513930000000000000000000000000,-853409188568400000000000000000000000000000000))                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                                           tschau and thanks
Andreas
Edited by: user542732 on Dec 12, 2008 10:56 AM

Similar Messages

Sdo_cs.transform procedure in a materialized view

Hi all,
Oracle version :10.2.0.4
I am trying to do perform reprojection in a materialised view ( refresh on demand, complete mode).
It seems everytime I refresh the MV ,this error pops up.
SQL> exec dbms_mview.refresh('SUPER', 'C');
BEGIN dbms_mview.refresh('SUPER', 'C'); END;
ERROR at line 1:
ORA-12008: error in materialized view refresh path
ORA-06531: Reference to uninitialized collection
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2251
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2457
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2426
ORA-06512: at line 1
<code>
CREATE MATERIALIZED VIEW "SUPER" ORGANIZATION HEAP PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255 NOCOMPRESS LOGGING STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 BUFFER_POOL DEFAULT) TABLESPACE "DATA_DATA" BUILD DEFERRED USING INDEX REFRESH COMPLETE ON DEMAND USING DEFAULT LOCAL ROLLBACK SEGMENT DISABLE QUERY REWRITE
AS
SELECT seq_nextval AS PID,
SITE,
STATE,
reproject(geoloc)
FROM BJON;
<code>
The procedure of reproject
create or replace
FUNCTION "REPROJECT" (p_coordinates in SDO_GEOMETRY)
     return SDO_GEOMETRY deterministic
     as v_coordinates SDO_GEOMETRY;
     BEGIN
          v_coordinates := sdo_cs.transform (p_coordinates, 4326);
          RETURN v_coordinates;
     end REPROJECT;
Can anyone let me know hw I can put plug thereprojection in a materialized view.
Edited by: CrackerJack on May 2, 2012 11:00 PM

Hi all,
Any clues?
I have died of anymore ideas to make this work.
All I need is a updated table with
Primary key ,
GEOMETRY 4326
spatial index.
metadata
Teh materialized view is perfect except I can't do the reprojections.
ORA-06531: Reference to uninitialized collection means have some null values in the array , but if you remove the Reproject function and just geometry itself , the materialised view works brilliant.
I tried converting to 0,0 point in the function to tackle the nulls in array if any.. but doesn't work.
sdo_cs.transform(nvl(geoloc, mdsys.sdo_geometry(2001, 8307, mdsys.sdo_point_type(0,0,NULL),NULL,NULL)),82027).get_wkt()
Any ideas is much appreciated.
Edited by: CrackerJack on May 6, 2012 10:27 PM

Sdo_cs.transform on Compaq tru64 UNIX

We have managed to get sdo_cs.transform function working on NT after applying the latest patches. We now need to have it work on Compaq Tru64 Ver 4.0F where we have just installed Oracle 8.1.6.3.0 with all the latest patches.
We get the error:
"ORA-03113: end-of-file on communication channel"
whenever we try the sdo_cs.transform function.
The following code works on our NT installation but fails on the UNIX installation:
SQL> SELECT * FROM AMG56_AGD66;
PLACE_NAME
POSITION(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
AMG56_AGD66
SDO_GEOMETRY(2001, 81938, SDO_POINT_TYPE(498910, 6966131, NULL), NULL, NULL)
SQL> SELECT c.place_name "Name",
2 c.position.sdo_srid,
3 c.position.sdo_point.x "Easting 1",
4 c.position.sdo_point.y "Northing 1",
5 c.position,
6 sdo_cs.transform(c.position,m.diminfo,82413)
7 FROM AMG56_AGD66 c, user_sdo_geom_metadata m
8 WHERE m.table_name = 'AMG56_AGD66'
9 AND m.column_name = 'POSITION';
SELECT c.place_name "Name",
ERROR at line 1:
ORA-03113: end-of-file on communication channel
SQL> SELECT * FROM AMG56_AGD66;
SELECT * FROM AMG56_AGD66
ERROR at line 1:
ORA-03114: not connected to ORACLE
SQL>
Any ideas???
Regards
Peter Cohen
null

Hi Peter,
I believe that functionality was broken in the field test version of coordinate systems that shipped in 8.1.6 only for transforming data stored in the SDO_POINT type. I'm not sure, but I doubt this will be patched on tru64 unix.
If you need to get this working you might want to try storing your point data using the elem_info_array and the ordinate array rather than the optimized point type.
This problem is fixed in 8.1.7.
Hope this helps,
dan

ORA-13282: failure on initialization of coordinate transformation

Hi all,
I try to create an index with type spatial_index and get this errormessage:
ORA-29855: error occurred in the execution of ODCIINDEXCREATE routine
ORA-13282: failure on initialization of coordinate transformation
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_10I", line 10
ORA-06512: at line 1
The WKTEXT ist this one (if it has something to do with it):
PROJCS["Thueringen 4",GEOGCS["GCS_Deutsche_Hauptdreiecksnetz", DATUM["D_DHDN",SPHEROID["Bessel_1841",6377397.155,299.1528128]], PRIMEM["Greenwich",0],UNIT["Degree",0.0174532925199433]], PROJECTION["Transverse_Mercator"],PARAMETER["False_Easting",4500000], PARAMETER["False_Northing",0],PARAMETER["Central_Meridian",12], PARAMETER["Scale_Factor",1],PARAMETER["Latitude_Of_Origin",0],
UNIT["Meter",1]]
Does anybody have any idea, what the problem could be?
Thanks in advance
Alex

Hi Udo,
This worked for me in 10g R1:
insert into cs_srs values (
'DHDN Soldner Berlin (EPSG 3068)',
81989002,
81989002,
NULL,
'PROJCS ["DHDN / Soldner Berlin",
GEOGCS ["",
DATUM ["",
SPHEROID ["Bessel 1841", 6377397.155000, 299.152813],
582.000000, 105.000000, 414.000000, -1.040000, -0.350000, 3.080000, 8.300000],
PRIMEM [ "Greenwich", 0.000000 ],
UNIT ["Decimal Degree", 0.01745329251994330]],
PROJECTION ["Transverse Mercator"],
PARAMETER ["Central_Meridian", 13.6272037],
PARAMETER ["Latitude_Of_Origin", 52.41864828],
PARAMETER ["False_Easting", 40000.00],
PARAMETER ["False_Northing", 10000.00],
UNIT ["Meter",1.000000000000]
null);
select sdo_cs.validate_wkt(81989002) from dual;
select sdo_cs.transform(sdo_geometry(2001,8192,sdo_point_type(13.6,52.4,null),null,null),81989002)
from dual;
select sdo_cs.transform(SDO_GEOMETRY(2001,81989002,SDO_POINT_TYPE(38098.5904,8073.54076,NULL),NULL,NULL),8192)
from dual;
In 10gR2, you'll have to follow the new requirements for coordinate systems.

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

New patches broke our transforms?

Hi all,
After applying the patch set, we now get this error when performing an SDO_CS.TRANSFORM()
ORA-29400: data cartridge error
ORA-30625: method dispatch on NULL SELF argument is disallowed
ORA-06512: at "MDSYS.SDO_CS", line 927
ORA-06512: at "MDSYS.SDO_CS", line 79
ORA-06512: at "MDSYS.SDO_CS", line 116
The query is:
SELECT order_id, sdo_cs.transform_orig (area, 8307)
FROM my_polygon p
WHERE p.area IS NOT NULL;
Area is stored in a custom SRID we've defined locally as 9000001. This exact same data works in our dev environment withOUT the patches.
Anybody have any ideas? Thanks in advance!
ENVIRONMENT DETAILS:
Production versions:
Oracle Database 10g Enterprise Edition Release 10.2.0.4.0 - 64bi
PL/SQL Release 10.2.0.4.0 - Production
CORE 10.2.0.4.0 Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.4.0 - Productio
NLSRTL Version 10.2.0.4.0 - Production
Dev versions:
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
PL/SQL Release 10.2.0.3.0 - Production
CORE 10.2.0.3.0 Production
TNS for IBM/AIX RISC System/6000: Version 10.2.0.3.0 - Productio
NLSRTL Version 10.2.0.3.0 - Production

Was a solution ever found?
Thinking we just hit this same issue.
We just upgrated from 10.2.0.2 to 10.2.0.4 RDBMS.

BPC 10 MS Transformation format error using *MVAL with no Rejected items

I'm a bit perplexed, but maybe I'm being too ambitious. I am trying to combine a year field from a column in my data file with 12 data columns for each month of that year using *MVAL to pick up those columns. Basically I want to pull from the file with a result like 2014P1 and then use a Time conversion to make it 2014.OCT.
I have found that the Mapping statement *Col(1)+*MVAL(25:36) does not work, but reversing it does, i.e. *MVAL(25:36)+*Col(1). This brings the small problem in the conversion file of making P1* convert for both P1 and P10, so to solve this I added +*Str(.) in the middle of the mapping statement. This brings results like P1.2014 and P10.2014 to be converted in the conversion file.
After several attempts the conversion I ended up with is:
EXTERNAL P1.* : INTERNAL *.OCT
EXTERNAL P2.* : INTERNAL *.NOV etc etc to P12
When validating the Transformation file it returns the error:
Input string was not in a correct format
Validation with data file failed
[The conversion file validated and processed with no problems, even with some VB added to reduce the year by 1 in the first three Periods.]
The strange thing is that the Rejected List is not greyed out, but it is completely empty - usually this error generates some rejected items that you can then learn from and revise your mappings or conversions.
If I change the conversion to repeat the * after the month, *.OCT*, then I do get rejections that correctly tell me that the conversion does not match my time id's. I see 2014.OCT2014 in the rejected items. This confirms that the correct part is being picked up by the conversion *.OCT, but that for some reason it is not accepted.
Running this for an Import in Data Manager also fails - this is not a bug in the transformation validation routine.
So, my questions are:
- am I doing something obviously wrong? or
- am I being too ambitious with *MVAL? or
- should this work, so that a dynamic conversion for any year can be set up - in other words is this a bug?
We are running BPC v10 MS SP12 with EPM SP16. I attach my Transformation file and the Time conversion.
Thanks
Chris

I was much delayed in testing this due to other issues, but an opportunity came up last week when building a new environment. This time the column headings were needed for the 12 data columns (12 months Oct to Sep with 3 letters) which meant I could try adding the year as a *Str() function in the mapping before the *MVAL statement.
The result was that it still failed but with another error:
Index was outside the bounds of the array.
I abandoned due to time and built a specific conversion file for the months. Each time I load some historic data I have to edit this to put in the correct years. I keep these lists pasted on the right of the formula column for easy reference.
One odd thing that we still find consistently since SP12 is that the last column header is always missed. To get around this we often add an extra blank column to the input files or in this case I added P12 to my conversion file so that the data was picked up. This is inconvenient.
It would be good to be able to pick up a year from a column in the data or to add it with the *Str() function before the *MVAL statement.
I have still to try Astha's proposal below. Next time!
Thanks
Chris.

Data change after call xml transformation for RAW data type

Hi,
Can someone explain what is workarround or any help for below problem
when call transformation is called for usr02 records, after xml string is generated is showing different data for RAW data type for example content of fields BCODE,PASSCODE etc get convert into different data
for example: content of BCODE fields before xml transformation say -7F8087472FB996E5
after xml transformation it display as f4CHRy+5luU=
why is this so happening? is this known behaviour after xml transformation or it is bug in xml transformation?
thanks in advance.
Regards,
John.

Hi,
I think this is because RAW data is BASE64 encoded when using CALL TRANSFORMATION.
Old post, but did you ever find a way to change that?
Thanks

Transformation Layer

Hello. I'm new there and this is my first thread. I looked in many places but I didn't find solution.
I have some problem with transformation GoogleMaps layer.
After added MVGoogleMapsLayer to MapViewer I take popup alert
[MVMapView.transformGeom] MAPVIEWER-05523: Cannot process response from MapViewer server.
(<?xml version="1.0" encoding="UTF-8"?>
<mcs_error>MCSServlet:ORA-13282: nie uda?o si? zainicjalizowa? transformacji wsp�?rz?dnych*
ORA-06512: przy "MDSYS.SDO_CS", linia 75
ORA-06512: przy "MDSYS.SDO_CS", linia 112
ORA-06512: przy "MDSYS.SDO_CS", linia 2678
</mcs_error>
*cannot initialize transform coordinates system
MVMapView.transformGeom] MAPVIEWER-05523:
Cannot process response from MapViewer server.
(<?xml version="1.0" encoding="UTF-8"?><mcs_error>MCSServlet:For input string: "-~"</mcs_error>)
In the FireBug I can see ajax request
http://localhost:8888//mapviewer/proxy?rtarget=http://localhost:8888/mapviewer/mcserver&request=cstransform&dstsrid=8307&geometry=SdoGeometry(2001,2180,(520000,450000,),,)&datasource=test
and response
<?xml version="1.0" encoding="UTF-8"?><mcs_error>MCSServlet:For input string: "-~"</mcs_error>
By the way in SQLDeveloper after uses SDO_CS.TRANSFORM I don't get response (only void rows).
I checked MDSYS.SDO_CS_SRS and I have all needed cs. My coordinates system is epsg:2180.
Sorry for my English but I don't have a chance to practice this skills.

Thanks for the answer. I found it yesterday and it's working.
But it's half success because it transformate my data to google maps coordinates and that make same problems.
I try now transformate data in database to google maps coordinates system and it works better.
Thanks for help.

Simple transform not working as expected

I'm new to Oracle Spatial, and I'm having some problems.
I'm trying to do a simple transform of a rectangle from one srid to another, and I'm getting the craziest results. After playing around, I found that I get the same weird behavior when I transform from an srid to itself.
This, for example, returns what I would expect it to:
select
-- SDO_CS.TRANSFORM (
SDO_GEOMETRY ( 2003, 8307, null, sdo_elem_info_array ( 1, 1003, 3 ),
SDO_ORDINATE_ARRAY ( -84.3416667, 41.2833333, -84.3250000, 41.2750000 )
-- ) , 8307
AS results FROM dual
With the two lines commented out, this is a simple selection of a rectangular geometry, without any transformation. It returns the coordinates it was given, with the trailing '0's trimmed off:
RESULTS(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 3), SDO_ORDINATE_ARRAY(
-84.341667, 41.2833333, -84.325, 41.275))
But if I uncomment the two lines, so that I' doing a transform of the rectangle from the WGS84 it was in into WGS 84, I get the weirdest results:
select
SDO_CS.TRANSFORM (
SDO_GEOMETRY ( 2003, 8307, null, sdo_elem_info_array ( 1, 1003, 3 ),
SDO_ORDINATE_ARRAY ( -84.3416667, 41.2833333, -84.3250000, 41.2750000 )
) , 8307
AS results FROM dual
RESULTS(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY(
-84.341667, 41.2833333, -84.340767, 41.2833333, -84.339868, 41.2833333, -84.338969, 41.2833333, -84.338069, 41.2833333, -84.33717, 41.2833333, -84.336271, 41.2833333, -84.335371, 41.2833333, -84.334472, 41.2833333, -84.333573, 41.2833333, -84.332673, 41.2833333, -84.331774, 41.2833333, -84.330875, 41.2833333, -84.329976, 41.2833333, -84.329076, 41.2833333, -84.328177, 41.2833333, -84.327278, 41.2833333, -84.326378, 41.2833333, -84.325479, 41.2833333, -84.325, 41.2833333, -84.325, 44.88325, -84.325, 48.4831666, -84.325, 52.0830833, -84.325, 55.683, -84.325, 59.2829166, -84.325, 62.8828333, -84.325, 66.48275, -84.325, 70.0826666, -84.325, 73.6825833, -84.325, 77.2825, -84.325, 80.8824166, -84.325, 84.4823333, -84.325, 88.08225, -84.325, 91.6821666, -84.325, 95.2820833, -84.325, 98.882, -84.325, 102.481917, -84.325, 106.081833, -84.325, 109.68175, -84.325, 113.281667, -84.325, 116.881583, -84.325, 120.4815, -84.325, 124.081417, -84.325, 127.681333, -84.325, 131.28125, -84.325, 134.881167, -84.325, 138.481083, -84.325, 142.081, -84.325, 145.680917, -84.325, 149.280833, -84.325, 152.88075, -84.325, 156.480667, -84.325, 160.080583, -84.325, 163.6805, -84.325, 167.280417, -84.325, 170.880333, -84.325, 174.48025, -84.325, 178.080167, -84.325, 181.680083, -84.325, 185.28, -84.325, 188.879917, -84.325, 192.479833, -84.325, 196.07975, -84.325, 199.679667, -84.325, 203.279583, -84.325, 206.8795, -84.325, 210.479417, -84.325, 214.079333, -84.325, 217.67925, -84.325, 221.279167, -84.325, 224.879083, -84.325, 228.479, -84.325, 232.078917, -84.325, 235.678833, -84.325, 239.27875, -84.325, 242.878667, -84.325, 246.478583, -84.325, 250.0785, -84.325, 253.678417, -84.325, 257.278333, -84.325, 260.87825, -84.325, 264.478167, -84.325, 268.078083, -84.325, 271.678, -84.325, 275.277917, -84.325, 278.877833, -84.325, 282.47775, -84.325, 286.077667, -84.325, 289.677583, -84.325, 293.2775, -84.325, 296.877417, -84.325, 300.477333, -84.325, 304.07725, -84.325, 307.677167, -84.325, 311.277083, -84.325, 314.877, -84.325, 318.476917, -84.325, 322.076833, -84.325, 325.67675, -84.325, 329.276667, -84.325, 332.876583, -84.325, 336.4765, -84.325, 340.076417, -84.325, 343.676333, -84.325, 347.27625, -84.325, 350.876167, -84.325, 354.476083, -84.325, 358.076, -84.325, 361.675917, -84.325, 365.275833, -84.325, 368.87575, -84.325, 372.475667, -84.325, 376.075583, -84.325, 379.6755, -84.325, 383.275417, -84.325, 386.875333, -84.325, 390.47525, -84.325, 394.075167, -84.325, 397.675083, -84.325, 41.275, -84.325899, 41.275, -84.326799, 41.275, -84.327698, 41.275, -84.328597, 41.275, -84.329497, 41.275, -84.330396, 41.275, -84.331295, 41.275, -84.332195, 41.275, -84.333094, 41.275, -84.333993, 41.275, -84.334893, 41.275, -84.335792, 41.275, -84.336691, 41.275, -84.337591, 41.275, -84.33849, 41.275, -84.339389, 41.275, -84.340288, 41.275, -84.341188, 41.275, -84.341667, 41.275, -84.341667, 37.6750833, -84.341667, 34.0751667, -84.341667, 30.47525, -84.341667, 26.8753333, -84.341667, 23.2754167, -84.341667, 19.6755, -84.341667, 16.0755833, -84.341667, 12.4756667, -84.341667, 8.87575, -84.341667, 5.27583333, -84.341667, 1.67591666, -84.341667, -1.924, -84.341667, -5.5239167, -84.341667, -9.1238333, -84.341667, -12.72375, -84.341667, -16.323667, -84.341667, -19.923583, -84.341667, -23.5235, -84.341667, -27.123417, -84.341667, -30.723333, -84.341667, -34.32325, -84.341667, -37.923167, -84.341667, -41.523083, -84.341667, -45.123, -84.341667, -48.722917, -84.341667, -52.322833, -84.341667, -55.92275, -84.341667, -59.522667, -84.341667, -63.122583, -84.341667, -66.7225, -84.341667, -70.322417, -84.341667, -73.922333, -84.341667, -77.52225, -84.341667, -81.122167, -84.341667, -84.722083, -84.341667, -88.322, -84.341667, -91.921917, -84.341667, -95.521833, -84.341667, -99.12175, -84.341667, -102.72167, -84.341667, -106.32158, -84.341667, -109.9215, -84.341667, -113.52142, -84.341667, -117.12133, -84.341667, -120.72125, -84.341667, -124.32117, -84.341667, -127.92108, -84.341667, -131.521, -84.341667, -135.12092, -84.341667, -138.72083, -84.341667, -142.32075, -84.341667, -145.92067, -84.341667, -149.52058, -84.341667, -153.1205, -84.341667, -156.72042, -84.341667, -160.32033, -84.341667, -163.92025, -84.341667, -167.52017, -84.341667, -171.12008, -84.341667, -174.72, -84.341667, -178.31992, -84.341667, -181.91983, -84.341667, -185.51975, -84.341667, -189.11967, -84.341667, -192.71958, -84.341667, -196.3195, -84.341667, -199.91942, -84.341667, -203.51933, -84.341667, -207.11925, -84.341667, -210.71917, -84.341667, -214.31908, -84.341667, -217.919, -84.341667, -221.51892, -84.341667, -225.11883, -84.341667, -228.71875, -84.341667, -232.31867, -84.341667, -235.91858, -84.341667, -239.5185, -84.341667, -243.11842, -84.341667, -246.71833, -84.341667, -250.31825, -84.341667, -253.91817, -84.341667, -257.51808, -84.341667, -261.118, -84.341667, -264.71792, -84.341667, -268.31783, -84.341667, -271.91775, -84.341667, -275.51767, -84.341667, -279.11758, -84.341667, -282.7175, -84.341667, -286.31742, -84.341667, -289.91733, -84.341667, -293.51725, -84.341667, -297.11717, -84.341667, -300.71708, -84.341667, -304.317, -84.341667, -307.91692, -84.341667, -311.51683, -84.341667, -315.11675, -84.341667, 41.2833333))
Which makes no sense to me whatsoever. I mean, why so many points? And why such absurd points? Srid 8307 is "Longitude / Latitude (WGS 84)", it shouldn't be giving me X coordinates of -250, or Y coordinates of 196.
Clearly I'm doing something fundamentally wrong, but I'm at a loss to see what.
I'm hoping it's something obvious. Help would be appreciated.

Hi
For someone being new, I advice to start reading, and yes a lot of informartion to deal with in the beginning, is the very well written documentaion.
In your case you should read carefully chapter 6
http://download.oracle.com/docs/cd/E11882_01/appdev.112/e11830/sdo_cs_concepts.htm#i891851
with specific attention to 6.2 Geodetic Coordinate Support
http://download.oracle.com/docs/cd/E11882_01/appdev.112/e11830/sdo_cs_concepts.htm#i891851
In there you will find a section 6.2.4 Geodetic MBRs
which completely describes the reasons behind the behaviour you have noticed.
most important:
The following considerations apply to the use of geodetic MBRs:
•Do not use a geodetic MBR with spatial objects stored in the database. Use it only to construct a query window.
•The lower-left Y coordinate (minY) must be less than the upper-right Y coordinate (maxY). If the lower-left X coordinate (minX) is greater than the upper-right X coordinate (maxX), the window is assumed to cross the date line meridian (that is, the meridian "opposite" the prime meridian, or both 180 and -180 longitude). For example, an MBR of (-10,10, -100, 20) with longitude/latitude data goes three-fourths of the way around the Earth (crossing the date line meridian), and goes from latitude lines 10 to 20.
•When Spatial constructs the MBR internally for the query, lines along latitude lines are densified by adding points at one-degree intervals. This might affect results for objects within a few meters of the edge of the MBR (especially objects in the middle latitudes in both hemispheres).
•When an optimized rectangle spans more than 119 degrees in longitude, it is internally divided into three rectangles; and as a result, these three rectangles share an edge that is the common boundary between them. If you validate the geometry of such an optimized rectangle, error code 13351 is returned because the internal rectangles have a shared edge. You can use such an optimized rectangle for queries with only the following: SDO_ANYINTERACT operator, SDO_RELATE operator with the ANYINTERACT mask, or SDO_GEOM.RELATE function with the ANYINTERACT mask. (Any other queries on such an optimized rectangle may return incorrect results.)
Good luck
Luc

Error when transforming a buffered geometry

This driving me mad!!
I have a procedure that compares a standard polygon to other polygons held in a number of tables to see if they interact. Some of the geometries held in the other tables are of differing coordinate systems, so before I compare I translate the geoms. This all works fine.
However, if I buffer the geometry before I call the procedure, I get all sorts of errors to do with transformation. has anybody successfully translated buffered polygons? and if so how
Many thanks
Chris
The buffered shape that errors is basically this: (copy an paste this and see if you get the error):
SELECT sdo_cs.transform(SDO_GEOMETRY(2003,81989,NULL,SDO_ELEM_INFO_ARRAY(1,1005,18,1,2,1,3,2,2,7,2,1,9,2,2,13,2,1,15,2,2,19,2,1,21,2,2,25,2,1,27,2,2,31,2,1,33,2,2,37,2,1,39,2,2,43,2,1,45,2,2,49,2,1,51,2,2),SDO_ORDINATE_ARRAY(351184.93,490373.18,351177.99,490370.87,351144.85,490352.23,351121.08,490322.56,351117.77,490316.27,351106.4,490264.5,351123.08,490214.19,351126.39,490209.23,351162.4,490176.56,351209.57,490164.74,351215.85,490164.74,351233.51,490166.31,351250.61,490170.97,351259.54,490174.28,351294.62,490196.48,351317.67,490231.01,351318.99,490234.32,351326.03,490267.66,351321.47,490301.43,351319.49,490307.71,351304.11,490337.66,351279.65,490360.8,351276.67,490362.79,351236.53,490378.44,351193.53,490375.74,351188.9,490374.41,351186.91,490373.82,351184.93,490373.18)),27700)
FROM DUAL
If I change this from a complex shape into a polygon it works fine (not sure if this is valid to just change the elem info?):
SELECT sdo_cs.transform(SDO_GEOMETRY(2003,81989,NULL,SDO_ELEM_INFO_ARRAY(1,1003,1),SDO_ORDINATE_ARRAY(351184.93,490373.18,351177.99,490370.87,351144.85,490352.23,351121.08,490322.56,351117.77,490316.27,351106.4,490264.5,351123.08,490214.19,351126.39,490209.23,351162.4,490176.56,351209.57,490164.74,351215.85,490164.74,351233.51,490166.31,351250.61,490170.97,351259.54,490174.28,351294.62,490196.48,351317.67,490231.01,351318.99,490234.32,351326.03,490267.66,351321.47,490301.43,351319.49,490307.71,351304.11,490337.66,351279.65,490360.8,351276.67,490362.79,351236.53,490378.44,351193.53,490375.74,351188.9,490374.41,351186.91,490373.82,351184.93,490373.18)),27700)
FROM DUAL

Sdo Buffer usually generate arcs in the result(etype= 1005) for projected coordinate systems. If you use the buffer geometry in sdo_cs.transform, you might run into problems.
You can use SDO_GEOM.SDO_ARC_DENSIFY funtion before transforming them to geodetic coordinates, and then perform Spatial operations on the resulting geometries.
6.2.5 Other Considerations and Requirements with Geodetic Data (11.2)
The following geometries are not permitted if a geodetic coordinate system is used or if any transformation is being performed (even if the transformation is from one projected coordinate system to another projected coordinate system):
* Circles
* Circular arcs
Geodetic coordinate system support is provided only for geometries that consist of points or geodesics (lines on the ellipsoid). If you have geometries containing circles or circular arcs in a projected coordinate system, you can densify them using the SDO_GEOM.SDO_ARC_DENSIFY function (documented in Chapter 24) before transforming them to geodetic coordinates, and then perform Spatial operations on the resulting geometries.Or you can try to first transform the geometry and then generate the buffer and then issue your sql queries.
jack
Edited by: Jack Wang on Nov 9, 2010 7:03 PM

Failure on initialization of coordinate transformation

I am trying to define a "custom" projection for our local coordinate system. The local coordinate system is a shifted and rotated state plane. To begin, I inserted a row in the mdsys.cs_srs that uses the WKTEXT field from the record for State Plance SC-south, 3902 (SRID=41133). I then "added", after the SPHEROID parameter, the shift, rotate, and scale values. Since our local coordinate system origin (0,0) is 1795630.77, 434471.63 svy_ft in SRID 41133, I converted the value to meters (547308.2586,132426.9528) and placed them in the position's of xShift, xShift, with negative signs. (ie SPHEROID["Clarke 1866",6378206.4,294.978698],-547308.2586,-132426.9528,0.0,0.0,0.0,0.0,1.0] )with the expectation that if I "transformed" a point (e.g. 1795630.77, 434471.63) into my custom projection, I should get back 0,0 as the answer. When I run my test case, I receive:
ORA-13282 failure on initialization of coordinate transformation
ORA-06512 at "MDSYS.SDO_CS", line 23
ORA-06512 at "MDSYS.SDO_CS", line 43
Any recommendations/thoughts on what is wrong??
Thanks in Advance!!

I think (but i am not sure) that you should not be changing the datum to shift the ellipsoid in X and Y.
Without knowing exactly what you are trying to do, it is difficult to be sure, but I think you just want to shift the results so the point (1795630.77, 434471.63) in 41133 becomes 0,0 in the shifted coordinate system, but you don't want to change the standard parallels or the latitude of origin.
To do this I think you want to take the original definition of 41133, and apply/reapply a false easting and a false northing.
I did this with the following:
delete from cs_srs where srid=1041133;
insert into cs_srs values (
'SRS Local Grid',1041133,1041133,
'dan',
'PROJCS["SRS Local Grid",
GEOGCS [ "NAD 27 (Continental US)",
DATUM ["NAD 27 (Continental US)",
SPHEROID ["Clarke 1866", 6378206.4, 294.9786982]],
PRIMEM [ "Greenwich", 0.000000 ],
UNIT ["Decimal Degree", 0.01745329251994330]],
PROJECTION ["Lambert Conformal Conic"],
PARAMETER ["Standard_Parallel_1", 32.333333],
PARAMETER ["Standard_Parallel_2", 33.666667],
PARAMETER ["Central_Meridian", -81.000000],
PARAMETER ["Latitude_Of_Origin", 31.833333],
PARAMETER ["False_Easting", 204369.23],
PARAMETER ["False_Northing", -434471.63],
UNIT ["U.S. Foot", 0.3048006096012]]',
null);
select sdo_cs.transform(mdsys.sdo_geometry
(2001,41133,sdo_point_type(1795630.77, 434471.63,null),null,null), 1041133)from dual;
SDO_CS.TRANSFORM(MDSYS.SDO_GEO(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM
SDO_GEOMETRY(2001, 1041133, SDO_POINT_TYPE(4.4806E08, .000006755, NULL), NULL,NULL)

Unknown error from SDO_CS :(

any help in resolving this issue..
May 7, 2009 12:05:11 AM oracle.sdovis.theme.DynGeomThemeProducer prepareData
SEVERE: Error fetching data.
java.sql.SQLException: ORA-06531: Reference to uninitialized collection
ORA-06512: at "MDSYS.SDO_CS", line 2553
ORA-06512: at "MDSYS.SDO_CS", line 2678
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:138)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:316)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:282)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:639)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:185)
at oracle.jdbc.driver.T4CPreparedStatement.execute_for_rows(T4CPreparedStatement.java:633)
at oracle.jdbc.driver.OracleStatement.execute_maybe_describe(OracleStatement.java:1048)
at oracle.jdbc.driver.T4CPreparedStatement.execute_maybe_describe(T4CPreparedStatement.java:535)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1126)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3001)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3043)
at oracle.sdovis.theme.DynGeomThemeProducer.prepareData(DynGeomThemeProducer.java:335)
at oracle.sdovis.Theme.prepareData(Theme.java:183)
at oracle.sdovis.LoadThemeData.run(LoadThemeData.java:74)
May 7, 2009 12:05:11 AM oracle.sdovis.LoadThemeData run
SEVERE: Exception fetching data for theme MY_JDBC_THEME.
Message:null
Description: Nested exception is:
java.sql.SQLException: ORA-06531: Reference to uninitialized collection
ORA-06512: at "MDSYS.SDO_CS", line 2553
ORA-06512: at "MDSYS.SDO_CS", line 2678
java.sql.SQLException: ORA-06531: Reference to uninitialized collection
ORA-06512: at "MDSYS.SDO_CS", line 2553
ORA-06512: at "MDSYS.SDO_CS", line 2678
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:138)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:316)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:282)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:639)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:185)
at oracle.jdbc.driver.T4CPreparedStatement.execute_for_rows(T4CPreparedStatement.java:633)
at oracle.jdbc.driver.OracleStatement.execute_maybe_describe(OracleStatement.java:1048)
at oracle.jdbc.driver.T4CPreparedStatement.execute_maybe_describe(T4CPreparedStatement.java:535)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1126)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3001)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3043)
at oracle.sdovis.theme.DynGeomThemeProducer.prepareData(DynGeomThemeProducer.java:335)
at oracle.sdovis.Theme.prepareData(Theme.java:183)
at oracle.sdovis.LoadThemeData.run(LoadThemeData.java:74)
May 7, 2009 12:05:11 AM oracle.lbs.foi.FOIServlet doPost
SEVERE: MAPVIEWER-06009: Error processing an FOI request.
Message:null
Description: Nested exception is:
java.sql.SQLException: ORA-06531: Reference to uninitialized collection
ORA-06512: at "MDSYS.SDO_CS", line 2553
ORA-06512: at "MDSYS.SDO_CS", line 2678
java.sql.SQLException: ORA-06531: Reference to uninitialized collection
ORA-06512: at "MDSYS.SDO_CS", line 2553
ORA-06512: at "MDSYS.SDO_CS", line 2678
at oracle.jdbc.driver.DatabaseError.throwSqlException(DatabaseError.java:138)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:316)
at oracle.jdbc.driver.T4CTTIoer.processError(T4CTTIoer.java:282)
at oracle.jdbc.driver.T4C8Oall.receive(T4C8Oall.java:639)
at oracle.jdbc.driver.T4CPreparedStatement.doOall8(T4CPreparedStatement.java:185)
at oracle.jdbc.driver.T4CPreparedStatement.execute_for_rows(T4CPreparedStatement.java:633)
at oracle.jdbc.driver.OracleStatement.execute_maybe_describe(OracleStatement.java:1048)
at oracle.jdbc.driver.T4CPreparedStatement.execute_maybe_describe(T4CPreparedStatement.java:535)
at oracle.jdbc.driver.OracleStatement.doExecuteWithTimeout(OracleStatement.java:1126)
at oracle.jdbc.driver.OraclePreparedStatement.executeInternal(OraclePreparedStatement.java:3001)
at oracle.jdbc.driver.OraclePreparedStatement.executeQuery(OraclePreparedStatement.java:3043)
at oracle.sdovis.theme.DynGeomThemeProducer.prepareData(DynGeomThemeProducer.java:335)
at oracle.sdovis.Theme.prepareData(Theme.java:183)
at oracle.sdovis.LoadThemeData.run(LoadThemeData.java:74)
thanks in advance..
Edited by: pravkris on May 7, 2009 1:35 PM

Thanks for the reply.
I didnt have spatial index created to the table. So created it.
This solved ORA-06531: Reference to uninitialized collection error.
This actually raised second issue. From logs...
FINEST: Query changed: select sdo_cs.transform(geometry,54004) geometry, NAME, CODE FROM ( select geometry,name,code from abc)
Found srid used in abc was 8307. So recreated table with srid 54004 which actually resolved the issue.

Simple coordinate transformation

I'm new to Oracle Spatial (8.1.7) and try to figure out a simple way to run a query to get values for a single point coordinate system transformation.
For example:
If I know the x y coordinates of a point and its coordinate system (srid) and want to calculate new x y values using a second srid. Is there a way to create a SQL statement or procedure without creating a spatial table, writing to the metadata (diminfo), indexing, etc......

You'll need to use the SDO_CS.TRANSFORM. It's overloaded, so you've got some options as to which version to use. Based on your info, you might want to try...
FUNCTION TRANSFORM RETURNS SDO_GEOMETRY
Argument Name Type In/Out Default?
GEOMOBJ SDO_GEOMETRY IN
TOLERANCE NUMBER IN
TO_SRID NUMBER IN
So, try something like this...
set define &
select sdo_cs.transform(MDSYS.SDO_GEOMETRY(2001, &from_srid, MDSYS.SDO_POINT_TYPE(&sdo_x1, &sdo_y1, NULL), NULL, NULL), &tolerance, &to_srid) from dual;
This will prompt you for values, but you get the idea...
-Chris

How to transform a long LINESTRING Transform

Hi @ all,
I'm trying to transform a LineString to another CRS,
but when the LineString is to long I get error ORA-01704: string literal too long
My Select:
select a.*, a.geo.get_wkt()
from (
select SDO_CS.TRANSFORM(MDSYS.SDO_GEOMETRY('LINESTRING (6.88095 ........... 50.72032)', 8307), 82027) as geo from dual) a;
Is there any way to transform very long Linestrings ?

set serverout on
declare
temporaryCLob CLOB;
amount NUMBER;
offset NUMBER := 1;
buffer VARCHAR2(100) := 'LINESTRING ( ';
buffer2 VARCHAR2(100) := ' 1 2, 3 4, 5 6)';
g sdo_geometry;
BEGIN
DBMS_OUTPUT.ENABLE(1000000);
-- CREATE TEMPORARY LOB
DBMS_LOB.CREATETEMPORARY(
lob_loc => temporaryCLob, cache => true, dur => dbms_lob.session);
-- TEST TO SEE IF LOB IS TEMPORARY
IF (DBMS_LOB.ISTEMPORARY(temporaryCLob) = 1) THEN
DBMS_OUTPUT.PUT_LINE('This is a temporary LOB.');
ELSE
DBMS_OUTPUT.PUT_LINE('This is a persistent LOB.');
END IF;
-- OPEN TEMPORARY LOB FOR READ / WRITE
DBMS_LOB.OPEN(
lob_loc => temporaryCLob
, open_mode => DBMS_LOB.LOB_READWRITE
-- WRITE SMALL BUFFER TO TEMPORARY LOB
DBMS_LOB.WRITE(
lob_loc => temporaryCLob
, amount => LENGTH(buffer)
, offset => offset
, buffer => buffer
-- APPEND A SMALL BUFFER TO TEMPORARY LOB
DBMS_LOB.WRITEAPPEND(
lob_loc => temporaryCLob
, amount => LENGTH(buffer2)
, buffer => buffer2
-- GET CURRENT LENGTH OF TEMPORARY LOB
DBMS_OUTPUT.PUT_LINE(
'Current length of temporary LOB: ' || DBMS_LOB.GETLENGTH(temporaryCLob)
-- PRINT CONTENTS OF THE TEMPORARY LOB
DBMS_OUTPUT.PUT_LINE('Current content of temporary LOB:');
DBMS_OUTPUT.PUT_LINE(DBMS_LOB.SUBSTR(temporaryCLob, DBMS_LOB.GETLENGTH(temporaryCLob), 1));
-- CLOSE / FREE TEMPORARY LOB
DBMS_LOB.CLOSE(lob_loc => temporaryCLob);
g := sdo_geometry(temporaryCLob);
DBMS_LOB.FREETEMPORARY(lob_loc => temporaryCLob);
END;
/

Bug in SDO_CS.TRANSFORM

Similar Messages

Maybe you are looking for