SDO_LRS.OFFSET_GEOM_SEGMENT

Hello folks,
Oracle EE 11gR2 w/spatial
So I have this geometry that I am working on. I am using it as a base intersection and I want to be able to offset it in pretty much any direction. The image ( A screenshot from geoRaptor ) is below:
As you can see there are nodes and links representing a typing intersection of a roadway. The arrows indicate direction of flow and the nodes ( pink doughnuts ) indicate points on which to join to other links. These links are defined as linestrings and the nodes as 2D points. This is pretty straight forward I believe.
So I have used offset_geom_segment, doing the requisite conversion to LRS and back. This all works fine. I can return a new geometry either left or right which of course follows the direction ( based upon the order of the points). So my question is this:
Am I missing something or is there an LRS or plain SDO to select either a centroid or a point within the linestring and the point geometry of the node to offset it to a complete new point and have the lats and longs adjusted in a similar fashion as the offset_geom_segment does? I understand the concept of projecting a point at a bearing & tilt so establishing a new reference point is straight forward. So am I beaing dense or just not looking deep enough? I cant seem to find a single was to "move" a geometry and have the vertices updated by the call. Do I have to manually take each point, project a new point from it then adjust? Looking for a simple way to do this.

FlyingGuy wrote:
I cant seem to find a single was to "move" a geometry and have the vertices updated by the call. Do I have to manually take each point, project a new point from it then adjust? Looking for a simple way to do this.
That's because there isn't one. Oracle never intended Spatial to be an editing tool, so editing geometries is not really part of the package. That said, it isn't that difficult: you've got your offset (or "moved") geometry, so you can simply update the the geometry it came from. That's not that difficult, is it? For a simple moving of a line or point, I think the affine transformation is a bit overkill. But something like this I don't think should be a problem:
update table t set t.geometry = sdo_lrs.offset_geom_segment(sdo_lrs.convert_to_lrs_geom(t.geometry), <whatever else offset needs>);
Mind you this is written off the top of my head, so you may need to check a few parameters and such, but I don't see why something like this couldn't work. If neccesary you can even wrap it in a small function.
HTH,
Stefan

Similar Messages

Problem with OFFSET_GEOM_SEGMENT

