SDO_DISTANCE for SRID=4156

Hello, I have problem with distance.
I created the elementary example:
select sdo_geom.sdo_distance(
SDO_GEOMETRY(2001,null,SDO_POINT_TYPE(1, 1, NULL),
NULL,NULL),
sdo_geometry(2001,null,SDO_POINT_TYPE(2, 1, NULL),
NULL,NULL),
0.5) as dist
FROM dual;
Result is 1.
I created same example, but for SRID 4156 as you can see.
SELECT SDO_GEOM.SDO_DISTANCE(
SDO_GEOMETRY(2001,4156,SDO_POINT_TYPE(1, 1, NULL),
NULL,NULL),
sdo_geometry(2001,4156,SDO_POINT_TYPE(2, 1, NULL),
NULL,NULL),
0.5,
'unit=M') as dist
FROM dual;
Result is 111289,738222679
How is possible that result is soo different?
The orientation of axis in the S-JTSK(for Czech Republic) with SRID 4156 are switched, but for this elementary example should be result still one.

Hi Radan,
Well, there are some larger issues here beyond measurement. Your first example has a NULL srid, which means this is "pure" cartesian planar coordinate system. You might think of it as an infinitely large sheet of graph paper (or eastern european notebook paper). Its perfectly flat and uniform and thus distance is just a matter of high school geometry reported in a generic unit - if you try to ask for meters or miles or whatever you will get ORA-13293. There is no mapping to the actual earth. Whether you measure the distance between 1 and 2 or 1,000,000 and 1,000,001, its all the same out in to infinity - just one generic unit.
Now 4156 is a geodetic projection using decimal degrees as its unit of measure intended for usage around the Czech Republic and Slovakia.
http://spatialreference.org/ref/epsg/4156/
Neither decimal degrees nor the same in meters is comparable to that generic distance reported above. Now another question is why you are measuring coordinates down in the Gulf of Guinea with a Czech SRID? Still, its works well enough. If we measure the same distance with WGS84 we get 111302.65 meters.
If you are looking for some kind of "default" SRID for testing or comparison, I guess I would say use WGS84 (4326).
Cheers,
Paul

