Sdo_aggr_union

I am trying to union 2 line segments and than create a buffer around my new geomerty. I ran both queries alone and they worked but when I combined them together I get an errror. Am I missing the something in my query?
1 SELECT mdsys.sdo_buffer(SELECT sdo_geom.sdo_aggr_union(mdsys.sdoaggrtype(a.geom, 0.5))
2 FROM dime a
3 WHERE a.rcd_nbr IN('46067','46068')) geom,
4 m.diminfo, 10)
5 FROM dime, user_sdo_geom_metadata m
6* WHERE m.TABLE_NAME = 'PARCEL'))
compass>/
SELECT mdsys.sdo_buffer(SELECT sdo_geom.sdo_aggr_union(mdsys.sdoaggrtype(a.geom, 0.5))
ERROR at line 1:
ORA-00936: missing expression

Matt,
I didn't think shapefiles had arcs in them! Even so, perhaps the arcs are in there but are incorrect because of a tolerance issue? Have you run the data through sdo_geom.validate_geometry before trying the query? Use a query like this:
SELECT a.rcd_nbr,
             a.geom,
             sdo_geom.validate_geometry(a.geom,m.diminfo)
  FROM user_sdo_geom_metadata m,
            dime a
WHERE ( m.TABLE_NAME = 'PARCEL' and m.column_name = 'GEOM' )
     AND a.rcd_nbr IN ('46067','46068')Then, if you get validate_geometry not returning TRUE paste the geometry objects that fail to this forum for people to look at. Also, what are your sdo_tolerance values in user_sdo_geom_metadata?
Simon

Similar Messages

  • A problem about SDO_AGGR_UNION

    I have a problem with the SDO_AGGR_UNION function.
    In the first step, I calculate the areas of the intersection between each polygon in dataset aus_veg_test A and the polygon 8 in dataset LAND_USE_DSE_TEST B. As the result shown below, some of the polygons in dataset A do intersect with polygon 8 in dataset B, such as 12, 13, 14, etc.
    In step 2, all the polygons in dataset A are aggregated into a single polygon 100 by SDO_AGGR_UNION function.
    In step 3, the area of the intersection between 100 (in table TEST_100) and 8 (dataset B) is calculated. But the result is 0.
    It seems to be a contradiction. Do you have some ideas about this? Thank you!
    -- STEP 1;
    SQL> SELECT a.gid, b.gid, SDO_GEOM.SDO_AREA(SDO_GEOM.SDO_INTERSECTION(a.geometry, b.geometry, 0.000000005), 0.000000005) AREA
    2 FROM aus_veg_test a, LAND_USE_DSE_TEST b
    3 WHERE B.GID = 8;
    GID GID AREA
    1 8
    2 8
    3 8
    4 8
    5 8
    6 8
    7 8
    8 8
    9 8
    10 8
    11 8
    GID GID AREA
    12 8 2.1580E-07
    13 8 8.2592E-07
    14 8 .00012801
    15 8
    16 8
    17 8
    18 8
    19 8
    20 8 .000042058
    21 8
    22 8
    GID GID AREA
    23 8
    24 8
    25 8
    26 8
    27 8
    28 8
    29 8
    30 8
    31 8
    32 8
    33 8 .000027234
    GID GID AREA
    34 8 0
    34 rows selected.
    -- STEP 2;
    SQL> CREATE TABLE TEST_100 AS
    2 SELECT 100 GRIDCODE, SDO_AGGR_UNION(MDSYS.SDOAGGRTYPE(GEOMETRY,0.0000005)) GEOMETRY
    3 FROM (SELECT 100 GRIDCODE, GEOMETRY FROM aus_veg_test) GROUP BY GRIDCODE;
    Table created.
    -- STEP 3;
    SQL> SELECT A.GRIDCODE, B.GID, SDO_GEOM.SDO_AREA(SDO_GEOM.SDO_INTERSECTION(A.geometry, B.geometry, 0.000000005), 0.000000005) AREA
    2 FROM TEST_100 A, LAND_USE_DSE_TEST B
    3 WHERE B.GID = 8;
    GRIDCODE GID AREA
    100 8 0

    I have the same problem with sdo_aggr_concat_line function
    create table uma_1(id number, geom mdsys.sdo_geometry);
    alter table uma_1 parallel;
    insert into uma_1
    values (1,SDO_GEOMETRY(2002,null,null,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(50,0,60,0)));
    insert into uma_1
    values
    (2,SDO_GEOMETRY(2002,null,null,SDO_ELEM_INFO_ARRAY(1,2,1),SDO_ORDINATE_ARRAY(20,0,30,0)));
    commit;
    SELECT SDO_AGGR_CONCAT_LINES(a.geom) FROM uma_1 a;
    :Returns no value or Oracle Error
    ORA-29400: data cartridge error
    ORA-00600: internal error code, arguments: [kohfrm771], [], [], [], [], [], [],[]
    alter table uma_1 noparallel;
    :Returns valid Line
    I wondering if you answer or replay on your problem?

  • Spatial Query - sdo_aggr_union

    Hi
    I am a newbie to oracle spatial (Database 11g) and am having an issue with sdo_aggr_union
    i have the following cursor
    CURSOR get_buffer_union IS
    SELECT sdo_aggr_union(sdoaggrtype(coverage,0.5)) coverage
    FROM
    (SELECT sdo_aggr_union(sdoaggrtype(coverage,0.5)) coverage
    FROM
    (SELECT sdo_aggr_union(sdoaggrtype(coverage,0.5)) coverage
    FROM
    (SELECT sdo_aggr_union(sdoaggrtype(coverage,0.5)) coverage
    FROM
    (SELECT sdo_aggr_union(mdsys.sdoaggrtype(geom,0.5)) coverage
    FROM rep_geo_acc_buffer
    where extraction_date = trunc(sysdate)
    GROUP BY mod(rownum,128))
    GROUP BY mod (rownum, 32))
    GROUP BY mod (rownum, 8))
    GROUP BY mod (rownum, 2)
    The result i am getting back is null. If I run the inner statement i get back 128 rows. Is it possible that this result is being held in cache and this is not the true result or is there someting wrong with the query.

    Wellcome to OTN Forums!
    Why you are using GROUP BY inner GROUP BY?
    What is your logic?
    CURSOR get_buffer_union IS
    SELECT sdo_aggr_union(sdoaggrtype(coverage,0.5)) coverage
    FROM
    (SELECT sdo_aggr_union(sdoaggrtype(coverage,0.5)) coverage
    FROM
    (SELECT sdo_aggr_union(sdoaggrtype(coverage,0.5)) coverage
    FROM
    (SELECT sdo_aggr_union(sdoaggrtype(coverage,0.5)) coverage
    FROM
    (SELECT sdo_aggr_union(mdsys.sdoaggrtype(geom,0.5)) coverage
    FROM rep_geo_acc_buffer
    where extraction_date = trunc(sysdate)
    GROUP BY mod(rownum,128))
    GROUP BY mod (rownum, 32))
    GROUP BY mod (rownum, 8))
    GROUP BY mod (rownum, 2)
    );

  • SDO_AGGR_UNION gives ODCI errors

    I have a Oracle spatial table having over 2 millon records. I need to aggregate all the buffer geometries based on names such that for each name there will be only one aggregated geometry. There are around 5000 distinct name.
    I am running the following query,
    SELECT NAME, COUNT(GEOM),
         SDO_AGGR_UNION(MDSYS.SDOAGGRTYPE
         (SDO_GEOM.SDO_BUFFER
         (GEOM, 100.0, 0.5, 'UNIT=FOOT'), 0.05))
    FROM GEOM_TABLE
    GROUP BY NAME;
    I am getting the following errors,
    ORA-29913: error in executing ODCIAGGREGATEMERGE callout
    ORA-29913: error in executing ODCIAGGREGATEITERATE callout
    ORA-13347: the coordinates defining an arc are not distinct
    When I am limiting the number of geometries during aggregation it is working fine but failing with real data. Since SDO_AGGR_UNION is very slow in performance, what are the other available solutions. SDO_AGGR_SET_UNION doesn't either.
    Regards,
    Ananda

    You may split your query into two, to measure their performance:
    CREATE TABLE BUFF_GEOM_TABLE (NAME VARCHAR2(***), GEOM SDO_GEOMETRY);
    INSERT INTO BUF_GEOM_TABLE SELECT NAME,  SDO_GEOM.SDO_BUFFER(GEOM, 100.0, 0.5, 'UNIT=FOOT'), 0.05)
    FROM GEOM_TABLE;
    SELECT NAME, COUNT(GEOM),
         SDO_AGGR_UNION(MDSYS.SDOAGGRTYPE
         (GEOM, 0.05))
    FROM BUFF_GEOM_TABLE
    GROUP BY NAME;
    If the bottleneck is with SDO_AGGR_UNION, you may have some options:
    If you have 12c Oracle Spatial, you can enable the Vector Performance Accelerator (VPA) feature by setting the
    SPATIAL_VECTOR_ACCELERATION database system parameter to the value TRUE.
    ALTER SYSTEM/SESSION SET SPATIAL_VECTOR_ACCELERATION = TRUE;
    If you have 11gR2, you may use SDO_AGGR_SET_UNION. Please see an example of SDO_AGGR_SET_UNION:
    Spatial Aggregate Functions

  • SDO_AGGR_UNION very slow

    Hello friends,
    I'm having problems with SDO_AGGR_UNION function in Oracle 11.2.0.3. The performance is very bad.
    I need to aggregate several polygons (645) using SDO_AGGR_UNION.
    My table is:
    SQL> DESC GC_MUNICIPALITY;
    Nome Nulo Tipo
    STATE_ID NOT NULL NUMBER(5)
    GEOLOC SDO_GEOMETRY()
    First I ran the following query:
    SELECT SDO_AGGR_UNION(SDOAGGRTYPE(geoloc, 0.5)) geoloc
    FROM GC_MUNICIPALITY
    WHERE STATE_ID = 35
    Execution time: 57 minutes
    Then, I ran then aggregate union with groupings:
    SELECT SDO_AGGR_UNION(SDOAGGRTYPE(geoloc,0.5)) geoloc
    FROM
    (SELECT SDO_AGGR_UNION(SDOAGGRTYPE(geoloc,0.5)) geoloc
    FROM
    (SELECT SDO_AGGR_UNION(SDOAGGRTYPE(geoloc,0.5)) geoloc
    FROM
    (SELECT SDO_AGGR_UNION(SDOAGGRTYPE(geoloc, 0.5)) geoloc
    FROM GC_MUNICIPALITY
    WHERE STATE_ID = 35
    GROUP BY MOD(ROWNUM, 15))
    GROUP BY MOD (ROWNUM, 7))
    GROUP BY MOD (ROWNUM, 2)
    Execution time: 15 minutes
    The second execution was faster than the first, but still very slow.
    If I use ArcGis, PostGis or JTS, the same aggregation is executed in few seconds.
    Why is this function so slow in Oracle?
    Is there another way to accomplish this aggregation with better performance?
    I read in another forum that if I convert from SDO_GEOMETRY to SDO_TOPO_GEOMETRY the aggregation is faster. However, the SDO_AGGR_UNION works only with SDO_GEOMETRY type. Is there any way to aggregate SDO_TOPO_GEOMETRY?
    Thanks!
    Edited by: user12000327 on 03/04/2012 09:30
    Edited by: user12000327 on 03/04/2012 09:33

    Siva,
    This group by won't work as you hit that internal limit in the server.Patently! I provided this example because this is what people want in an aggregate and it is the way most people think of it.
    So try the other approach described in the user guide using a function that creates a geometry array and passes it to the union function.OK, two more assertions:
    1. Working with users over the years I have discovered they can use SQL reasonably well but I am surprised how many simply don't want to go down a PL/SQL function route!
    2.The example given is very opaque as to how to do a SELECT ... GROUP BY aggregation using sdo_aggr_set_union.
    Personally, I would prefer to expose the grouping value....
    CREATE OR REPLACE FUNCTION Set_Geometry(p_value in varchar2)
    RETURN SDO_GEOMETRY_ARRAY
    deterministic
    AS
      c_query   SYS_REFCURSOR;
      v_g       sdo_geometry;
      v_GeomArr sdo_geometry_array;
    BEGIN
      v_GeomArr := SDO_GEOMETRY_ARRAY();
      OPEN c_query FOR 'select a.geometry from admin a where a.blockcode = :1'
                 USING p_value;
       LOOP
        FETCH c_query into v_g;
         EXIT when c_query%NOTFOUND ;
         v_GeomArr.extend;
         v_GeomArr(v_GeomArr.count) := v_g;
       END LOOP;
       RETURN v_GeomArr;
    END;
    -- Which is called like so:
    select a.group_code, count(*) as aggrCount, sdo_aggr_set_union(set_geometry(a.group_code),0.005) as geoms
    from admin a
    where a.hierarchy_code = 'WA'
    group by a.group_code;But this is quite inflexible because it really isn't a generic function but rather a function for a specific piece of SQL.
    Because of this I prefer something more generic:
    CREATE OR REPLACE FUNCTION Set_Geometry(p_cursor in SYS_REFCURSOR)
    RETURN SDO_GEOMETRY_ARRAY
    DETERMINISTIC
    AS
       v_geom    sdo_geometry;
       v_GeomArr sdo_geometry_array;
    BEGIN
       v_GeomArr := SDO_GEOMETRY_ARRAY();
       LOOP
        FETCH p_cursor INTO v_geom;
         EXIT when p_cursor%NOTFOUND ;
         v_GeomArr.extend;
         v_GeomArr(v_GeomArr.count) := v_geom;
       END LOOP;
       RETURN v_GeomArr;
    END;
    -- Results
    FUNCTION Set_Geometry compiled
    -- Now here's how to use it in a SELECT .... GROUP BY ...
    select group_code,
           count(*) as aggrCount,
           sdo_aggr_set_union(set_geometry(CURSOR(SELECT b.geometry FROM test_table b WHERE b.group_code= a.group_code)),0.005) as geoms
    from test_table a
    where a.hierarchy_code = 'WA'
    group by a.group_code;Now I agree SDO_AGGR_SET_UNION is much faster and, with my function, more flexible but it is still ugly.
    I am not an expert on this issue of that system limit of 30k sort area. When we talk to internal groups about it, they always
    ask us to show the customer filed ER. So it will really help if customers like you file an official ER for this.Surely someone in the spatial team is an expert!
    I can't file an ER because my Oracle use is under an OTN license for development purposes. I have asked complaining customers to do so over the years but for some reason they don't so I am left to make a fool of myself on their behalf.
    Having said that, the main problem with this approach is still the multiple copies of the data which tends to take up
    most of the time. So we are coming up with a better way to call sdo_aggr_set_union that avoid this multiple copies of the data.In your UC presentation? It is good for the public to know that the OS team is always trying to make things better and faster.
    regards
    Simon

  • Join Line Segments (road segments) SDO_AGGR_UNION/SDO_AGGR_CONCAT_LINES

    Hi,
    I have road segments I need to join/merge in order to get the complete road axe. Unfortunately I have some segements which are not joined and the resulting road axe has a gap.
    When I look at the road segements and the join result it seems to me that aggregation does not work for roads which either have segements which are disjoint (we have a few roads where single segments do not touch) or if a road has two or more "branches" (just take the letter "Y" as example for it).
    (1) SDO_AGGR_CONCAT_LINES
    Didn't work at all - I could not create a view using SDO_AGGR_CONCAT_LINES. As the documention mentions - not suitable if you have arcs (we have).
    (2) SDO_AGGR_UNION
    I tried SDO_AGGR_UNION as well although the documentation mentions - "Do not use SDO_AGGR_UNION to merge line string or multiline string geometries; instead, use the SDO_AGGR_CONCAT_LINES spatial aggregate function."
    (3) SDO_AGGR_SET_UNION
    I tried SDO_AGGR_SET_UNION as well. It sounded promising as the documentation doesn't mention anything related to arcs but says: "Can aggregate sets of lines..."
    2 and 3 give the same result. Please have a look at the screenshot (mh, looks like I can't upload a picture...)
    I would like to aggregate the segements - is there another function in Oracle I could use?
    Any idea, whether SDO_AGGR_UNION / SDO_AGGR_SET_UNION are / are not suitable for my dataset?
    Many thanks, Rob
    My view definitions:
    CREATE OR REPLACE FORCE VIEW AV_V_STRASSEN_2
    AS
      SELECT l.fid,
        ln.location_name,
        SDO_AGGR_UNION(sdo.SDOAGGRTYPE(rs.geom, 0.005)) geom
      FROM lm_lo_location l,
        lm_lo_location_name ln,
        lm_lo_road_section rs
      WHERE l.fid = ln.fid_lo_location
      AND l.fid   = rs.fid_lo_location
      GROUP BY l.fid,
        ln.location_name;
        CREATE OR REPLACE FORCE VIEW AV_V_STRASSEN_3
    AS
        SELECT l.fid,
        ln.location_name,
        sdo_aggr_set_union (get_geom_set ('lm_lo_road_section', 'geom','fid_lo_location = ', l.fid), .0005 ) geom
      FROM lm_lo_location l,
        lm_lo_location_name ln,
        lm_lo_road_section rs
      WHERE l.fid = ln.fid_lo_location
      AND l.fid   = rs.fid_lo_location
      GROUP BY l.fid,
        ln.location_name;

    R o b wrote:
    after some further tests I found out that the cause of the issue seems to be the application I used for viewing my road network.
    I displayed the view in SQLDeveloper and with FME and both look fine - result is expected (for view 2 and 3). But initially I used a different package for checking the view visually.
    Yes, that can happen sometimes. Currently I've been working with one of the biggest GIS-applications out there, and I have noticed that especially when zooming in or out rapidly gaps appear between lines (when I know for certain that there are no gaps - because I checked). It's weird that, but it can trick you into believing things are not right.
    R o b wrote:
    Stefan - thanks for yopur reply:
    - I need the roads not road segements when displaying the data in our GIS system, most users want a road not single segements
    - performance : will see, if it's not good I will create a mat. view, road network is quite static and doesn't change often
    - gaps : there are no gaps in our data set (but "gaps" appeared when I displayed the view in one specific software package).
    - sdo_aggr_union / sdo_aggr_set_union seem to do what I want and seem to work with our data as well
    Roads do make more sense to users - that is true. If you also need segments, maybe the LRS stuff can help you there: create the necessary segments on the fly when needed? On the other hand you are right, road networks tend to stay the same for a long time, and if the do change you usually have plenty of notification so an MV might be best (also depends on the number of users and the type of users I suppose).
    Glad it's working for you now!
    Cheers,
    Stefan

  • Spatial - SDO_AGGR_UNION question.

    I have extracted geo spatial informaton from a document and created sdo_geometry objects of different types in my database. I have polygons, points, lines, ellipsis, and multipoint types of gtypes. I am trying to aggregate them using SDO_AGGR_UNION. this is sql I am running - the dxc.xml_id is the id of my document which all of the rows have):
    select SDO_AGGR_UNION(SDOAGGRTYPE(dxc.shape_geo, 0.005)) from DOCUMENT_GEO dxc where dxc.xml_id = 374;
    I get this error:
    ORA-29913: error in executing ODCIAGGREGATEITERATE callout
    ORA-13031: Invalid Gtype in the SDO_GEOMETRY object for point object
    ORA-13031: Invalid Gtype in the SDO_GEOMETRY object for point object
    29913. 00000 - "error in executing %s callout"
    *Cause:    The execution of the specified callout caused an error.
    *Action:   Examine the error messages take appropriate action.
    I am thinking that spatial only support aggregating points with points, polygons with polygons, lines with lines, etc. Can anyone confirm this. The documentation isn't clear. If you can aggregate points with other things I would love to know how its done. Thanks.

    Your question is better off @ the Spatial Forum: Spatial

  • SDO_AGGR_UNION Question

    I have extracted geo spatial informaton from a document and created sdo_geometry objects of different types in my database. I have polygons, points, lines, ellipsis, and multipoint types of gtypes. I am trying to aggregate them using SDO_AGGR_UNION. this is sql I am running - the dxc.xml_id is the id of my document which all of the rows have):
    select SDO_AGGR_UNION(SDOAGGRTYPE(dxc.shape_geo, 0.005)) from DOCUMENT_GEO dxc where dxc.xml_id = 374;
    I get this error:
    ORA-29913: error in executing ODCIAGGREGATEITERATE callout
    ORA-13031: Invalid Gtype in the SDO_GEOMETRY object for point object
    ORA-13031: Invalid Gtype in the SDO_GEOMETRY object for point object
    29913. 00000 - "error in executing %s callout"
    *Cause: The execution of the specified callout caused an error.
    *Action: Examine the error messages take appropriate action.
    I am thinking that spatial only support aggregating points with points, polygons with polygons, lines with lines, etc. Can anyone confirm this. The documentation isn't clear. If you can aggregate points with other things I would love to know how its done. Thanks.

    680275,
    . . . .Multipoints appear to be supported.
    . . . .NOTE: the multipoint you listed was missing an EIA-tuple that identifies the last coordinate.
    SQL> INSERT INTO foobar (geometry) VALUES (
          MDSYS.SDO_GEOMETRY(2005, 40986, NULL,
          MDSYS.SDO_ELEM_INFO_ARRAY(
                1,1,1,
                3,1,1,
                5,1,1,
                7,1,1), -- "this was the missing EIA tuple"
          MDSYS.SDO_ORDINATE_ARRAY(
                1,2, --"point 1, EIA 1,1,1"
                3,4, --"point 2, EIA 3,1,1"
                1,2, --"point 3, EIA 5,1,1"
                3,4) --"point 4, EIA 7,1,1"
    SQL> SELECT t.geometry.sdo_gtype FROM foobar t;
                  2003  --"polygon"
                  2001  --"point"
                  2005  --"multipoint"
                  2002  --"line"
    4 rows selected.
    SQL> SELECT SDO_AGGR_UNION(SDOAGGRTYPE(geometry, 0.005)) from foobar;
    SDO_GEOMETRY(
        2004,
        40986,
        NULL,
        SDO_ELEM_INFO_ARRAY(
            1,2,1,
            5,1,3,
            11,1005,3,
                11,2,1,
                39,2,2,
                43,2,1),
        SDO_ORDINATE_ARRAY(
            6075668.22,2231086.91,6075754.6,2231132.45,
            1,2,3,4,  --"look familiar?"
            6061788.51,2165302.52,6067373.34,2283448.5,
            6067415.28,2283445.98,6067462.25,2283443.2,
            6067512.2,2283440.25,6067557.15,2283437.6,
            6067608.88,2283434.54,6067732.73,2283427.23,
            6067762.67,2283425.46,6067781.78,2283422.04,
            6067867.37,2283406.71,6067995.22,2283383.8,
            6068124.42,2283360.66,6068253.62,2283337.51,
            6068382.8,2283314.38,6068390.77,2283312.95,
            6068424.34,2283441.03,6068477.6,2283562.25,
            6068069.52,2283742.62,6068073.71,2283852.77,
            6067842.68,2283848.42,6067586.81,2283843.86,
            6067448.96,2283841.22,6067373.34,2283448.5)). . . .NOTE: the unioning (in sdo_aggr_"UNION") is probably why the duplicate coordinates in the multiple-point geometry were omitted from the aggregate.
    Regards,
    Noel

  • SDO_AGGR_UNION crashes the session

    Hi!
    I am developing a PL/SQL overlay module to overlay two polygon layers (+ some additional logic). I also use SDO_AGGR_UNION function, which aggregates polygons previously created by SDO_INTERSECTION function.
    At this point session crashes with "end-of-file on communication chanel". When debugging, I realised, that SDO_INTERSECTION produced invalid polygon from valid input polygons. In some case,s playing with tolerances, helps that crash does not occur. But produces crashes at other cases.
    I have Oracle Database 10g Enterprise Edition Release 10.1.0.4.0.
    Any idea, what is wrong or how to handle "end-of-file on communication chanel" as exception?
    Regards, Saso

    Saso,
    I'd bet real money that this is related to the issue we've been having, and working with Oracle to resolve, on SDO_UNION:
    SDO_UNION EOF on communications channel
    No, you cannot do anything to trap this problem in the database as the database session has crashed (core dumped).
    Bryan

  • SDO_AGGR_UNION into new polygon

    How can you write the reesult of an sdo_aggr_union into a new record?
    Thanks,
    Edited by: user6318652 on May 20, 2009 11:35 AM

    Sorry,
    I'm using the select statement
    SELECT mdsys.sdo_aggr_union(sdoaggrtype(geoloc, 0.5)) from my_table where my_area = 'fred';
    which returns;
    (2003, , , (1, 1003, 1, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ), (4927241.99521007, 3514676.65366773, 4926847.39343902, 3513395.32320204, 4927625.53162728, 3513158.63715876, 4928388.66594592, 3512924.01414755, 4928860.91274226, 3514460.78549355, 4929331.2840549, 3515991.74284008, 4927788.32361268, 3516459.86357228, 4927318.89004189, 3514927.59338716, 4927241.99521007, 3514676.65366773, , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ))
    I can manually format this and create an insert such as;
    Insert into my_SecondTable (GEOLOC) values (SDO_GEOMETRY(2003,NULL,NULL, sdo_elem_info_array(1, 1003, 1), SDO_ORDINATE_ARRAY(4927241.99521007, 3514676.65366773, 4926847.39343902, 3513395.32320204, 4927625.53162728, 3513158.63715876, 4928388.66594592, 3512924.01414755, 4928860.91274226, 3514460.78549355, 4929331.2840549, 3515991.74284008, 4927788.32361268, 3516459.86357228, 4927318.89004189, 3514927.59338716, 4927241.99521007, 3514676.65366773)));
    however, there should be a way to simply output the aggr_union results into an insert, but the results are in different formats. I assume there is something I'm missing.

  • SDO_AGGR_UNION function reverses linestrings !?

    Hi,
    When I use the SDO_AGGR_UNION function, the geometry objects (linestrings) get reversed
    by changing the order of the vertex
    Here's a SQL sample code that illustrates this issue :
    Code :
    DROP TABLE tmp;
    commit;
    CREATE TABLE tmp
    ("ID" NUMBER,
    "GEOM" SDO_GEOMETRY);
    commit;
    INSERT INTO TMP VALUES (
    1,
    SDO_GEOMETRY(2002, NULL, NULL, sdo_elem_info_array (1,2,1), SDO_ORDINATE_ARRAY(1,1, 2,2))
    commit;
    INSERT INTO TMP VALUES (
    1,
    SDO_GEOMETRY(2002, NULL, NULL, sdo_elem_info_array (1,2,1), SDO_ORDINATE_ARRAY(1,1, 2,2))
    commit;
    INSERT INTO TMP VALUES (
    2,
    SDO_GEOMETRY(2002, NULL, NULL, sdo_elem_info_array (1,2,1), SDO_ORDINATE_ARRAY(2,2, 1,1))
    commit;
    INSERT INTO TMP VALUES (
    2,
    SDO_GEOMETRY(2002, NULL, NULL, sdo_elem_info_array (1,2,1), SDO_ORDINATE_ARRAY(2,2, 1,1))
    commit;
    SELECT id, SDO_AGGR_UNION(SDOAGGRTYPE(a.geom,0.005))
    FROM tmp a
    GROUP BY id;
    Output :
    ID SDO_AGGR_UNION(SDOAGGRTYPE(A.GEOM,0.005))
    1 MDSYS.SDO_GEOMETRY(2002,NULL,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),MDSYS.SDO_ORDINATE_ARRAY(1,1,2,2))
    2 MDSYS.SDO_GEOMETRY(2002,NULL,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),MDSYS.SDO_ORDINATE_ARRAY(1,1,2,2))
    1 SDO_ORDINATE_ARRAY(1,1,2,2)
    2 SDO_ORDINATE_ARRAY(1,1,2,2)
    The linear geometry from record 2 got reversed by the SDO_AGGR_UNION function but not the one from record 1.
    Is this a normal feature ? Is there a workaround ?
    Thanks for your help

    update :
    if a SRId is provided (8307 for instance), the geometries get reversed but in another order !
    drop table tmp;
    commit;
    create table tmp
    ("ID" NUMBER,
    "GEOM" SDO_GEOMETRY);
    commit;
    INSERT INTO TMP VALUES (
    1,
    SDO_GEOMETRY(2002, 8307, null, sdo_elem_info_array (1,2,1), SDO_ORDINATE_ARRAY(1,1, 2,2))
    commit;
    INSERT INTO TMP VALUES (
    1,
    SDO_GEOMETRY(2002, 8307, null, sdo_elem_info_array (1,2,1), SDO_ORDINATE_ARRAY(1,1, 2,2))
    commit;
    INSERT INTO TMP VALUES (
    2,
    SDO_GEOMETRY(2002, 8307, null, sdo_elem_info_array (1,2,1), SDO_ORDINATE_ARRAY(2,2, 1,1))
    commit;
    INSERT INTO TMP VALUES (
    2,
    SDO_GEOMETRY(2002, 8307, null, sdo_elem_info_array (1,2,1), SDO_ORDINATE_ARRAY(2,2, 1,1))
    commit;
    select id, SDO_AGGR_UNION(SDOAGGRTYPE(a.geom,0.005))
    from tmp a
    group by id;
    ID SDO_AGGR_UNION(SDOAGGRTYPE(A.GEOM,0.005))
    1 MDSYS.SDO_GEOMETRY(2002,8307,null,MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),MDSYS.SDO_ORDINATE_ARRAY(2,2,1,1))
    2 MDSYS.SDO_GEOMETRY(2002,8307,null,MDSYS.SDO_ELEM_INFO_ARRAY(1,2,1),MDSYS.SDO_ORDINATE_ARRAY(2,2,1,1))
    funny isn't it ?

  • Final number of elements after SDO_AGGR_UNION

    Hi!
    I'm curious about how Oracle define number of elements in sdo object we've got after SDO_AGGR_UNION.
    Each object in ROAD table is of SDO_GTYPE=2002(line segments) and SDO_ELEM_INFO = 1 2 1.
    Say, we want to union all lines in table.
    After
    -- union about 400 rows
    select SDO_AGGR_UNION(MDSYS.SDOAGGRTYPE(t.geoloc, 00000001)) from (select geoloc geoloc
    from road t
    where
    SDO_GEOM.VALIDATE_GEOMETRY(t.geoloc,00000001)='TRUE'
    )t
    we have one aggergated object with SDO_GTYPE=2006(multiline) and !30! elements in SDO_ELEM_INFO, means it's 10 multiline segments now.
    It seems the number of SDO_ELEM_INFO elements depends on the number of rows processed. And it's always about 350-360 points in SDO_ORDINATES for each multyline segment in SDO_ELEM_INFO.
    Is there any way to get the only one multyline?

    Hi maha,
    First of all it depends of your user_sdo_geom_metadata entry. There you have defined a tolerance value. what have you defined there?
    As i can see you have SDO_GEOM.VALIDATE_GEOMETRY(t.geoloc,00000001) defined - so my question: do you mean 1 or 0.00000001? 0.00000001 may be a bit too much!
    /* 1.9.1 SDOAGGRTYPE Object Type - Oracle® Spatial User's Guide and Reference
    The tolerance value in the SDOAGGRTYPE definition should be the same as the SDO_TOLERANCE value specified in the DIMINFO in the xxx_SDO_GEOM_METADATA views for the geometries, unless you have a specific reason for wanting a different value. For more information about tolerance, see Section 1.5.5; for information about the xxx_SDO_GEOM_METADATA views, see Section 2.4.
    The tolerance value in the SDOAGGRTYPE definition can affect the result of a spatial aggregate function. Figure 1-12 shows a spatial aggregate union (SDO_AGGR_UNION) operation of two geometries using two different tolerance values: one smaller and one larger than the distance between the geometries.
    I assume, your tolerance is defined too small for your point distances.
    regards, Andreas

  • Sdo_aggr_union core dump on 11.1

    I am using the spatial features of Oracle 11.1 and I have run into a bug
    that causes the instance to core dump. I am wondering if anyone could help
    me sort out the problem.
    I can send the data in the table and the full trace file to anyone interested. I would just attach them to this message, but the forum does not appear to support attachments.
    /c/TEMP/bug:: sqlplus a715139/XXX @bug.sql
    SQL*Plus: Release 11.1.0.6.0 - Production on Thu Jul 24 17:07:43 2008
    Copyright (c) 1982, 2007, Oracle. All rights reserved.
    Connected to:
    Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing
    options
    select
    sdo_aggr_union(SDOAGGRTYPE(sdo_util.simplify(geom,1222.99245256282,0.5),
    0.5)) from bug
    ERROR at line 1:
    ORA-03113: end-of-file on communication channel
    Process ID: 3596
    Session ID: 129 Serial number: 35
    Disconnected from Oracle Database 11g Enterprise Edition Release
    11.1.0.6.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing
    options
    /c/TEMP/bug: head -125 orcl11_ora_3596_i26632.trc
    Dump file c:\app\a715139\diag\rdbms\orcl11\orcl11\incident\incdir_26632\orcl11_ora_3596_i26632.trc
    Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
    With the Partitioning, OLAP, Data Mining and Real Application Testing options
    Windows XP Version V5.1 Service Pack 2
    CPU : 2 - type 586
    Process Affinity : 0x00000000
    Memory (Avail/Total): Ph:1130M/3071M, Ph+PgF:3156M/4955M, VA:1240M/2047M
    Instance name: orcl11
    Redo thread mounted by this instance: 1
    Oracle process number: 25
    Windows thread id: 3596, image: ORACLE.EXE (SHAD)
    *** 2008-07-24 17:07:43.651
    *** SESSION ID:(129.35) 2008-07-24 17:07:43.651
    *** CLIENT ID:() 2008-07-24 17:07:43.651
    *** SERVICE NAME:(SYS$USERS) 2008-07-24 17:07:43.651
    *** MODULE NAME:(SQL*Plus) 2008-07-24 17:07:43.651
    *** ACTION NAME:() 2008-07-24 17:07:43.651
    Dump continued from file: c:\app\a715139\diag\rdbms\orcl11\orcl11\trace\orcl11_ora_3596.trc
    ORA-07445: exception encountered: core dump [mdagun_iter()+923] [ACCESS_VIOLATION] [ADDR:0x4] [PC:0x3DC866F] [UNABLE_TO_READ] []
    ========= Dump for incident 26632 (ORA 7445 [mdagun_iter()+923]) ========
    ----- Beginning of Customized Incident Dump(s) -----
    Exception [type: ACCESS_VIOLATION, UNABLE_TO_READ] [ADDR:0x4] [PC:0x3DC866F, _mdagun_iter()+923]
    Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
    Process Id: 0x00000270 Thread Id : 0x00000e0c Time : Thu Jul 24 17:07:43
    Excp. Code: 0xc0000005 Excp. Type: ACCESS_VIO Flags: 0x00000000
    ------------------- Registers ----------------------------
    eip = 03dc866f esp = 30f79144 ebp = 30f7a3b0 edi = 00000000 esi = 30f7ae34
    eax = 00000000 ebx = 0d98e234 ecx = 000010e6 edx = 0cef2180
    ecs = 0000001b eds = 00000023 ees = 00000023 ess = 00000023
    egs = 00000000 efs = 0000003b
    eflags = 00010246
    ------------------- End of Registers ---------------------
    *** 2008-07-24 17:07:43.651
    ----- Current SQL Statement for this session (sql_id=c1f0bx7jjmfmt) -----
    select sdo_aggr_union(SDOAGGRTYPE(sdo_util.simplify(geom,1222.99245256282,0.5), 0.5)) from bug
    ----- PL/SQL Stack -----
    ----- PL/SQL Call Stack -----
    object line object
    handle number name
    27C82C3C 59 MDSYS.AGGRUNION
    27C82C3C 25 MDSYS.AGGRUNION
    ----- Call Stack Trace -----
    calling call entry argument values in hex
    location type point (? means dubious value)
    mdaguniter()+923 00000000
    _spefcpfa()+168      CALLreg  00000000             30F7AE34 D982038 D981FA4
    D981EF8 D988E04 D9888A8 0
    spefmccallstd()+47  CALLrel  spefcpfa()+0 30F7AB88 7 D98E1E0 30F7A600
    7 30F7A618 0
    pextproc()+58       CALLrel  spefmccallstd()+0 30F7AE64 30F7AD24 30F7AC00
    30F7AB88 0
    __PGOSF416__peftrus CALLrel _pextproc()+0       
    ted()+115
    _psdexsp()+192       CALLreg  00000000             30F7AE64
    _rpiswu2()+560       CALLreg  00000000             30F7AAD0
    psdextp()+685       CALLrel  rpiswu2()+0 2F06AA90 58 2F06AAD4 2
    30F7AB00 58 2F06AB54 0 0
    4492DB8 0 30F7AAD0 1
    _pefccal()+467       CALLreg  00000000            
    pefcal()+174        CALLrel  pefccal()+0 30F7AE64
    pevmFCAL()+128 CALLrel _pefcal()+0         
    pfrinstrFCAL()+55 CALLrel pevmFCAL()+0 E39EED0 1E18BD38
    pfrrunno_tool()+5 CALL??? 00000000 E39EED0 1E18B512 E39EF10
    6
    pfrrun()+875        CALLrel  pfrrun_no_tool()+0 E39EED0 1E18B45C E39EF10
    plsqlrun()+729 CALLrel _pfrrun()+0          E39EED0
    peidxrrun()+202 CALLrel plsqlrun()+0 E39EED0 2 E38014C
    peidxexe()+52       CALLrel  peidxr_run()+0
    kkxdexe()+1367      CALLrel  peidxexe()+0 E39ED68
    kkxmpexe()+184      CALLrel  kkxdexe()+0 E39ED68 DE60704 D973E1C
    _kgmexwi()+469       CALLreg  00000000             F08A408 23462AC4 DED1B00
    E39ED68 27C82C3C D973E1C
    D973E3C
    kgmexec()+1116      CALLrel  kgmexwi()+0 F08A408 1 30F7B910 23462AC4
    DED1B00 DED1B44 2 27C82C3C
    D973E1C 30F7B84C
    evapls()+797        CALLrel  kgmexec()+0 F08A408 1 30F7B910 29DD4630
    27A0EB54 D973F04 D973E1C 0
    D973EF0 0 79
    _evaopn2()+609       CALL???  00000000             213F564C
    qximeopfbk()+533 CALL??? 00000000 213F564C
    qximeop()+65        CALLrel  qximeop_fbk()+0 213F564C 0 C0 30F7BDC8
    D951010
    qxuageag()+501      CALLrel  qximeop()+0 213F564C 0 C0 30F7BDC8
    D957100 95 4 213F545C D951C80
    DE64064 213F56A8
    _qesaAggNonDistSS()  CALL???  00000000             DE64040
    +292
    _kdstf0000001000kmP  CALLreg  00000000            
    ()+2278
    kdsttgr()+4444      CALLrel  kdstf0000001000kmP
    ()+0
    qertbFetch()+689    CALLrel  kdsttgr()+0 D951710 0 213F60FC D951668
    213F6148 32FB904 30F7C498
    7FFF
    _qergsFetch()+1994   CALLptr  00000000             D972F3C DE64040 1 213F5BD0
    5A9303D
    _opifch2()+7430      CALLreg  00000000             213F5BE4 D951CE8 1B12F34
    30F7C674 1
    kpoal8()+3756       CALLrel  opifch2()+0 89 5 30F7CCF8
    _opiodr()+1224       CALLreg  00000000             5E 1C 30F7F20C
    _ttcpip()+2733       CALLreg  00000000             5E 1C 30F7F20C 0
    _opitsk()+1278       CALL???  00000000            
    opiino()+1067       CALLrel  opitsk()+0 0 0
    _opiodr()+1224       CALLreg  00000000             3C 4 30F7FC24
    opidrv()+807        CALLrel  opiodr()+0 3C 4 30F7FC24 0
    sou2o()+45          CALLrel  opidrv()+0 3C 4 30F7FC24
    opimaireal()+130 CALLrel _sou2o()+0           30F7FC18 3C 4 30F7FC24
    opimai()+92         CALLrel  opimai_real()+0 2 30F7FC50
    OracleThreadStart@  CALLrel  opimai()+0
    4()+764
    7C80B680 CALLreg 00000000
    00000000 CALL??? 00000000

    Try adding the argument -XX:MaxPermSize=64M to the java command line. Also, 1.3.x
    sometimes dies when you take thread dumps.
    Mike
    "Silvan Heuberger" <[email protected]> wrote:
    >
    Mike,
    JVM version:
    $ /opt/java1.3/bin/java -version
    java version "JavaVM-1.3.0.01"
    Java(TM) 2 Runtime Environment, Standard Edition (build jinteg:02/14/01-23:51)
    HotSpot VM (build 1.0.1fcs jinteg:02/15/01-02:43 PA2.0, mixed mode)
    Silvan
    "Mike Reiche" <[email protected]> wrote:
    What JVM are you using?
    "Silvan Heuberger" <[email protected]> wrote:
    Hi
    We are running WLS5.1SP10 on a HP-UX 11.00 and stress the WLS with
    50
    parallel
    users. For the Connection to the DB (Oracle 8.1.7) we use the oci driver
    oci816_8
    with is deliverd with the sp10. our initial poolsize is set to 20 and
    the max
    is 100. the currentThreadsize we try from 50 to 140. Already aftera
    few requests
    (<400) the wls writes a core dump. As we make this with sp6 no coredump
    occured,
    but the java memory heap overflow.
    has somebody the same experience and know a solution for the problem?
    Thanx
    Silvan

  • SDO_AGGR_UNION in 9i

    Hello ,
    Could you please let me know whether SDO_AGGR_UNION is present in Oracle 9.2.0.1 (Locator feature) in Standard Edition.
    If it is not present , could any one please let me know is there is any other way to join two geometries like SDO_AGGR_UNION.
    Thanks in Advance
    Senthil

    sdo_geom.sdo_union and sdo_aggr_union are only available in spatial, not locator.
    I don't know of any way of getting this functionality except to either write it or buy it (from an app vendor or from oracle).

  • SDO_AGGR_UNION of polygons result a geometry with a line segment inside?

    Hi,
    I am struggling with a problem, I cannot find the reason.
    I have 3 polygons in Oracle Spatial 11g (Enterprise Edition Release 11.1.0.7.0 - 64bit Production):
    All three are simple polygons: SDO_GEOMETRY(2003, null, null, (1,1003,1), (... coord array...) )
    They are valid as the result of an SDO_MIGRATE.TO_CURRENT and a VALIDATE_GEOMETRY_WITH_CONTEXT
    SELECT SDO_AGGR_UNION(SDOAGGRTYPE(GEOM, 5E-1)) FROM ....
    result a collection geometry with elem_info_array (1,2,1, 5,1003,1)
    I cannot understand, how can this happen. Unioning the three separate polygons should result a simple polygon (if they were touching/overlapping) or a multipolygon with 2 or 3 rings.
    But the unionig how can result a line segment of two points??
    I have double-checked the polygons and the tolerance values also.
    Have you any idea?
    Thanks is advance
    Regards,
    Tamas

    They're some crazy looking geometries you've got there! I got a geometry back from your query using 11.1.0.6 on Windows XP, but its a useless geometry. I wouldn't expect Oracle Spatial to come back with a sensible geometry at the end of this anyway. You've got a mix of lots of different geometry types.
    SQL> select t.geometry.sdo_gtype, count(*)
      2  from test_geomunion t
      3  group by t.geometry.sdo_gtype
      4  order by 1;
    GEOMETRY.SDO_GTYPE   COUNT(*)
                  2001        355
                  2002        499
                  2003       1649
                  2004         11
                  2006          2
                  2007         21What result would you expect from the sdo_aggr_union query? i.e. what purpose would unioning all these together serve?
    I would more usually use sdo_aggr_union to put merge a few contiguous polygons together. Unioning points, lines and polygons together doesn't make sense to me.

Maybe you are looking for

  • Purchase Register Report issue

    Hi, I am working Purchase Register report. In this, we have a PO with 10 Quantity.  But at the time of MIGO we receive 5 qty out of 10. Now how can we pick the amount according to 5 qty received from MIGO because we want show MIGO condition in our re

  • The headphone jack.

    I'm beginning to lose my mind over this. Maybe someone can shine some light on what I can do here. I bought my MacBook Pro on Sunday, the 25th. I enjoyed it greatly. I love everything about the MBP. But no more than 12 hours into it's life, I plugged

  • Has anyone else lost their personal hotspot option after updating to iOS 6.1?

    I updated to the new iOS last night, and when I went to use my AT&T personal hotspot today, I noticed that it's missing from my settings menu.  Any tips on how to get it back?  I called AT&T and they told me that everything is fine on their end and t

  • I keep getting an error when downloading CS5.5 because of the 7Z Compressed File.

    I'm downloading both files in the same folder. I have windows 7. I downloaded a program to extract the 7z file called bitser which hasn't helped.

  • Camera Facetime HD intégrée - MacBook Pro Rétina

    Lorsque je veux accéder à "Facetime" ou autres programmes et site qui me demande l'utilisation de ma Camera Facetime HD ceux-ci m'affichent un message d'erreur "Aucune caméra reconnue. Ce problème me tracasse car même dans les configuration de mon Ma