I'm having a problem trying to use the LRS offset segment function. Possibly I'm mis-interpreting the docs since I keep getting an incorrect ARC_TOLERANCE specification with both 10.1.0.4.0 and 10.2.0.1.0. What am I missing?
SELECT SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(
SDO_GEOMETRY(3302, 8307, NULL, SDO_ELEM_INFO_ARRAY(1,2,1),
SDO_ORDINATE_ARRAY(0,0,0, 1,1,1) ),.05) from dual;
TRUE
1 row selected.
SELECT SDO_LRS.OFFSET_GEOM_SEGMENT(
SDO_GEOMETRY(3302, 8307, NULL, SDO_ELEM_INFO_ARRAY(1,2,1),
SDO_ORDINATE_ARRAY(0,0,0, 1,1,1) ), 0, 1, -4, .05) FROM dual;
SELECT SDO_LRS.OFFSET_GEOM_SEGMENT(
ERROR at line 1:
ORA-13292: incorrect ARC_TOLERANCE specification
ORA-06512: at "MDSYS.SDO_LRS", line 6936

Ah ha... Thanks!
I didn't realize the unit parameter was not optional. The documentation is a bit misleading on this (IMHO) since it shows the units item as optional, and even gives a default (although "not" optional - not sure how you do that) tolerance parameter:
SDO_LRS.OFFSET_GEOM_SEGMENT(
geom_segment IN SDO_GEOMETRY,
start_measure IN NUMBER,
end_measure IN NUMBER,
offset IN NUMBER,
tolerance IN NUMBER DEFAULT 1.0e-8
[, unit IN VARCHAR2]
) RETURN SDO_GEOMETRY;
But... the "fine print" (that I skipped over since I didn't need to mess with units) then goes on to say:
If the input geometry is geodetic data, this parameter is required, and arc_tolerance must be specified.
Possibly for these type of sometimes optional type issues, the train-track option approach is better.
I am still left me wondering exactly what that tolerance parameter is being used for with this function...
Bryan

Offset_geom_segment

I have some code using sdo_lrs.offset_geom_segment that is producing results that I can't explain. In a nutshell, I'm just trying to offset a simple straight line in 10.2.0.3.
The first example works fine, the second with a positive offset returns a NULL geometry:
SELECT sdo_lrs.offset_geom_segment
                         (SDO_GEOMETRY (3302,
                                        8307,
                                        NULL,
                                        sdo_elem_info_array (1, 2, 1),
                                        sdo_ordinate_array (141.357782781269,
                                                            40.7192916042001,
                                                            0,
                                                            141.357801395643,
                                                            40.7192841972761,
                                                            1
                          0,
                          1,
                          -0.1524,
                          (.1524 / 8),
                          'arc_tolerance=' || (.1524 / 4)
FROM DUAL;
SELECT sdo_lrs.offset_geom_segment
                         (SDO_GEOMETRY (3302,
                                        8307,
                                        NULL,
                                        sdo_elem_info_array (1, 2, 1),
                                        sdo_ordinate_array (141.357782781269,
                                                            40.7192916042001,
                                                            0,
                                                            141.357801395643,
                                                            40.7192841972761,
                                                            1
                          0,
                          1,
                          0.1524,
                          (.1524 / 8),
                          'arc_tolerance=' || (.1524 / 4)
FROM DUAL;

Hi Brian
There seems no problem on my machine when using SQL+:
Connected to:
Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - Production
With the Partitioning, OLAP and Data Mining options
SQL> SELECT sdo_lrs.offset_geom_segment
2                           (SDO_GEOMETRY (3302,
3                                          8307,
4                                          NULL,
5                                          sdo_elem_info_array (1, 2, 1),
6                                          sdo_ordinate_array (141.357782781269,
7                                                              40.7192916042001,
8                                                              0,
9                                                              141.357801395643,
10                                                              40.7192841972761,
11                                                              1
12                                                             )
13                                         ),
14                            0,
15                            1,
16                            0.1524,
17                            (.1524 / 8),
18                            'arc_tolerance=' || (.1524 / 4)
19                           )
20    FROM DUAL;
SDO_LRS.OFFSET_GEOM_SEGMENT(SDO_GEOMETRY(3302,8307,NULL,SDO_ELEM_INFO_ARRAY(1,2,
SDO_GEOMETRY(3302, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(
141.357784, 40.7192928, 0, 141.357802, 40.7192854, 1))
SQL> SELECT sdo_lrs.offset_geom_segment
2                           (SDO_GEOMETRY (3302,
3                                          8307,
4                                          NULL,
5                                          sdo_elem_info_array (1, 2, 1),
6                                          sdo_ordinate_array (141.357782781269,
7                                                              40.7192916042001,
8                                                              0,
9                                                              141.357801395643,
10                                                              40.7192841972761,
11                                                              1
12                                                             )
13                                         ),
14                            0,
15                            1,
16                            -0.1524,
17                            (.1524 / 8),
18                            'arc_tolerance=' || (.1524 / 4)
19                           )
20    FROM DUAL;
SDO_LRS.OFFSET_GEOM_SEGMENT(SDO_GEOMETRY(3302,8307,NULL,SDO_ELEM_INFO_ARRAY(1,2,
SDO_GEOMETRY(3302, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(
141.357782, 40.7192904, 0, 141.357801, 40.719283, 1)) However, when trying this through SQL developer interface, SQL developer hangs.
Luc
Edited by: lucvanlinden on Feb 19, 2009 8:52 AM
Edited by: lucvanlinden on Feb 19, 2009 8:54 AM

Mapviewer, parallel lines and custom rendering

I have been scratching my head a bit on this:
We have some databases which contains various types of water/sewer-pipes. These lines (pipes) has an attribute connected to them, which describes displacement and ranges from -3 to 3 (where a "normal" centered lines is 0).
Since we are very interested in the mapviewer WMS-feature, and want to render the map just the way we do in our apps, I am wondering, is there some way I can implement "server-logic" to apply displacement to the lines according to the displacement-attribute ?
Thanks in advance,
Oyvind

Oyvind
You could use a view that references the original geometry (or just store it back in the same table in a different column), offsetting it to one side or the other using the LRS functions.
First, youll have to add an LRS value (unless you already have them) using SDO_LRS.CONVERT_TO_LRS_GEOM. Start and End could be 0 and 1.
Then offest that LRS geometry using SDO_LRS.OFFSET_GEOM_SEGMENT.
Then remove the LRS items (unless that doesnt make any difference in your app):
CREATE OR REPLACE VIEW corrected_pipedata
(geom)
AS
SELECT SDO_LRS.CONVERT_TO_STD_GEOM( SDO_LRS.OFFSET_GEOM_SEGMENT( SDO_LRS.CONVERT_TO_LRS_GEOM(a.in_geom, 0, 1),
0, 1,
a.in_offset))
FROM pipedata a
Example:
SELECT geometry_l from c_path_segment WHERE rownum < 2;SDO_GEOMETRY(3002, 8307, *, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(-80.5460927551392, 28.4766171261354, 0, -80.5460869608106, 28.4766337523028, 0))
SELECT SDO_LRS.CONVERT_TO_STD_GEOM(SDO_LRS.OFFSET_GEOM_SEGMENT( SDO_LRS.CONVERT_TO_LRS_GEOM(a.geometry_l, 0, 1),0, 1,
-1 ,
0.005,
'unit=meter arc_tolerance=0.05'))
FROM c_path_segment a
WHERE rownum < 2;
SDO_GEOMETRY(3002, 8307, *, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(-80.5460833610681, 28.4766140113997, 0, -80.5460829955615, 28.4766144706575, 0, -80.546077201
2316, 28.4766310968245, 0))
SELECT SDO_LRS.CONVERT_TO_STD_GEOM(SDO_LRS.OFFSET_GEOM_SEGMENT( SDO_LRS.CONVERT_TO_LRS_GEOM(a.geometry_l, 0, 1),0, 1,
1 ,
0.005,
'unit=meter arc_tolerance=0.05'))
FROM c_path_segment a
WHERE rownum < 2;
SDO_GEOMETRY(3002, 8307, *, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(-80.5461024997426, 28.4766189245689, 0, -80.5461025147173, 28.4766197816126, 0, -80.546096720
3901, 28.4766364077804, 0, -80.546096182864, 28.4766370831801, 0))

Oracle spatial query SDO_LRS with php

Hello, I have this problem,
I use php for read data from oracle table.
I know I can't show on web page the result of SDO_ORDINATE_ARRAY
Christopher Jones has written that I must use SDO_UTIL.GETVERTICES like as
select
t.X,
t.Y
from table_a, TABLE(SDO_UTIL.GETVERTICES(table_a.GEOMETRY_1)) t
where
id_num = 970;
But now I must read a projection point ordinate of a point with respect to a geometric segment
and the same problem come back.
esemple of spatial query that I use:
SELECT
SDO_LRS.PROJECT_PT(geometry,
SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY(580094.69, 4998493.68, NULL)) )
FROM
TABLE_B
WHERE
ID_CODE = 970;
If I use sql plus I have this result
SDO_LRS.PROJECT_PT(GEOMETRY,SD(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM
SDO_GEOMETRY(3301, NULL, NULL, SDO_ELEM_INFO_ARRAY(1, 1, 1), SDO_ORDINATE_ARRAY(
580093,325, 4998497,57, 45,2254405))
Which is exacly the query for extract these coordinates?
Someone can help me?
My English is very bad please reply easy.
Thanks for all!
Angelo

Hello thanks for all to everyboby.
I put the same question on Forum /Category/Database/Spatial and I have received this reply
from Brian Camire, this query worked well.
SELECT
T.X,
T.Y
FROM
TABLE
SELECT
SDO_UTIL.GETVERTICES
SDO_LRS.PROJECT_PT
GEOMETRY,
SDO_GEOMETRY
3301,
NULL,
NULL,
SDO_ELEM_INFO_ARRAY(1, 1, 1),
SDO_ORDINATE_ARRAY(580093.859, 4998493.5, NULL)
FROM
TABLE_B
WHERE
ID_CODE = 970
) T;
Best regards
Angelo.

How to find a line/edge that starts at the same point as the end of another

I have an edges table of Lat/Lon data and for a specific edge I want to find any other edges that have the same start point as the end point of the given edge.
I tried the following query:
select geo_street_id from geo_street s2
where SDO_LRS.GEOM_SEGMENT_START_PT(s2.geom) =
(select SDO_LRS.GEOM_SEGMENT_END_PT(s.geom) as geom from geo_street s
where geo_street_id = 122978214)
but it gets the following error:
ORA-22901: cannot compare nested table or VARRAY or LOB attributes of an object type
Any Ideas?

1. to compare geometry to be equal you should use appropriate function (SDO_GEOM.RELATE http://download.oracle.com/docs/html/B14255_01/sdo_objgeom.htm#sthref1561) or operators (sdo_relate http://download.oracle.com/docs/html/B14255_01/sdo_operat.htm#i78531) with specific mask EQUAL.
2. to filter down the resultset in first place you can use the operator SDO_RELATE with mask TOUCH as this will return already the set of lines sharing endpoints, but will also include lines touching eachother not at endpoints (endpoint intersecting the otherone's interior)
something like
select geo_street_id from geo_street s2, geo_street s
where
s.geo_street_id = 122978214
AND
sdo_relate(s2.geom, s.geom,'mask=touch') = 'TRUE'
AND
sdo_geom.relate(SDO_LRS.GEOM_SEGMENT_START_PT(s2.geom),
'EQUAL',
SDO_LRS.GEOM_SEGMENT_END_PT(s.geom),0.005)='EQUAL'
3. if you would do this for the full table, an SDO_JOIN (http://download.oracle.com/docs/html/B14255_01/sdo_operat.htm#BGEDJIBF) might be more appropriate.
4. you might also consider 4 cases:
start = start
start = end
end = start
end = end
5. alternative would be to take only the endpoints of your selected geometry and perform a touch with the edges. using the sdo_util.APPEND on the startpoint en endpoint of your geometry will return a multipoint. although there might some specific cases that this would not return respected result I think
something like:
select geo_street_id from geo_street s2, geo_street s
where
s.geo_street_id = 122978214
AND
sdo_relate(s2.geom,
SDO_UTIL.APPEND(
SDO_LRS.GEOM_SEGMENT_START_PT(s.geom),
SDO_LRS.GEOM_SEGMENT_END_PT(s.geom)
,'mask=touch') = 'TRUE'
Let us know how it works.
Luc

How to find a second point on a line given a point and distance

Hi All,
My requirement is: Given a point on a line and distance, I have to find the second point. All geometries are in LRS.
I tried using SDO_LRS.LOCATE_PT, it is returning the second point from the start of the segment but I want to locate the point from the given start point. Kindly suggest in how to solve this.
SQL Used:
SELECT SDO_LRS.LOCATE_PT(a.shape, m.diminfo, 9, 0)
FROM lrs_access_fiber a, user_sdo_geom_metadata m
WHERE m.table_name = 'LRS_ACCESS_FIBER' AND m.column_name = 'SHAPE' AND a.unique_id = 1996;
Regards
Venkat

Hi Luc,
Thanks for the information. I have implemented this in a slightly different way like:
1. Firstly, found the distance (Distance_a of the point selected from the start point of the segment using:
SELECT SDO_LRS.GET_MEASURE(SDO_LRS.PROJECT_PT(a.shape, m.diminfo,MDSYS.SDO_GEOMETRY(2301, 8307, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 1, 1), MDSYS.SDO_ORDINATE_ARRAY(xa,ya, NULL)) ), m.diminfo ) into Distance_a FROM LRS_ACCESS_FIBER a, user_sdo_geom_metadata m WHERE m.table_name = 'LRS_ACCESS_FIBER' AND m.column_name = 'SHAPE' AND a.unique_id = Input_Fiber_Id;
2. Then added the given distance (b) to this computed distance (Distance_a ) to get the distance of the second point (Distance_b).
Distance_b := abs (Distance_a + b);
3. Then used SDO_LRS.LOCATE_PT with offset=0 and distance=Distance_b to get the second point.
select SDO_LRS.LOCATE_PT(a.shape, distance_pt, 0) into point_geometry from LRS_ACCESS_FIBER a where a.unique_id = input_fiber_id;
Please give your inputs and feedback.
Regards
Venkat

How to create geofence at the start of a geometry segment?

I want to create a geofence at the start (and end) of each of our road sections.
The geofence would extend exactly x(specified) metres at right angles to the segment direction at the start point.
Is there any Oracle functionality to construct a line (or 2 points) at right angles to a point on a line?
I can find the start point using this construction
SELECT SDO_LRS.GEOM_SEGMENT_START_PT(geom)
FROM ROAD_CENTRELINE_SDO WHERE id = 82;
The only way I have found of creating the geometry is by using some trigonometry to calculate the angle subtended and create two equidistant points. This is rather clumsy and I wondered if anyone knew how to do this more efficiently using Oracle Spatial functionality.
Philip

Phil,
I can understand that you found the packages complex. There is quite a bit of work gone into them over the years. Once you are over the install, and grow in your understanding of Spatial, you might find one or two of the functions quite useful. I am working on documentation... not enough hours in the day!
Wrt you immediate question.
Assuming that these two queries return the points you need:
SELECT SDO_LRS.LOCATE_PT(a.geom, 0, -7) FROM ROAD_CENTRELINE_SDO a
SELECT SDO_LRS.LOCATE_PT(a.geom, 0, 7) FROM ROAD_CENTRELINE_SDO a
Then, because these functions return a point in the sdo_ordinate_array and not in SDO_POINT, you should be able to construct a line as follows:
SELECT sdo_geometry(2002,l.SRID,NULL,sdo_elem_info_array(1,2,1),
       sdo_ordinate_array(l.column_value.x,l.column_value.y,
                          r.column_value.x,r.column_value.y))
FROM ( SELECT a.ID, a.geom.sdo_srid as srid, b.*
           FROM ROAD_CENTRELINE_SDO a,
                TABLE( SDO_UTIL.GET_VERTICES( SDO_LRS.LOCATE_PT(a.geom,0,-7) ) )
       ) l,
       ( SELECT c.ID, c.geom.sdo_srid as srid, d.*
           FROM ROAD_CENTRELINE_SDO c,
                TABLE( SDO_UTIL.GET_VERTICES( SDO_LRS.LOCATE_PT(c.geom,0, 7) ) )
       ) r
WHERE r.id = l.id;I have not tested this as I do not have an operational LRS in place but it should work. Of course, if the SDO_LRS.LOCATE_PT returned the data in an sdo_point structure all this complexity could be avoided. But this approach does not require the construction of a function that returns an sdo_point from an sdo_geometry with a point coded in sdo_ordinate_array (which would be result in nicer SQL). If you coded a function that did this:
create or replace Function ToSdoPoint( p_geometry IN MDSYS.SDO_GEOMETRY )
    RETURN MDSYS.SDO_GEOMETRY DETERMINISTIC
    IS
     v_element         number;
     v_elements        number;
     v_geometry        MDSYS.SDO_Geometry;
     v_SdoPoint        MDSYS.SDO_Point_Type := MDSYS.SDO_Point_Type(0,0,NULL);
     v_Ordinates       MDSYS.SDO_Ordinate_Array;
Begin
    IF ( MOD(p_geometry.sdo_gtype,10) not in (1,5) ) Then
      v_geometry := NULL;
    ELSIF p_geometry.sdo_point is not null THEN
      v_geometry := mdsys.sdo_geometry(p_geometry.sdo_gtype,p_geometry.sdo_srid,p_geometry.sdo_point,NULL,NULL);
    ELSE
      v_ordinates := p_geometry.sdo_ordinates;
      v_SdoPoint.X := v_ordinates(1);
      v_SdoPoint.Y := v_ordinates(2);
      IF ( FLOOR(p_geometry.sdo_gtype/1000) = 3 ) THEN
        v_SdoPoint.Z := v_ordinates(3);
      END IF;
      v_geometry := mdsys.sdo_geometry(p_geometry.sdo_gtype,p_geometry.sdo_srid,v_SdoPoint,NULL,NULL);
    END IF;
    RETURN v_geometry;
END ToSdoPoint;
show errors
select toSdoPoint(mdsys.sdo_geometry(2001,null,null,
                   sdo_elem_info_array(1,2,1),sdo_ordinate_array(1,2)))
from dual;Then the SQL becomes:
SELECT sdo_geometry(2002,SRID,NULL,sdo_elem_info(1,2,1),
       sdo_ordinate_array(left.x,left.y, right.x,right.y)) as geom
FROM ( SELECT a.geom.sdo_srid as srid,
               ToSdoPoint(SDO_LRS.LOCATE_PT(a.geom, 0, -7)) as left,
               ToSdoPoint(SDO_LRS.LOCATE_PT(a.geom, 0, 7)) as right
           FROM ROAD_CENTRELINE_SDO a )Hope this helps.
regards
Simon

Rebuilding spatial indexing fail after patch 9.2.0.8.0

Hi!
I did apply patchset, and after i did try to
set NLS_LANG=American_America.CL8MSWIN1251
sqlplusw ......
SQL> alter index XXXX.YYYYYYYY_g_idx rebuild; -- <- Russian name
alter index XXXX.YYYYYYYY_g_idx rebuild
ERROR at line 1:
ORA-29858: error occurred in the execution of ODCIINDEXALTER routine
ORA-29400: data cartridge error
¡a¤
ORA-13249: internal error in Spatial index: [mdidxrbd]
ORA-13205: internal error while parsing spatial parameters
ORA-06512: at "MDSYS.SDO_INDEX_METHOD_9I", line 259
ORA-06512: at line 1
As you can see, rebuilding was failed.
Before upgrade all did work fine.
If i will create table WITH_ENGLISH_NAME as SELECT from my table all working fine ;(
I DID apply all *.sql from patchset.
Any idea, gurus ?
P.S.
I did use script from metalink
verify_spatial_installation.sql :
SQL>
SQL> prompt Verify version and status
Verify version and status
SQL> select COMP_NAME, SCHEMA, VERSION, STATUS
2 from dba_registry where comp_id='SDO';
COMP_NAME SCHEMA VERSION STATUS
Spatial MDSYS 9.2.0.8.0 VALID
SQL>
SQL> prompt Number of objects
Number of objects
SQL> select count(*)
2 from dba_objects where owner='MDSYS';
COUNT(*)
250
SQL>
SQL> prompt Summary count of objects
Summary count of objects
SQL> select object_type, count(*)
2 from dba_objects where owner='MDSYS'
3 group by object_type;
OBJECT_TYPE COUNT(*)
FUNCTION 47
INDEX 17
INDEXTYPE 2
LIBRARY 12
LOB 12
OPERATOR 14
PACKAGE 25
PACKAGE BODY 25
SEQUENCE 2
TABLE 18
TRIGGER 7
TYPE 34
TYPE BODY 10
VIEW 25
14 rows selected.
SQL>
SQL> prompt Any invalid objects ?
Any invalid objects ?
SQL> select object_name, object_type, status
2 from dba_objects
3 where owner='MDSYS'
4 and status <> 'VALID'
5 order by object_name;
OBJECT_NAME OBJECT_TYPE STATUS
SDO_MIGRATE PACKAGE BODY INVALID
SQL>
SQL> prompt List of all spatial objects ordered by object_name
List of all spatial objects ordered by object_name
SQL> select object_name, object_type, status
2 from dba_objects where owner='MDSYS'
3 order by object_name;
OBJECT_NAME OBJECT_TYPE STATUS
AGGRCENTROID TYPE VALID
AGGRCENTROID TYPE BODY VALID
AGGRCONVEXHULL TYPE VALID
AGGRCONVEXHULL TYPE BODY VALID
AGGRLRSCONCAT TYPE VALID
AGGRLRSCONCAT TYPE BODY VALID
AGGRLRSCONCAT3D TYPE VALID
AGGRLRSCONCAT3D TYPE BODY VALID
AGGRMBR TYPE VALID
AGGRMBR TYPE BODY VALID
AGGRUNION TYPE VALID
AGGRUNION TYPE BODY VALID
ALL_GEOMETRY_COLUMNS VIEW VALID
ALL_SDO_GEOM_METADATA VIEW VALID
ALL_SDO_INDEX_INFO VIEW VALID
ALL_SDO_INDEX_METADATA VIEW VALID
ALL_SDO_LRS_METADATA VIEW VALID
ALL_SDO_MAPS VIEW VALID
ALL_SDO_STYLES VIEW VALID
ALL_SDO_THEMES VIEW VALID
CS_SRS TABLE VALID
DBA_GEOMETRY_COLUMNS VIEW VALID
DBA_SDO_INDEX_INFO VIEW VALID
DBA_SDO_INDEX_METADATA VIEW VALID
DBA_SDO_LRS_METADATA VIEW VALID
DBA_SDO_MAPS VIEW VALID
DBA_SDO_STYLES VIEW VALID
DBA_SDO_THEMES VIEW VALID
F81_INDEX_OBJECT TYPE VALID
F81_INDEX_OBJ_ARRAY TYPE VALID
F81_NT_IND_TYPE TYPE VALID
GEOCODER_HTTP PACKAGE VALID
GEOCODER_HTTP PACKAGE BODY VALID
GEOCODE_RESULT TYPE VALID
GEODETIC_SRIDS VIEW VALID
H81_INDEX_OBJECT TYPE VALID
H81_INDEX_OBJ_ARRAY TYPE VALID
H81_NT_IND_TYPE TYPE VALID
HHAND FUNCTION VALID
HHBYTELEN FUNCTION VALID
HHCBIT FUNCTION VALID
HHCELLBNDRY FUNCTION VALID
HHCELLSIZE FUNCTION VALID
HHCLDATE FUNCTION VALID
HHCOLLAPSE FUNCTION VALID
HHCOMMONCODE FUNCTION VALID
HHCOMPARE FUNCTION VALID
HHCOMPOSE FUNCTION VALID
HHDECODE FUNCTION VALID
HHDISTANCE FUNCTION VALID
HHENCODE FUNCTION VALID
HHENCODE_BYLEVEL FUNCTION VALID
HHGBIT FUNCTION VALID
HHGETCID FUNCTION VALID
HHGROUP FUNCTION VALID
HHGTBIT FUNCTION VALID
HHGTYPE FUNCTION VALID
HHIDLPART FUNCTION VALID
HHIDPART FUNCTION VALID
HHINCRLEV FUNCTION VALID
HHJLDATE FUNCTION VALID
HHLENGTH FUNCTION VALID
HHLEVELS FUNCTION VALID
HHMATCH FUNCTION VALID
HHMAXCODE FUNCTION VALID
HHNCOMPARE FUNCTION VALID
HHNDIM FUNCTION VALID
HHOR FUNCTION VALID
HHORDER FUNCTION VALID
HHPRECISION FUNCTION VALID
HHSBIT FUNCTION VALID
HHSETCID FUNCTION VALID
HHSTBIT FUNCTION VALID
HHSTYPE FUNCTION VALID
HHSUBDIVIDE FUNCTION VALID
HHSUBSTR FUNCTION VALID
HHXOR FUNCTION VALID
LOCATOR_WITHIN_DISTANCE OPERATOR VALID
MD PACKAGE VALID
MD PACKAGE BODY VALID
MD$RELATE TABLE VALID
MD1 PACKAGE VALID
MD1 PACKAGE BODY VALID
MD2 PACKAGE VALID
MD2 PACKAGE BODY VALID
MDERR PACKAGE VALID
MDERR PACKAGE BODY VALID
MDPRVT_IDX PACKAGE VALID
MDPRVT_IDX PACKAGE BODY VALID
MD_LRS PACKAGE VALID
MD_LRS PACKAGE BODY VALID
OGIS_GEOMETRY_COLUMNS TABLE VALID
OGIS_SPATIAL_REFERENCE_SYSTEMS TABLE VALID
ORDMD_AG_LIBS LIBRARY VALID
ORDMD_CS_LIBS LIBRARY VALID
ORDMD_IDX_LIBS LIBRARY VALID
ORDMD_LRS_LIBS LIBRARY VALID
ORDMD_MBR_LIBS LIBRARY VALID
ORDMD_MIG_LIBS LIBRARY VALID
ORDMD_PRIDX_LIBS LIBRARY VALID
ORDMD_REL_LIBS LIBRARY VALID
ORDMD_RTREE_LIBS LIBRARY VALID
ORDMD_UDT_LIBS LIBRARY VALID
ORDMD_UTL_LIBS LIBRARY VALID
ORDMD_WD_LIBS LIBRARY VALID
PK_SDO_MASK INDEX VALID
PK_SRID INDEX VALID
PRVT_IDX PACKAGE VALID
PRVT_IDX PACKAGE BODY VALID
RTREE_FILTER OPERATOR VALID
RTREE_IDX PACKAGE VALID
RTREE_IDX PACKAGE BODY VALID
RTREE_INDEX INDEXTYPE VALID
RTREE_INDEX_METHOD TYPE VALID
RTREE_INDEX_METHOD TYPE BODY VALID
RTREE_NN OPERATOR VALID
SAMPLE_SEQ SEQUENCE VALID
SDO PACKAGE VALID
SDO PACKAGE BODY VALID
SDOAGGR TYPE VALID
SDOAGGR TYPE BODY VALID
SDOAGGRTYPE TYPE VALID
SDO_3GL PACKAGE VALID
SDO_3GL PACKAGE BODY VALID
SDO_ADMIN PACKAGE VALID
SDO_ADMIN PACKAGE BODY VALID
SDO_AGGR_CENTROID FUNCTION VALID
SDO_AGGR_CONVEXHULL FUNCTION VALID
SDO_AGGR_LRS_CONCAT FUNCTION VALID
SDO_AGGR_LRS_CONCAT_3D FUNCTION VALID
SDO_AGGR_MBR FUNCTION VALID
SDO_AGGR_UNION FUNCTION VALID
SDO_ANGLE_UNITS TABLE VALID
SDO_AREA_UNITS TABLE VALID
SDO_CATALOG PACKAGE VALID
SDO_CATALOG PACKAGE BODY VALID
SDO_CONSTRUCT_DIM_ARRAY FUNCTION VALID
SDO_CS PACKAGE VALID
SDO_CS PACKAGE BODY VALID
SDO_DATUMS TABLE VALID
SDO_DIM_ARRAY TYPE VALID
SDO_DIM_ELEMENT TYPE VALID
SDO_DIST_UNITS TABLE VALID
SDO_DROP_USER TRIGGER VALID
SDO_ELEM_INFO_ARRAY TYPE VALID
SDO_ELLIPSOIDS TABLE VALID
SDO_FILTER OPERATOR VALID
SDO_GEOM PACKAGE VALID
SDO_GEOM PACKAGE BODY VALID
SDO_GEOMETRY TYPE VALID
SDO_GEOMETRY TYPE BODY VALID
SDO_GEOM_IDX INDEX VALID
SDO_GEOM_METADATA_TABLE TABLE VALID
SDO_GEOM_TRIG_DEL1 TRIGGER VALID
SDO_GEOM_TRIG_INS1 TRIGGER VALID
SDO_GEOM_TRIG_UPD1 TRIGGER VALID
SDO_IDX PACKAGE VALID
SDO_IDX PACKAGE BODY VALID
SDO_IDX_MDATA_IDX INDEX VALID
SDO_IDX_TAB_SEQUENCE SEQUENCE VALID
SDO_INDEX_METADATA_TABLE TABLE VALID
SDO_INDEX_METHOD_9I TYPE VALID
SDO_INDEX_METHOD_9I TYPE BODY VALID
SDO_INT2_FILTER OPERATOR VALID
SDO_INT2_RELATE OPERATOR VALID
SDO_INT_FILTER OPERATOR VALID
SDO_INT_RELATE OPERATOR VALID
SDO_LRS PACKAGE VALID
SDO_LRS PACKAGE BODY VALID
SDO_LRS_METADATA_TABLE TABLE VALID
SDO_LRS_META_IDX INDEX VALID
SDO_LRS_TRIG_DEL TRIGGER VALID
SDO_LRS_TRIG_INS TRIGGER VALID
SDO_LRS_TRIG_UPD TRIGGER VALID
SDO_MAPS_TABLE TABLE VALID
SDO_MBR TYPE VALID
SDO_META PACKAGE VALID
SDO_META PACKAGE BODY VALID
SDO_MIGRATE PACKAGE VALID
SDO_MIGRATE PACKAGE BODY INVALID
SDO_NN OPERATOR VALID
SDO_NN_DISTANCE OPERATOR VALID
SDO_NUMTAB TYPE VALID
SDO_ORDINATE_ARRAY TYPE VALID
SDO_POINT_TYPE TYPE VALID
SDO_PRIDX PACKAGE VALID
SDO_PRIDX PACKAGE BODY VALID
SDO_PROJECTIONS TABLE VALID
SDO_RELATE OPERATOR VALID
SDO_RELATEMASK_TABLE VIEW VALID
SDO_RELATE_MASK PACKAGE VALID
SDO_RELATE_MASK PACKAGE BODY VALID
SDO_RID_ARRAY TYPE VALID
SDO_RTREE_ADMIN PACKAGE VALID
SDO_RTREE_ADMIN PACKAGE BODY VALID
SDO_RTREE_FILTER OPERATOR VALID
SDO_RTREE_RELATE OPERATOR VALID
SDO_STAT TYPE VALID
SDO_STATTAB TYPE VALID
SDO_STYLES_TABLE TABLE VALID
SDO_THEMES_IDX INDEX VALID
SDO_THEMES_TABLE TABLE VALID
SDO_TUNE PACKAGE VALID
SDO_TUNE PACKAGE BODY VALID
SDO_UTIL PACKAGE VALID
SDO_UTIL PACKAGE BODY VALID
SDO_VERSION FUNCTION VALID
SDO_VPOINT_TYPE TYPE VALID
SDO_WITHIN_DISTANCE OPERATOR VALID
SPATIAL_INDEX INDEXTYPE VALID
SYS_C001565 INDEX VALID
SYS_C001571 INDEX VALID
SYS_C001706 INDEX VALID
SYS_LOB0000027008C00040$$ LOB VALID
SYS_LOB0000027008C00041$$ LOB VALID
SYS_LOB0000027053C00012$$ LOB VALID
SYS_LOB0000027053C00013$$ LOB VALID
SYS_LOB0000027209C00004$$ LOB VALID
SYS_LOB0000027216C00005$$ LOB VALID
SYS_LOB0000027216C00006$$ LOB VALID
SYS_LOB0000027216C00013$$ LOB VALID
SYS_LOB0000027216C00014$$ LOB VALID
SYS_LOB0000027229C00006$$ LOB VALID
SYS_LOB0000028651C00012$$ LOB VALID
SYS_LOB0000028651C00013$$ LOB VALID
TRANSFORM_MAP PACKAGE VALID
TRANSFORM_MAP PACKAGE BODY VALID
UNIQUE_ANGLE_UNITS INDEX VALID
UNIQUE_AREA_UNITS INDEX VALID
UNIQUE_DIST_UNITS INDEX VALID
UNIQUE_LAYERS INDEX VALID
UNIQUE_MAPS INDEX VALID
UNIQUE_STYLES INDEX VALID
UNIQUE_TABLES INDEX VALID
UNIQUE_THEMES INDEX VALID
USER_CS_SRS TABLE VALID
USER_GEOMETRY_COLUMNS VIEW VALID
USER_SDO_GEOM_METADATA VIEW VALID
USER_SDO_INDEX_INFO VIEW VALID
USER_SDO_INDEX_METADATA VIEW VALID
USER_SDO_LRS_METADATA VIEW VALID
USER_SDO_MAPS VIEW VALID
USER_SDO_STYLES VIEW VALID
USER_SDO_THEMES VIEW VALID
USER_TRANSFORM_MAP TABLE VALID
V81_INDEX_OBJECT TYPE VALID
V81_INDEX_OBJ_ARRAY TYPE VALID
V81_NT_IND_TYPE TYPE VALID
VERTEX_SET_TYPE TYPE VALID
VERTEX_TYPE TYPE VALID
250 rows selected.
SQL>
SQL> spool off

Sir! No Sir! :)
I will try to explain.
If I do have table with russian letter, than creating index creation will fail, no matter name of index :(
But if I will prepare copy of my table with english name (including meta-data) - index creations is succesfull.

Can't show Greate Circle Route (in SRID 8307) in Map Viewer

I've got a task to show flight tracks on the world map in Map Viewer.
I've got a table with appropriate geometry
INSERT INTO USER_SDO_GEOM_METADATA (TABLE_NAME, COLUMN_NAME, DIMINFO, SRID) VALUES (
'TMP_LEG_ARC_001', 'LEG_GEOM',
SDO_DIM_ARRAY(
SDO_DIM_ELEMENT('LONG', -180.0, 180.0, 0.05),
SDO_DIM_ELEMENT('LAT', -90.0, 90.0, 0.05)
8307);
I've got a theme created from this column. It's evident that flights (and any other straight lines on the earth surface) should look like arcs but in MapViwer I can see straight lines.
It looks like Map Viewer just projected ends of line on the map and then draw straight line between them, instead of projecting whole line on the map (which should be converted into arc)
What have I done wrong?!
Edited by: Wishmaster on 08.11.2012 21:38

MapViewer doesn't display them as great circles. This will be fixed in a future release.
Meanwhile you can use Oracle Spatial functions to create the sissified lines which will approximate/be displayed as flight paths/great circles.
That is use something like Dan Geringer's (sample code so usual disclaimers apply) densify_line plsql stored procedure below.
The densify_line function takes two arguments:
• two_pt_line - The line to densify
• arc_tolerance - The interval (in meters) used to densify the line
The first argument calls for a two point line. It ensures the endpoints are included in the densified result.
You can also pass in a linestring with more than two points. The end points are ensured to be part of the densified line, but the intermediate shape points are not. To guarantee shape points, you can call densify_line iteratively with the 2 point line segments of a linestring.
CREATE OR REPLACE FUNCTION densify_line (two_pt_line MDSYS.SDO_GEOMETRY,
arc_tolerance number) RETURN MDSYS.SDO_GEOMETRY
DETERMINISTIC IS
lrs_segment MDSYS.SDO_GEOMETRY;
new_point MDSYS.SDO_GEOMETRY;
densified_line MDSYS.SDO_GEOMETRY := mdsys.sdo_geometry (two_pt_line.sdo_gtype,
two_pt_line.sdo_srid,
null,
mdsys.sdo_elem_info_array (1,2,1),
mdsys.sdo_ordinate_array ());
curr_measure NUMBER;
times_to_loop NUMBER;
BEGIN
IF two_pt_line IS NOT NULL
THEN
densified_line.sdo_ordinates.extend(2);
densified_line.sdo_ordinates(1) := two_pt_line.sdo_ordinates(1);
densified_line.sdo_ordinates(2) := two_pt_line.sdo_ordinates(2);
lrs_segment := SDO_LRS.CONVERT_TO_LRS_GEOM (two_pt_line);
times_to_loop := FLOOR (lrs_segment.sdo_ordinates(lrs_segment.sdo_ordinates.count) / arc_tolerance);
curr_measure := 0;
FOR i IN 1 .. times_to_loop LOOP
curr_measure := curr_measure + arc_tolerance;
densified_line.sdo_ordinates.extend(2);
new_point := sdo_lrs.locate_pt (lrs_segment, curr_measure);
densified_line.sdo_ordinates(densified_line.sdo_ordinates.count-1) := new_point.sdo_ordinates(1);
densified_line.sdo_ordinates(densified_line.sdo_ordinates.count) := new_point.sdo_ordinates(2);
END LOOP;
IF curr_measure < lrs_segment.sdo_ordinates(lrs_segment.sdo_ordinates.count)
THEN
densified_line.sdo_ordinates.extend(2);
densified_line.sdo_ordinates(densified_line.sdo_ordinates.count - 1) :=
two_pt_line.sdo_ordinates(two_pt_line.sdo_ordinates.count - 1);
densified_line.sdo_ordinates(densified_line.sdo_ordinates.count) :=
two_pt_line.sdo_ordinates(two_pt_line.sdo_ordinates.count);
END IF;
END IF;
RETURN densified_line;
END;
/

Extracting x,y co-ordinates of SDO_GEOMETRY into two variables say x1, ya

Hi All,
I am able to store the output SDO_GEOMETRY into a variable but i am facing difficulties in extracting ordinates in sdo_geometry to two independent variables say xa, ya. Kindly suggest some solution.
The procedure is as follows:
CREATE OR REPLACE PROCEDURE fnd_2nd_Point
(Input_Fiber_Id IN NUMBER,
xa IN FLOAT,
ya IN FLOAT,
Length_Fiber IN FLOAT,
Result OUT VARCHAR,
xCordInAte OUT FLOAT,
yCordInAte OUT FLOAT)
IS
ProjPoint_a mdsys.sDo_Geometry := NULL;
v_Point_xa FLOAT := NULL;
v_Point_ya FLOAT := NULL;
BEGIN
SELECT sDo_lrs.Project_pt(a.Shape,m.DimInfo,mdsys.Sdo_geometry(2001,8307,NULL,mdsys.Sdo_elem_info_array(1,1,1),
mdsys.Sdo_ordinate_array(xa,ya,Length_Fiber)))
INTO {color:#0000ff}ProjPoint_a
{color}FROM lrs_Access_Fiber a,
User_sDo_geom_MetAdAta m
WHERE m.Table_Name = 'LRS_ACCESS_FIBER'
AND m.Column_Name = 'SHAPE'
AND a.Unique_Id = Input_Fiber_Id;
{color:#0000ff}-- SELECT t.x, t.y INTO v_Point_xa, v_Point_ya FROM TABLE(sDo_util.Getvertices(ProjPoint_a)) t;
{color}
{color:#0000ff}-- dbms_Output.Put_Line('Point Xa is ' ||v_Point_xa||' and point Ya is '||v_Point_ya);
{color}
{color:#0000ff}-- xCordInAte := v_Point_xa;
{color}
{color:#0000ff}-- yCordInAte := v_Point_ya;
{color}
-- Result := 'success';
END;
Kindly advice on the options available to extract the ordinates of sdo_geometry into 2 independent variables.
Regards,
Venkat

Please find the output as below for the following inputs: INPUT_FIBER_ID :=2005; XA := 78.424; YA := 17.643; LENGTH_FIBER :=500;
Point Xa is 78.48686988 and point Ya is 17.61674904
RESULT = success
XCORDINATE = 78.48686988
YCORDINATE = 17.61674904
Is this output correct? Actually, I have to integrate this with UMN MapServer. Kindly advice
Regards
Venkat

SDO_UTIL.APPEND strips away LRS dimensions

Hi folks,
Checking over the forum it seems I did note this issue in passing a year ago
https://community.oracle.com/message/11033886#11033886
But it came out to bite me today. It does seem true that I flog poor old SDO_UTIL.APPEND every-so-often and perhaps I should find other interests.
I am thinking this is probably a "feature" and a small blurb should be added to the documentation for the function. SDO_UTIL.APPEND simply says of itself, "Appends one geometry to another geometry to create a new geometry."
There is no mention of what types of geometries you should or should not feed to it.
However feeding LRS geometries to SDO_UTIL.APPEND is a bad idea (see below) as the function destroys the LRS dimension from the SDO_GTYPE producing a 3D geometry. I guess that I should be using SDO_LRS.CONCATENATE_GEOM_SEGMENTS though I am not interested in this case in merging the geometries, I just want to house them together in a multi-geometry. I think this is what SDO_UTIL.APPEND was meant for.
Assuming this is just a feature, perhaps Oracle could add a note on the SDO_UTIL.APPEND page that the function is not valid for LRS geometries? Or is this a bug?
Cheers,
Paul
ON 11GR2:
SELECT
SDO_UTIL.APPEND(
    SDO_GEOMETRY(3302,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(1,1,1, 2,2,2))
   ,SDO_GEOMETRY(3302,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(3,3,3, 4,4,4))
FROM dual;
RESULT:
SDO_GEOMETRY(3006,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1,7,2,1),SDO_ORDINATE_ARRAY(1,1,1,2,2,2,3,3,3,4,4,4))

Paul,
My take on append, is that it will just stuff the first and the second geometries together with no logic applied. So although your example result geometry just happens to work out, there is no logic given to the measure portion of the LRS. The measure can be a distance, say meters for Lat/Lon - or it can be some arbitrary scale such as the percentage of a city block going from 0 to 1. Since append would have no knowledge of how your two line stings are to be stuck together, you could easily wind up with:
SELECT
SDO_UTIL.APPEND(
    SDO_GEOMETRY(3302,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(3,3,3, 4,4,4)),
    SDO_GEOMETRY(3302,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(1,1,1, 2,2,2))
FROM dual;
RESULT:
SDO_GEOMETRY(3006,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1,7,2,1),SDO_ORDINATE_ARRAY(3,3,3,4,4,4,1,1,1,2,2,2))
...that of course is completely invalid as the measure is not progressing in order:
SELECT
SDO_LRS.VALIDATE_LRS_GEOMETRY(
   SDO_GEOMETRY(3306,NULL,NULL,SDO_ELEM_INFO_ARRAY(1,2,1,7,2,1),SDO_ORDINATE_ARRAY(3,3,3,4,4,4,1,1,1,2,2,2))
FROM
dual;
RESULT ON 11.2.0.4.2: 13335
ORA-13335 LRS segment is not defined
Cause: The given start or end measures are not defined, or some assigned measures in between are not in an ascending order.
Action: An LRS geometric segment is defined if its start and end measure are assigned (non-null). Any other measures assigned on the segment must be in an ascending order.
Bryan
PS - Yes, I agree on the error message - or more so, on checking for valid inputs to start with. However, I do get the idea that doing so on something that is called millions or billions of times in a row, can cause it to run slightly slower. All in all, I'd personally rather have validity checks that a routine that runs 2% faster and can give me invalid answers.

Finding the centroid of a polyline

Hi.
I am trying to write a function that will return the centroid of an input polyline. I have come up with two possible solutions, but both are problematic in different ways...
This first function returns an error:
ORA-00600: internal error code
Our DBA is looking in to this, but so far with no success
The second function seems to work ok, but is very slow. It takes over half an hour to process the first 10,000 records in my table (there are 270,000 in all)
Any suggestions as to what the problem might be with the first function, or how to speed up the second?
Thanks!
1
create or replace function get_line_centroid(geoloc MDSYS.SDO_GEOMETRY) return MDSYS.SDO_GEOMETRY
as
mbr MDSYS.SDO_GEOMETRY;
centroid MDSYS.SDO_GEOMETRY;
begin
mbr := MDSYS.SDO_GEOM.SDO_MBR(geoloc);
If SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(mbr, 0.05) = 'TRUE' Then
centroid := MDSYS.SDO_GEOM.SDO_CENTROID(mbr, 0.05);
End If;
return centroid;
end;
2
create or replace function get_line_centroid(geoloc MDSYS.SDO_GEOMETRY) return MDSYS.SDO_GEOMETRY
as
lrs_seg MDSYS.SDO_GEOMETRY;
centroid MDSYS.SDO_GEOMETRY;
begin
lrs_seg := SDO_LRS.CONVERT_TO_LRS_GEOM(geoloc);
centroid := SDO_LRS.LOCATE_PT(lrs_seg, SDO_LRS.PERCENTAGE_TO_MEASURE(lrs_seg, 50));
return SDO_LRS.CONVERT_TO_STD_GEOM(centroid);
end;

Hi All.
Well I have still not figured why my first function was failing, but I have discovered a much faster alternative to the second one...
This is to perform a manual computation of the centroid using the coordinates in the ordinate array of the line.
Quite straight forward :)

"invalid LRS segment" when querying an Oracle Spatial DB

I have a table of GIS segments in an Oracle Spatial database. I'm using C# and ODP to connect to the database. For a given measure from the start of a segment, I want to find the GPS coordinates for that point. I'm running the following query:
select g.geom.sdo_ordinates ord_array from
*(select sdo_lrs.locate_pt(shape,0.02,0) as geom from test_schema.test_table*
where route='ABC' and segmentnum='101.1') g
where shape is of type SDO_GEOMETRY. I'm getting the following error:
ORA-13331: invalid LRS segment
Is there a problem with how I'm passing shape to locate_pt()? The Oracle Spatial documentation says the argument should be SDO_geometry, so that seems ok.
Edited by: 964844 on Oct 11, 2012 2:10 PM

I'm using C# with ODP.NET.
Here is the current version of the code that is failing:
var param = new OracleParameter("geom", OracleDbType.Object);
param.UdtTypeName = "MDSYS.SDO_GEOMETRY";
param.Direction = ParameterDirection.Input;
OracleCommand oCmd = new OracleCommand();
oCmd.Connection = this.oConn;
oCmd.CommandText = queryStr;
oCmd.CommandType = CommandType.Text;
oCmd.Parameters.Add(param);
OracleDataAdapter da = new OracleDataAdapter(oCmd);
DataTable dt = new DataTable();
da.Fill(dt);
The exception is generated by the da.Fill(dt) line.

Oracle Spatial LRS point X and Y.

I’m having some problems with LRS points.
Two tables: A and b. Table A contains valid LRS linestrings; table B (non spatial) is a list of points with stated eastings and northings columns that exist in close proximity to the linestrings. Points are associated to the linestring by a.unique_id.
I’m successfully projecting the b.points onto their a.linestrings using SDO_LRS.PROJECT_PT passing the a.geometry and constructing a geometry from b.eastings and b.northings.
So far so good. I can get the measure by nesting SDO_LRS.GET_MEASURE; and offset with SDO_LRS.GET_OFFSET. Meaning that the returned value from SDO_LRS.PROJECT_PT is a valid LRS point (SDO_GTYPE=3301):
(3301, 81989, (0, 0, ), (1, 1, 1, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ), (525121.71247406, 185976.696321595, 21.4631188722804, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ))
This is my problem: how do I extract the X and Y from the SDO_LRS.PROJECT_PT returned value?
This work so far:
SELECT a.unique_id,
b.point_id,
SDO_LRS.GET_MEASURE
SDO_LRS.PROJECT_PT
a.geoloc,
b.SDO_GEOMETRY (2001,81989,SDO_POINT_TYPE(b.def_easting,b.def_northing,NULL),NULL,NULL)
ABS(SDO_LRS.FIND_OFFSET
a.geoloc,
b.SDO_GEOMETRY (2001,81989,SDO_POINT_TYPE(b.def_easting,b.def_northing,NULL),NULL,NULL)
FROM road_network a,points b
WHERE a.unique_id = b.roads_id
I’d like to add the following selections but it does not work:
SDO_LRS.PROJECT_PT
a.geoloc,
b.SDO_GEOMETRY (2001,81989,SDO_POINT_TYPE(b.def_easting,b.def_northing,NULL),NULL,NULL)
).SDO_POINT.X,
SDO_LRS.PROJECT_PT
a.geoloc,
b.SDO_GEOMETRY (2001,81989,SDO_POINT_TYPE(b.def_easting,b.def_northing,NULL),NULL,NULL)
).SDO_POINT.Y
And this one neither (just a couple of brackets, sign of desperation!):
(SDO_LRS.PROJECT_PT
a.geoloc,
b.SDO_GEOMETRY (2001,81989,SDO_POINT_TYPE(b.def_easting,b.def_northing,NULL),NULL,NULL)
)).SDO_POINT.X
(SDO_LRS.PROJECT_PT
a.geoloc,
b.SDO_GEOMETRY (2001,81989,SDO_POINT_TYPE(b.def_easting,b.def_northing,NULL),NULL,NULL)
)).SDO_POINT.Y
It always returns 0.
When you look at the SDO_LRS.PROJECT_PT returned value you’ll see the following only ordinates: 525121.71247406, 185976.696321595, 21.4631188722804
525121.71247406 being the X;
185976.696321595 the Y; and
21.4631188722804 the LRS measure.
So, how do I get those X and Y as part of my query results? Thanks.
Edited by: JG1981 on Jun 25, 2010 3:30 PM

A bit of time has past... I got back to this piece of work again. Thanks for the tips above, I’ve successfully implemented some of those. It works, but it’s too slow for production.
To summarise, this is the real world problem I’m dealing with:
Let’s say I’ve got a table containing pedestrian’s footways; each footway is referenced to its road network section (link), many footways records to one section. I have to calculate the length of each individual footway along its road section.
Theoretically this is done by projecting all the footway vertices onto its road section and returning the difference between the highest LRS value and the lowest. The problem is slightly made worse by the fact that each footway polygon can actually be made up of multiple elements (multipolygon).
The following is a sort of high level logic. I’d like to know if any of you agree with this:
1.     A temporary table t is created and populated with the following columns:
a.     Footway_id  existing identifier;
b.     Element_id  sequential and unique to the footway record;
c.     Vertices  LRS point (projected point);
2.     The table t is then queried: for each footway[sum[ each element (maxLRS-minLRS)]], in short, for each footway multipolygon the length of each element is added together to give the total length of the footway.
Is this too clumsy? Is there another way to go about? Perhaps without the use of a temporary table? Any suggestion’s welcome.
Thanks

SDO_LRS.OFFSET_GEOM_SEGMENT

Similar Messages

Maybe you are looking for