Similar Messages

  • Order of coordinates affect SDO_AREA for SRID 8307

    I have this strange problem. Coordinates stored in sdo_ordinate_array in this order: 1,2,3,4,1 gives very small difference in area from coordinates stored in this order: 2,3,4,1,2.
    The difference in area is approximately in the range of ~0.001 square meters.
    Is this a bug? Any way to fix it?
    The query to show this problem is
    select sdo_geom.sdo_area(polygon,0.5) from dual;
    substitute polygon for
    sdo_geometry(2003,8307,null,sdo_elem_info_array(1,1003,1),sdo_ordinate_array(
    0.07125,-0.000069,
    0.048,0.00010,
    0.041,-0.000056,
    0.068,-0.00014,
    0.07125,-0.000069))
    gives 43081.7511289923
    and
    sdo_geometry(2003,8307,null,sdo_elem_info_array(1,1003,1),sdo_ordinate_array(
    0.068,-0.00014,
    0.07125,-0.000069,
    0.048,0.00010,
    0.041,-0.000056,
    0.068,-0.00014))
    gives 43081.7503993156
    These 2 geometry are clearly the same. but running sdo_area on them gives different results!
    I'm using oracle 10 g release2 10.2.0.4
    Any help will be greatly appreciated!
    Thanks!

    Is there any way to return the same area for the same geometry object?
    I understand that it is not easy with the inherent error, but shouldn't it be expected behavior that the same geometry object returns the same area?
    Is there anyway to fix the order of the coordinate so that sdo_area will behave?
    Is there anyway to round it to 0.1% so that the error is removed?
    Thanks!

  • Sdo_distance

    Hi, I took following bounds for SRID 32616 from EPSG and trying to compute distance.
    Projected bounds:
    166021.44 0.00
    534994.66 9329005.18
    SELECT   sdo_geom.sdo_distance( sdo_geom.sdo_geometry(2001 ,32616 ,sdo_geom.sdo_point_type(166021.44, 0, NULL) ,NULL ,NULL)
                               ,sdo_geom.sdo_geometry(2001 ,32616 ,sdo_point_type(534994.66, 0, NULL) ,NULL ,NULL) ,0.0001 ,'unit=METER') distance_in_m
                               from DUAL;
    I am getting the result 368973.22 m (368 km), i think the distance should be around 600 km.
    Please help me if i am wrong.
    Thanks

    Hi Don,
    First of all: I would use 4326 if you need WGS84, since it is more recent than 8307. Oracle marks 8307 as Legacy:
    select scrs.SRID, scrs.COORD_REF_SYS_NAME, scrs.COORD_REF_SYS_KIND, scs.COORD_SYS_TYPE,
          scs.DIMENSION, scrs.IS_VALID, scrs.IS_LEGACY, scrs.SUPPORTS_SDO_GEOMETRY, scs.COORD_SYS_NAME
    from SDO_COORD_REF_SYS scrs,
        SDO_COORD_SYS scs
    where scrs.COORD_SYS_ID = scs.COORD_SYS_ID and
          scrs.srid = 8307;
    Secondly: an ellipsoidal coordinate system measures distances along the curve of the earth, where a projected coordinate system measures distances along straight lines. It depends on the projection, but the longer the distance, the more these two distances are different. This is easy to see if you place a ruler on a ball (which is basically what happens, if the ball has been sat on by an elephant). Even in a small country like The Netherlands there is already a distortion at the ends of the country because of that.
    HTH,
    Stefan

  • Operator query fail silently if multiple srids are in indexed table

    i use an
    SDO_ANYINTERACT
    on an indexed table. By error (mine) I inserted data with another srid. All SDO_ANYINTERACT deliver 'FALSE'. May I suggest to raise exception in these cases. I dont like silent failure.
    I have another suggestion. For pointclouds oracle creates a trigger like this:
    CREATE OR REPLACE TRIGGER MDTNPC_FA15_4_TR$ BEFORE DELETE OR UPDATE ON ALS.POINTCLOUD FOR EACH ROW
    BEGIN IF DELETING THEN MDSYS.SDOTNPC.DEL_BLKTAB_ROWS(:old.PC.blk_table, :old.PC.pc_id); ELSIF UPDATING THEN MDSYS.SDOTNPC.DEL_BLKTAB_ROWS(:old.PC.blk_table, :old.PC.pc_id); END IF; END;
    basically this means: on update -> delete.
    May I suggest you raise an exception instead of simply deleting ALL associated records? If one wants to alter the tolerance on a pointcloud with f.e. 2 billion records ... guess what ...

    Can you give more details on your first case with different SRIDs.I have POINTCLOUD_${SRID} and ssPOINTCLOUD_BLK_${SRID} tables.
    On creating a pointcloud for SRID 25832 I accidentally used the wrong block table for SRID 25833. There is a $$ spatial index on the extent column. So the insert was done due to SDO_PC_PKG.create_pc...
    Maybe the index in the block table is set something like "NOVALIDATE/DISABLED/..." within this procedure (I cant look into it of course). So the check you mentioned doesnt hit.

  • Sdo_geom.validate_geometry_with_context returns error for a valid polygon

    Hi people,
    I have found a strange case, where sdo_geom.validate_geometry_with_context returns an error:
    select sdo_geom.validate_geometry_with_context(SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY(0.0, 51.9273, 0.3556, 51.9273, 0.3910, 51.9274, 0.1964, 51.9274, 0.0, 51.9273)), 1) from dual;
    13349 [Element <1>] [Ring <1>][Edge <3>][Edge <1>]
    The tolerance for SRID 8307 is in meters, right? The shape is a parallelogram, although the lat dimension is about 0.0001 grad or ~11 meters. Any hints why there is an error?
    // using Oracle Database 11g Enterprise Edition Release 11.2.0.1.0 - 64bit Production
    Edited by: Slava2 on May 27, 2013 3:12 AM

    You defined a spheric polygon in WGS84, that has a self intersection near <0.22945371630245; 51.9274226210077> :
    WITH l1 AS
    (SELECT SDO_GEOMETRY(2002, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(0.0000,51.9273, 0.3556,51.9273)) geom
        FROM dual),
        l2 AS
    (SELECT SDO_GEOMETRY(2002, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(0.3910,51.9274, 0.1964,51.9274)) geom
    FROM dual)
    SELECT  sdo_geom.sdo_intersection(l1.geom, l2.geom,0.00001) FROM l1, l2;
    (2001; 8307; ; (1; 1; 1); (0.22945371630245; 51.9274226210077))
    1 row selected.

  • Bind values for complex datatype in Oracle trace file

    If I run trace on oracle spatial queries, how can I get the detailed information of the bind variable value for sdo_geometry objects (the content of the sdo_geometry objects, e.g. coordinates... ) in the queries?
    For example, in the query, SRID, SDO_ELEM_INFO_ARRAY, and SDO_ORDINATE_ARRAY are bind variables. For SRID, I can find its value (number), but for sdo_elem_info_array and sdo_ordinate_array, I only got something like:
    BINDS #1:
    bind 0: dty=23 mxl=32(16) mal=00 scl=00 pre=00 oacflg=00 oacfl2=0 size=32 offset=0
    bfp=0c0521dc bln=32 avl=16 flg=05
    value=
    Dump of memory from 0xC0521DC to 0xC0521EC
    C0521D0 9E2362B1 [.b#.]
    C0521E0 479F3EB7 8B3F2BA9 A1441E4C [.>.G.+?.L.D.]
    I also tried to look at v$sql, v$sql_bind_data, v$sql_bind_capture views and haven't been able to find the values.
    Thanks!

    If I run trace on oracle spatial queries, how can I get the detailed information of the bind variable value for sdo_geometry objects (the content of the sdo_geometry objects, e.g. coordinates... ) in the queries?
    For example, in the query, SRID, SDO_ELEM_INFO_ARRAY, and SDO_ORDINATE_ARRAY are bind variables. For SRID, I can find its value (number), but for sdo_elem_info_array and sdo_ordinate_array, I only got something like:
    BINDS #1:
    bind 0: dty=23 mxl=32(16) mal=00 scl=00 pre=00 oacflg=00 oacfl2=0 size=32 offset=0
    bfp=0c0521dc bln=32 avl=16 flg=05
    value=
    Dump of memory from 0xC0521DC to 0xC0521EC
    C0521D0 9E2362B1 [.b#.]
    C0521E0 479F3EB7 8B3F2BA9 A1441E4C [.>.G.+?.L.D.]
    I also tried to look at v$sql, v$sql_bind_data, v$sql_bind_capture views and haven't been able to find the values.
    Thanks!

  • About insert into MDSYS.SDO_GEOM_METADATA_TABLE

    Hi all,
    I'm newbie with Oracle Spatial.
    I would like to know what values can I define to columns SDO_LB and SDO_UB
    for the dim element for SRID 8292 when I insert into table
    MDSYS.SDO_GEOM_METADATA_TABLE.
    I found the following example:
    INSERT INTO MDSYS.SDO_GEOM_METADATA_TABLE
           SDO_OWNER, SDO_TABLE_NAME, SDO_COLUMN_NAME,
           SDO_DIMINFO,
           SDO_SRID)
    VALUES('PROJUSER', 'LOCAL', 'CD_LOCAL',
    MDSYS.SDO_DIM_ARRAY(MDSYS.SDO_DIM_ELEMENT('X', 500000, 600000, 0.05),
                        MDSYS.SDO_DIM_ELEMENT('Y', 7000000, 7020000, 0.05)),
    8292);But I don't know if this insert is correct and the spatial index
    is valid for SRID 8292.
    Thank you very much!!!
    []´s

    Hi,
    8292 is a Geographic system, so this is the correct entry for metadata:
    insert into user_sdo_geom_metadata values ( ...,
    SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05),
    SDO_DIM_ELEMENT('Y', -90, 90, .05)), 8292);
    And you should never insert directly into the MDSYS.SDO_GEOM_METADATA_TABLE table.
    You should always insert into USER_SDO_GEOM_METADATA view.
    siva

  • Sdoutl.jar WKT bug

    Hi, using the WKT class, we ran into the following issue where if you call WKT.toJGeometry() it chokes on scientific notation like this: POLYGON ((-8.2907617E8 4.2403891E8, -8.2907617E8 4.2403891E8, -8.2907617E8 4.2403891E8, -8.2907617E8 4.2403891E8, -8.2907617E8 4.2403891E8))
    <p>
    As you can see, the wkt string has scientific notation in it. This is slightly odd, since we created the wkt byte[] from the WKT class itself by using WKT.fromJGeometry()
    <p>
    This means the round-trip between WKT and JGeometry does not appear to work.
    <p>
    This is easily reproducible with the following code:
    <p>
    JGeometry jGeometry = new JGeometry(-829076170, 424038910, -829076170, 424038910, 8307);
    WKT wkt = new WKT();
    byte[] bytes = wkt.fromJGeometry(jGeometry);
    for(byte b : bytes) { System.out.print((char)b); }
    JGeometry roundTrip = wkt.toJGeometry(bytes);  // <- THROWS EXCEPTION<p>
    The stack trace is:
    <p>
    java.lang.RuntimeException: -3
         at oracle.spatial.util.WKT$WKTInputStream.readDouble(WKT.java:137)
         at oracle.spatial.util.WKBasis.readDouble(WKBasis.java:1311)
         at oracle.spatial.util.WKBasis.toJGeometry_WKB_XXXPOLYGON(WKBasis.java:1270)
         at oracle.spatial.util.WKBasis.toJGeometry_WKB_POLYGON(WKBasis.java:1218)
         at oracle.spatial.util.WKBasis.toJGeometry(WKBasis.java:937)
         at oracle.spatial.util.WKBasis.toJGeometry(WKBasis.java:894)

    While this still seems to be a bug in the WKT class, the coordinates we were using were in an int format, and we were not properly transposing them to degrees. They needed a division by 10^7, so when we do that, this problem goes away for us...however, even if the coordinates as listed are not seemingly valid earth coordinates for SRID 8307, it still seems like the WKT parser should be able to properly handle java's toString on Doubles with scientific notation.

  • SDO_PC, multiple SRIDs - best practise for data model?

    Hi,
    im using UTM and I am getting data covering two zones.
    all my existing data is from zone A.
    tables:
    pointcloud
    pointcloud_blk
    now im getting data with very few points from zone A and most points from zone B. It was agreed that the data delivery will be in SRID for zone B.
    so I tested whether this would work. I had two pointclouds. One with SRID A, another with SRID B. As soon as I put SRID B pointcloud inside, I could NO LONGER QUERY pointcloud with SRID A.
    So it seems to be necessary to use at least another pointcloud_blk, f.e. pointcloud_blk_[srid].
    Question: does another pointcloud_blk for each SRID suffice or do i also need a pointcloud table per SRID. the pointcloud table seems only interesting due to its EXTENT column. But on the other hand this could be queried by "function", since there are only 10 or so records (pointclouds) inside.
    PLZ share your best practises. What does work, what not.

    It is necessary to have one pointcloud_blk table for each SRID since there is a spatial index on that table.
    As for the PointCloud table itself, it is up to you. You can have pointclouds with different SRIDs in that table.
    But if you want to create spatial index on it, you have to use some function based index so that the index
    sees one SRID for the table.
    Since this table usually does not have many rows, this should work fine with one table for different SRIDs.
    siva

  • Where can I find a WKT for an SRID?

    Hello all!
    I want to transform a geometry from SRID 4327 (geographic 3d) to SRID 4328 (geocentric), but i get this error
    Error starting at line 1 in command:
    select sdo_cs.transform(sdo_geometry(3001, 4327, sdo_point_type(30, 50, 100), null, null), 4328) from dual
    Error report:
    SQL Error: ORA-13282: Initialisierung von Koordinatentransformation nicht erfolgreich
    ORA-06512: in "MDSYS.SDO_CS", Zeile 100
    ORA-06512: in "MDSYS.SDO_CS", Zeile 137
    ORA-06512: in "MDSYS.SDO_CS", Zeile 5266
    ORA-06512: in "MDSYS.SDO_CS", Zeile 2853
    13282. 00000 - "failure on initialization of coordinate transformation"
    *Cause:    Parsing error on source or destination coordinate system WKT, or
    incompatible coordinate systems.
    *Action:   Check the validity of the WKT for table entries, and check if the
    requested transformation is valid.
    I checked the wktext column in the mdsys.sdo_cs_srs table for the SRID 4328, it is null. Where do I get the WKT for the SRID 4328 or how can I build it?
    Yavuz
    Edited by: selim51 on Nov 9, 2008 2:02 PM

    Yes, geocentric WKTs are currently not filled in. Geocentric transformations are performed, internally, between geodetic SRIDs. However, they cannot currently serve as final transformation targets. So, at this point, filling in a WKT, manually, would not help.
    I will file this as an improvement request.
    Mike

  • SRIDs do not match for the two geometries

    When execute the program below, it return the error messages: ORA-29877,ORA-13037 and ORA-06512, can anyone tell me what happen and how to fix it, thanks.
    SQL> DECLARE
    2 geo MDSYS.SDO_GEOMETRY;
    3 BEGIN
    4 SELECT A.GEOMETRY INTO geo FROM LINE A WHERE A.ENTITYID = 1734;
    5 UPDATE LINE SET GEOMETRY = geo WHERE ENTITYID = 1733;
    6 END;
    7 /

    Hi,
    Oracle SDO 9i r.2
    I have the same errors.
    Action:
    UPDATE M0100I.TERENURIP t SET t.geoloc.sdo_srid = 262148;
    ERROR at line 1:
    ORA-29877: failed in the execution of the ODCIINDEXUPDATE routine
    ORA-13037: SRIDs do not match for the two geometries
    ORA-13037: SRIDs do not match for the two geometries
    ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 319
    ORA-06512: at "MDSYS.SDO_IDX", line 16
    ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 368
    For this table data indexed:
    CREATE INDEX "M0100I"."TERENURIP_SX"
    ON "M0100I"."TERENURIP" ("GEOLOC") INDEXTYPE IS
    MDSYS.SPATIAL_INDEX PARAMETERS (' SDO_INDX_DIMS=2
    LAYER_GTYPE="POINT" SDO_RTR_PCTFREE=2 INITIAL=64K NEXT=8192
    MINEXTENTS=1 MAXEXTENTS=2147483645 PCTINCREASE=0')
    In table user_sdo_geom_metadata for this table: "M0100I"."TERENURIP" SRID = 262148
    sdo_srid of the geometry = null
    Andrey

  • ORA-13487: SRID not found for source coordinate system metadata

    Hi,
    When executing the following
    DECLARE
    g SDO_GEORASTER;
    BEGIN
    SELECT raster INTO g FROM CADRE_AWIFS_GEORASTERS
    WHERE row_id = 3 FOR UPDATE;
    SDO_GEOR.IMPORTFROM
    g, 'SRID=8307',
    'GEOTIFF','FILE',
    '/Oracle2/usr/local/src/cadre/raster_import_orcl/BAND2.TIF'
    UPDATE CADRE_AWIFS_GEORASTERS SET raster = g
    WHERE row_id = 3;
    COMMIT;
    END;
    I get the error ORA-13487
    How can I find the SRID that's making it blow up?

    your file is geotiff, so you should remove "SRID=8307' from the storage parameter. instead, always apply blocksize.
    to find out what kind of coordinate system is inside your geotiff file, you can use many tools. if you don't have the tools, recommend listgeo.exe or gdalinfo. both are open source and can be dowloaded and installed in minutes.
    you may call sdo_cs.find_srid to search the equivalent CS in oracle spatial. or simply check the WKTEXT in the cs_srs table to find out.
    Jeffrey

  • Help! SDO_DISTANCE with 999999 SRID

    SELECT SDO_GEOM.SDO_DISTANCE(
    SDO_GEOMETRY(2001, 999999, SDO_POINT_TYPE(683644.093, 7465365.51, NULL), NULL, NULL),
    SDO_GEOMETRY(2001, 999999, SDO_POINT_TYPE(683544.093, 7465355.51, NULL), NULL, NULL),
    0.0000005, 'unit=KM') as Dist from dual
    I cannot get distance, but null. why 999999 not success?
    somebody can help me? thanks in advance
    btw, how to judge a point is in a line? e.g. the moving car (point) in which road (line)?

    hi, sorry for the poor expression here.
    select c2.linename
    from pointtable c1, linetable c2
    where c1.pointid = 108
    and SDO_RELATE(c1.GEOCOLUMN, c2.GEOCOLUMN,
    'MASK=ANYINTERACT')='TRUE';
    but it dosenot work well.
    Could you please explain what you mean by
    this?
    Does it return wrong results?
    I got nothing with this query. Nothing between the point and the line.
    Now, I use the distance, if the distance less than a threshold, I guess it's inside relationship, i.e. the moving car is in a certain road. Any better solutions?
    >>
    I want to use distance, but the point 2 linedistance
    is not reasonable (much larger than I thought)with
    the following sql:
    select c1.pointid, c2.linename,sdo_geom.sdo_distance
    (c1.STOPGEO, m1.diminfo, c2.GEOCOLUMN, m2.diminfo)
    dist
    from pointtable c1, linetable c2,
    user_sdo_geom_metadata m1, user_sdo_geom_metadatam2
    where c1.BESID = 1011
    and m1.table_name ='pointtable' and m1.column_name
    ='GEOCOLUMN'
    and m2.table_name ='linetable' and m2.column_name
    ='GEOCOLUMN'
    and rownum <= 10
    ORDER BY dist asc;
    i wanna use this for getting the top 10 closest roads for this moving point.
    now, i realize the problem it that I cannot use rownum<=10 before but after calculating distance:
    select * from (... order by disc) xx where rownum<=10
    I got the aim (linking point and road), but it's not exciting, very slow.
    I have 827330 points, and 78588 road segments.
    it's really computing expensive.
    Message was edited by:
    user646378

  • Beginner question: There is no EPSG SRID for my data.  What do I do?

    Hi, I am pretty much an absolute beginner with Oracle and Oracle Spatial. I need to use a spatial reference system that is not included by default in 11g. I have read chapter 6 of the Spatial Developers Guide but am finding it difficult to determine the correct parameters to insert into SDO_COORD_REF_SYSTEM. Can anyone help??? This is the wkt from the .prj from my shapefile.
    PROJCS("Albers Conical Equal
    Area",
    GEOGCS("GCS_North_American_1927",
    DATUM("D_North_American_1927",
    SPHEROID("Clarke_1866",6378206.4,294.9786982)),
    PRIMEM("Greenwich",0.0),
    UNIT("Degree",0.0174532925199433)),
    PROJECTION("Albers"),
    PARAMETER("False_Easting",0.0),
    PARAMETER("False_Northing",0.0),
    PARAMETER("Central_Meridian",-105.6855555555556),
    PARAMETER("Standard_Parallel_1",40.38611111111113),
    PARAMETER("Standard_Parallel_2",47.27722222222222),
    PARAMETER("Latitude_Of_Origin",37.0),
    UNIT("Meter",1.0))

    These are the steps I used. Does this look right? It seems to have worked.
    Create a projection operation 1000001
    insert into MDSYS.SDO_COORD_OPS (
    COORD_OP_ID,
    COORD_OP_NAME,
    COORD_OP_TYPE,
    SOURCE_SRID,
    TARGET_SRID,
    COORD_TFM_VERSION,
    COORD_OP_VARIANT,
    COORD_OP_METHOD_ID,
    UOM_ID_SOURCE_OFFSETS,
    UOM_ID_TARGET_OFFSETS,
    INFORMATION_SOURCE,
    DATA_SOURCE,
    SHOW_OPERATION,
    IS_LEGACY,
    LEGACY_CODE,
    REVERSE_OP,
    IS_IMPLEMENTED_FORWARD,
    IS_IMPLEMENTED_REVERSE)
    VALUES (
    1000001,
    'COE_Albers_Conical_Equal_Area',
    'CONVERSION',
    NULL,
    NULL,
    NULL,
    NULL,
    9822,
    NULL,
    NULL,
    NULL,
    NULL,
    1,
    'FALSE',
    NULL,
    1,
    1,
    1);
    Configure the projection parameters: 8821 Latitude_Of_Origin
    insert into MDSYS.SDO_COORD_OP_PARAM_VALS (
    COORD_OP_ID,
    COORD_OP_METHOD_ID,
    PARAMETER_ID,
    PARAMETER_VALUE,
    PARAM_VALUE_FILE_REF,
    UOM_ID)
    VALUES (
    1000001,
    9822,
    8821,
    37.0,
    NULL,
    9102);
    Configure the projection parameters: 8822 Central_Meridian
    insert into MDSYS.SDO_COORD_OP_PARAM_VALS (
    COORD_OP_ID,
    COORD_OP_METHOD_ID,
    PARAMETER_ID,
    PARAMETER_VALUE,
    PARAM_VALUE_FILE_REF,
    UOM_ID)
    VALUES (
    1000001,
    9822,
    8822,
    -105.6855555555556,
    NULL,
    9102);
    Configure the projection parameters: 8823 Standard_Parallel_1
    insert into MDSYS.SDO_COORD_OP_PARAM_VALS (
    COORD_OP_ID,
    COORD_OP_METHOD_ID,
    PARAMETER_ID,
    PARAMETER_VALUE,
    PARAM_VALUE_FILE_REF,
    UOM_ID)
    VALUES (
    1000001,
    9822,
    8823,
    40.38611111111113,
    NULL,
    9102);
    Configure the projection parameters: 8824 Standard_Parallel_2
    insert into MDSYS.SDO_COORD_OP_PARAM_VALS (
    COORD_OP_ID,
    COORD_OP_METHOD_ID,
    PARAMETER_ID,
    PARAMETER_VALUE,
    PARAM_VALUE_FILE_REF,
    UOM_ID)
    VALUES (
    1000001,
    9822,
    8824,
    47.27722222222222,
    NULL,
    9102);
    Configure the projection parameters: 8826 False_Easting
    insert into MDSYS.SDO_COORD_OP_PARAM_VALS (
    COORD_OP_ID,
    COORD_OP_METHOD_ID,
    PARAMETER_ID,
    PARAMETER_VALUE,
    PARAM_VALUE_FILE_REF,
    UOM_ID)
    VALUES (
    1000001,
    9822,
    8826,
    0.0,
    NULL,
    9001);
    Configure the projection parameters: 8827: False_Northing
    insert into MDSYS.SDO_COORD_OP_PARAM_VALS (
    COORD_OP_ID,
    COORD_OP_METHOD_ID,
    PARAMETER_ID,
    PARAMETER_VALUE,
    PARAM_VALUE_FILE_REF,
    UOM_ID)
    VALUES (
    1000001,
    9822,
    8827,
    0.0,
    NULL,
    9001);
    Find the GEOG_CRS_DATUM_ID:
    select datum_id from sdo_coord_ref_sys where srid = 4267;
    DATUM_ID
    6267
    Determine COORD_SYS_ID to use:
    Our units are meters so we can use 4400.
    select COORD_SYS_NAME from sdo_coord_sys where COORD_SYS_ID = 4400;
    -- Cartesian 2D CS. Axes: easting, northing (E,N). Orientations: east, north.
    -- UoM: m.
    Now create the projected CRS:
    insert into MDSYS.SDO_COORD_REF_SYSTEM (
    SRID,
    COORD_REF_SYS_NAME,
    COORD_REF_SYS_KIND,
    COORD_SYS_ID,
    DATUM_ID,
    SOURCE_GEOG_SRID,
    PROJECTION_CONV_ID,
    CMPD_HORIZ_SRID,
    CMPD_VERT_SRID,
    INFORMATION_SOURCE,
    DATA_SOURCE,
    IS_LEGACY,
    LEGACY_CODE,
    LEGACY_WKTEXT,
    LEGACY_CS_BOUNDS,
    GEOG_CRS_DATUM_ID)
    VALUES (
    1000002,
    'COE_Albers_Conical_Equal_Area',
    'PROJECTED',
    4400,
    NULL,
    4267,
    1000001,
    NULL,
    NULL,
    NULL,
    NULL,
    'FALSE',
    NULL,
    NULL,
    NULL,
    6267);
    See the result:
    select srid, wktext from cs_srs where srid = 1000002;
    PROJCS("COE_Albers_Conical_Equal_Area", GEOGCS ( "NAD27", DATUM ("North American
    Datum 1927 (EPSG ID 6267)", SPHEROID ("Clarke 1866 (EPSG ID 7008)", 6378206.4,
    294.978698213905820761610537123195175418), -3, 142, 183, 0, 0, 0, 0), PRIMEM ( "
    Greenwich", 0.000000 ), UNIT ("Decimal Degree", 0.01745329251994328)), PROJECTIO
    N ("COE_Albers_Conical_Equal_Area"), UNIT ("Meter", 1))

  • How Is sdo_geom.sdo_distance calculated in geodetic space?

    Hi,
    I'm new to oracle spatial -- but very familiar spatial SQL in Manifold GIS. In that package, there are two distance functions, a "distance", which returns the distance in native coordinates, and a "distanceEarth", which is used to return true distance (in meters) rather than degrees when working in lat/lon. When I author a basic distance query in oracle which finds the distances between all the geometries in one table and all the geometries in another table, the sgo_geom.sdo_distance will return the result in meters even when I am working in lat/lon. So when does the oracle distance function convert between degrees and meters? Is it really returning the true distance? In this clear?
    thanks!

    In Oracle Spatial, we always return the true distance based on the coordinate system
    of the geometry.
    If the geometry has lat/long values for coordinates, and appropriate SRID is set,
    we compute the true earth distance.
    If there is no SRID set for the geometry, the distance returned will be computed
    as if the long/lat values are x,y values.
    siva

Maybe you are looking for

  • E-mail messages sent, are received not in the paragraph-form as sent, but

    Dear Friends, E-mail messages sent, are received not in the paragraph-form as sent, but are broken-up into small segments, one line finely printed, the next line may appear with just two or three words printed on it, then the next line will show a fe

  • How to change colors in one picture that they will be similar to colors in other picture

    Rather big title but I couldn't find better one. I have two pictures presenting the same thing, but in different light (e.g. one is made in the morning and one in the evening). So - similar objects have different colors. How can I change the a pictur

  • Posterisation issues with DNG Profiles Editor

    I tried to tweak the Adobe Standard Beta for Nikon Coolpix 8700 profile to match the look of TIFF output of the same image from Capture NX. Though I could manage to get a perfect match of the colors (by way of around ten points in the green to red ra

  • Where is the store menu to authorize a computer?

    The tutorials say to go to the store menu and it will say "authorize this computer".  I cannot find a store menu.  I have looked everywhere that I can think of and nothing works.  iTunes is always frustrating but this is an especially frustrating exp

  • SDK configuration problem

    When installing Flex Builder 3 Beta, I installed the SDK in a non-standard location (same is true for the already installed 2.0.1 SDK from Flex Builder 2). Flex Builder 3 finds none of them. When I try to manually add them (Window->Preferences->Flex-