SDO_BUFFER & multlinestring

Hi!
I am trying to create a buffer around the I 10 Highway from the US-dataset, interstates table. I am using following statement:
select sdo_geom.sdo_buffer((select geom from interstates where highway = 'I 10'), 0.5 , 0.1) from dual;
which results into:
[1]: (Error): ORA-13050: unable to construct spatial object
ORA-06512: at "MDSYS.SDO_3GL", line 399
ORA-06512: at "MDSYS.SDO_GEOM", line 3228 ORA-06512: at "MDSYS.SDO_GEOM", line 3240 ORA-06512: at line 1
The I 10 is a multiline so I also tried to create a buffer arround the I 170 and this works perfectly. Therfore I tried to create a buffer around several other highways, all of them were multilines and they all failed.
what a I doing wrong? Or is it impossible to create a buffer around a multiline string?
null

I found that the following statement does work for me:
select sdo_geom.sdo_buffer(geom, (select diminfo
from user_sdo_geom_metadata
where table_name = 'INTERSTATES'
and column_name = 'GEOM'), 0.5)
from interstates where highway = 'I 10';
But I don't understand what is wrong with the first statement.

Similar Messages

Sdo_buffer in Ora 10.2.0.4

Hi,
i'm running 2 dbs (R 10.2.0.4), one with windows and the other with linux. on the windows box the sdo_buffer works fine (buffer is computed) on the linux box the same statement results with 0-buffer.
are there any patch-levels regarding the OS (Windows vs Linux) ?
any suggestion ?
Edited by: juppo007 on 31.03.2010 05:29

the mentioned Geometry (VG-NR 303) is:
MDSYS.SDO_GEOMETRY(2003, 8307, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,1), MDSYS.SDO_ORDINATE_ARRAY(9.549311,47.582256,9.538158,47.585304,9.437511,47.538124,9.413537,47.527152,9.415096,47.525301,9.4082739999973,47.5231859999917,9.40340099999,47.5245079999662,9.39151099998129,47.522788999921,9.38488499998607,47.5017699999387,9.36656299998985,47.4897409999214,9.35291899999645,47.4814129999226,9.32933400000691,47.4736129999407,9.32192700000757,47.4675319999569,9.32329200000694,47.4639629999592,9.296199,47.465946,9.269885,47.442812,9.257801,47.432765,9.236555,47.434484,9.228369,47.427478,9.225835,47.421926,9.218038,47.405666,9.233242,47.390199,9.220962,47.382399,9.21453,47.364289,9.18704699917612,47.3476330000881,9.15819899863946,47.3345450000278,9.13039699794128,47.3313260000053,9.09719199683627,47.3356030000608,9.07750499602416,47.3330910000328,9.06074299523214,47.3270099999344,9.04748899453611,47.3296539999761,9.00480999184711,47.3048059993701,9.02681599333377,47.2894889991295,9.04780099456774,47.2860999991797,9.04385099435481,47.2776349989996,9.08639199645546,47.243234998798,9.10253555486423,47.2348670426165,9.10254154254773,47.2348742086742,9.10257121822297,47.2348710220964,9.14843622065071,47.2050760150544,9.14843815723205,47.2050746135459,9.14843986296803,47.2050730790354,9.16672885928311,47.1866410756564,9.1667311353001,47.1866279209723,9.19750399941013,47.1826989994088,9.21036799956856,47.1775509995101,9.22777899972697,47.1821659996551,9.23743599980615,47.1729329997167,9.22177599969553,47.163166999587,9.22073199970725,47.1452329995639,9.312079,47.154466,9.348879,47.144345,9.357753,47.133691,9.395303,47.130117,9.408933,47.110779,9.395013,47.101899,9.376164,47.104069,9.4309719999673,47.0649980001031,9.47076400017053,47.0675829996375,9.47208100016807,47.0606749996371,9.47537300017892,47.0525819996122,9.48229400024704,47.055972999498,9.4860700002689,47.0490269994548,9.49273200035533,47.0561239993296,9.53981500113295,47.0648819984333,9.55913700153588,47.0481209979459,9.60851700321915,47.0633879966931,9.61204700342227,47.0786189967294,9.63337000441301,47.0837039961738,9.63613400461608,47.1011019963159,9.6219190039645,47.1102019968057,9.63534400466573,47.1275999966983,9.62507800417935,47.132149997003,9.62231400410297,47.1508859973095,9.60651900341005,47.149011997604,9.59664800305212,47.1623949979359,9.56584800203848,47.1706919985065,9.57414000230585,47.1795249984619,9.56782300212573,47.1872869986168,9.5844070026886,47.2054869985788,9.56941100221986,47.2188159988816,9.56759500216414,47.2181069988938,9.56042100196281,47.2234909990129,9.55592700183761,47.2218949990421,9.55236800174598,47.2239449990917,9.56674000216596,47.2422629991273,9.53149500129395,47.2699919995746,9.53491100136943,47.2736419995845,9.54827900168831,47.2825619995962,9.55340900182432,47.2906559996459,9.556829,47.298428,9.586776,47.315761,9.597437,47.340921,9.606228,47.35288,9.625868,47.366081,9.656705,47.368383,9.670828,47.377676,9.675451,47.390437,9.672066,47.392043,9.651534,47.404891,9.650349,47.413723,9.645052,47.437759,9.658573,47.448315,9.659791,47.45354,9.63936,47.456354,9.622476,47.457694,9.61455,47.466452,9.610175,47.471141,9.604278,47.462726,9.601076,47.461677,9.595305,47.463283,9.591438,47.468272,9.587253,47.475338,9.584177,47.48037,9.577299,47.485187,9.562295,47.496429,9.563084,47.506064,9.611954,47.529369,9.593261,47.570712,9.56701,47.579303,9.549311,47.582256))
thx - Juppo

How to realize the function like SDO_GEOM.SDO_BUFFER in Spatial Operators?

Dear all,
I wanted to use SDO_GEOM.SDO_BUFFER function to generate a
buffer polygon around a geometry object while it is pretty slow
to perform for a large spatial database. I think it better
to use Spatial Operators for it takes advantage of spatial index.
But within operators, there are no availble function. Can anyone
tell me how to do it with Spatial Operators?
Thanks a lot,
Fan

Fabio,
Error 13349 indicates that the polygons intersect with themselves.
You need to fix these errors. There are tools in MapInfo Professional 7.5 to check and automatically fix them. There are other tools commercially available which also fix geometry errors.
If you know MapInfo I would fix these errors there.
Ivan

SDO_RELATE and SDO_BUFFER

Hi Folks,
I created a generic stored procedure that gets a table and a polygon coordinates as parameters and returns
the table records that satisfy a relationship.
One example of fhe SQL executed by the procedure is:
select GEOFT_MESORREGIAO.* from GEOFT_MESORREGIAO
where SDO_RELATE(GEOFT_MESORREGIAO.MES_GM_POLIGONO,
SDO_GEOMETRY(2003,2000004,NULL,
SDO_ELEM_INFO_ARRAY(1,1003,1),
SDO_ORDINATE_ARRAY(-51.427259,-20.547785,-51.575114,-22.289193,-49.094429,-22.387763,-49.028716,-20.457420)),'mask=ANYINTERACT') ='TRUE'
The GEOFT_MESORREGIAO stores polygon geometries.
Running the example I got 7 rows as result.
In the same procedure, users can pass additional parameters to create a buffer around the polygon defined as the query window.
In this case, the SQL executed is:
select GEOFT_MESORREGIAO.* from GEOFT_MESORREGIAO
where SDO_RELATE(GEOFT_MESORREGIAO.MES_GM_POLIGONO,
SDO_GEOM.SDO_BUFFER(SDO_GEOMETRY(2003,2000004,NULL,
SDO_ELEM_INFO_ARRAY(1,1003,1),
SDO_ORDINATE_ARRAY(-51.427259,-20.547785,-51.575114,-22.289193,-49.094429,-22.387763,-49.028716,-20.457420)),10,0.05,'unit=KM'),'mask=ANYINTERACT') ='TRUE'
Running this example I got 6 rows as result.
This is not right to me, because if I'm using a bigger query window created by the buffer function, it was expected to get more rows
as result or, at least, the same number of rows returned by the first example.
This was tested in Oracle 11g R1.
Am I missing anything?
Regards,
Luis

Hi
When validating your inline geometry, it returns a ORA-13348: polygon boundary is not closed.
The first coordinate should be repeated at the end to close a ring in a polygon.
SDO_GEOMETRY(2003,8236,NULL,
SDO_ELEM_INFO_ARRAY(1,1003,1),
SDO_ORDINATE_ARRAY(-51.427259,-20.547785,-51.575114,-22.289193,-49.094429,-22.387763,-49.028716,-20.457420*,-51.427259,-20.547785*))
will validate.
Try it and see if your results are as expected.
Luc

SDO_BUFFER Geometry in Mapviewer

I'm using the sdo_geom.sdo_buffer procedure to successfully generate a buffer around a point, but I can't seem to get the buffer to display the way I'd like. This is what I am doing to get a gray buffer:
mv.addJDBCTheme(dataSrc, "ASSET_CIRCLES", circleQuery,
"geometry", "8307", "SQL_QUERY", null, "L.CIRCLE" , true);
What I'd like is a colored buffer. In playing around w/ it, I was able to change the color of the circle's border, but can't seem to change the interior fill color. Any suggestions?
Thanks.

L.CIRCLE is likely a line style and so only determines how the border is rendered.
Use a color style instead. You may need to create one that has the desired stroke and fill colors. E.g.
select definition from user_Sdo_styles where name='C.CHARCOAL W/ ROSY BROWN BORDER' ;
DEFINITION
<?xml version="1.0" standalone="yes"?>
<svg width="1in" height="1in">
<desc></desc>
<g class="color" style="stroke:#bc8f8f;fill:#808080">
<rect width="50" height="50"/></g>
</svg>
SQL>

JGeometry and SDO_BUFFER of geodetic coordinates

I can successfully execute SQL that will create a "circle" around a geodetic lat/long using the SDO_BUFFER. The goal is to persist the resulting "circle" that SDO_BUFFER calculates. However, even using JGeometry, I still get the error "Too Many Values" when inserting over JDBC.
How can I execute the following SQL via JDBC? I'm using the JGeometry to "wrap" the point; however, I don't see how to use SDO_BUFFER.
The following is the prepared statement:
insert into t1 (?, ?, SDO_GEOM.SDO_BUFFER(?), ?, ?, ?, ?, ?)
// create a JGeometry for the point reprenting the lat/long
JGeometry landmarkGeo = JGeometry.createPoint(new double[]{latLong.getLongitude(), latLong.getLatitude()}, JGeometry.GTYPE_POINT, 8307);
STRUCT struct = JGeometry.store(landmarkGeo, conn);
stmt.setObject(3, struct);

Your call to sdo_buffer is not correct (syntax error), so it ends up
sending too many values to the table.
> insert into t1 (?, ?, SDO_GEOM.SDO_BUFFER(?), ?, ?, ?, ?, ?)
This closing ")" for sdo_buffer is not in the right place.
Depending on which signature you are using for buffer, move
the ")" to the right place.
How many columns are there in your table ?
siva

SDO_GEOM.SDO_BUFFER failed with ORA-13050

Hello,
I want to construct buffer for polylines.
SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT function returns TRUE for problem geometries:
SELECT SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(
MDSYS.SDO_GEOMETRY(2002, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1), MDSYS.S
121.75439, 31.37049, 121.75234, 31.36996, 121.75245, 31.37184, 121.75262, 31.373
121.75232, 31.37518, 121.74977, 31.37854)), 1e-7)
from dual
SDO_GEOM.VALIDATE_GEOMETRY_WIT
TRUE
But SDO_BUFFER fails:
SELECT SDO_GEOM.SDO_BUFFER(
MDSYS.SDO_GEOMETRY(2002, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1), MDSYS.SDO_ORDINATE_ARRAY(
121.75439, 31.37049, 121.75234, 31.36996, 121.75245, 31.37184, 121.75262, 31.37362, 121.75253, 31.37449,
121.75232, 31.37518, 121.74977, 31.37854)), 1e-5, 1e-7)
from dual;
Can somebody help me with advice how to construct buffer?
I have SDO_VERSION=9.2.0.5.0
Data tolerance in the user_sdo_geom_metadata table is 1e-7.
Thank you.
PS:
Other example of problem polyline:
MDSYS.SDO_GEOMETRY(2002, NULL, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1), MDSYS.SDO_ORDINATE_ARRAY(
121.68669, 31.3819, 121.68675, 31.3822, 121.68665, 31.38219, 121.68668, 31.3824,
121.6867, 31.38242, 121.68676, 31.38241, 121.68679, 31.38254, 121.68682, 31.38254, 121.6868, 31.3824))

Hello.
Im still trying to find out resolution for buffers construction :)
Actually I've got that buffer construction works much better on geodesic data.
Next statement is OK now:
SELECT SDO_GEOM.SDO_BUFFER(
MDSYS.SDO_GEOMETRY(2002, 8307, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1), MDSYS.SDO_ORDINATE_ARRAY(
121.75439, 31.37049, 121.75234, 31.36996, 121.75245, 31.37184, 121.75262, 31.37362, 121.75253, 31.37449,
121.75232, 31.37518, 121.74977, 31.37854)), 1, 1e-2, 'arc_tolerance=0.5')
from dual;
I run large test and got only one (currently) issue with the next poliline [ORA-13050: unable to construct spatial object]:
select SDO_GEOM.SDO_BUFFER(
MDSYS.SDO_GEOMETRY(2002, 8307, NULL, MDSYS.SDO_ELEM_INFO_ARRAY(1, 2, 1), MDSYS.SDO_ORDINATE_ARRAY(
117.56163, 23.74977999, 117.56163, 23.74949001, 117.56163, 23.7492, 117.56117999, 23.74906)),
1, 1e-2, 'arc_tolerance=0.5') from dual;
What is wrong with that poliline?
Are there any rules or workarounds for such cases? Can some body suggest me something about that?
I've found only 2 workarounds for that time:
1) I need to construct buffer within 1 millimeter tolerance. So I can round input geometry ordinates to 1 millimeter (1e-7) and try to build buffer after that. I did it for above poliline - and it works (actually it is necessary to round only second ordinate 23.74977999->23.7497799). But I don't sure that it will resolve issue entirely.
2) I can iteratively slightly increase buffer distance until buffer construction will be OK. Above example works starting from 1.3 meter. It is not best resolution because it can alter process logic.
Thank you.

Do I misunderstand sdo_buffer

As I understand SDO_GEOM.SDO_BUFFER it should generate rounded polygon around given geometry.
But if I create buffer around point, I actually get rectangle:
SELECT t.X, t.Y
from
TABLE(SDO_UTIL.GETVERTICES(
SDO_GEOM.SDO_BUFFER(
SDO_GEOMETRY(2001,NULL,SDO_POINT_TYPE(520000,125000,NULL),NULL,NULL)
,1000
,0.0005
))) t
The result I get:
X     Y
520000     126000
519000     125000
520000     124000
521000     125000
520000     126000
I would expect more points which define some sort of circle for the buffer around point.
Do I misunderstand sdo_buffer function?
Regards,
Sašo

Sorry, my writing was actually faster then my thinking:
The resulting polygon is circle, as it should be, displayed points are defining the arcs.
The problem is solved.
Sašo

SDO_BUFFER creates an ellipse

I am using the following statement to create a circle around a point:
sdo_geom.sdo_buffer(geom, 0.4734848, 0.5, 'arc_tolerance=.01 unit=mile')
This create an ellipse with the correct radius on the y axis, but 20% more distance on the x axis. SRID of the points is 8307.
What do I have to do to have a circle?

Since you are in long/lat space, the buffer created might look like an ellipse, but it should be a circle.
Can you post the coordinates of the input geometry ?
There is another interface sdo_util.circle_polygon() which can also be used when the input is a point geometry.
siva

Sdo_buffer question

I am hoping that someone can help me. I know this is a super easy fix. I am looking to creat a buffer around one xy coord. Am I on the right tract.
select sdo_geom.sdo_buffer(MDSYS.SDO_GEOMETRY(2001,8307,MDSYS.SDO_POINT_TYPE(2560808.6,387514.844,0),NULL,NULL), m.diminfo,100,.0005)
from tractblockpoint2000 t, user_sdo_geom_metadata m
select sdo_geom.sdo_buffer(MDSYS.SDO_GEOMETRY(2001,8307,MDSYS.SDO_POINT_TYPE(2560808.6,387514.844,0)
ERROR at line 1:
ORA-13205: internal error while parsing spatial parameters
ORA-06512: at "MDSYS.SDO_3GL", line 439
ORA-06512: at "MDSYS.SDO_GEOM", line 3065

The answer is yes. It is easy to buffer a point.
There are more questions to ask and answer here, though, because your data is not valid.
your sdo_gtype = 2301: this is not allowed. If I was to guess from looking at your data, I would guess you want 2001.
your sdo_srid = 8307: this is fine if your coordinates are between -180 and 180 in longitude (x), and -90 to 90 in latitude (y). Your data is not in this range.
if I was writing this, i would use the sdo_point_type instead of sdo_elem_info_array and sdo_ordinate array.
A two-d point in the sdo_ordinate_array should only have 2 ordinates (x and y, not x,y,null) - if stored in the sdo_point_type, then you need x, y, and null.
you don't need a select ... from dual to buffer the geometry, you can call the function in the operator.
Arc tolerance of 1/2 meter (0.5) is very fine - you will get a geometry with lots of vertices, and it may take a long time to get results. Below is an example of your query, rewritten, with a 10 meter tolerance. That said, further below is the same query written as sdo_within_distance, which includes an implicit, highly accurate buffer operation and an anyinteract.
Note since these queries are in a geodetic coordinate system and you didn't specify units, the default is meters.
The rewritten queries use the geod_cities table which is downloadable from OTN ( http://otn.oracle.com/products/spatial ), click on training on the right, then exercise solutions.
Your query rewritten:
select city
from geod_cities t
where sdo_relate(t.location, sdo_geom.sdo_buffer( mdsys.SDO_GEOMETRY(2001,8307, sdo_point_type(-75.13,40,NULL),null,null), 1000, 0.05, 'arc_tolerance=10'), 'mask = anyinteract querytype=window') = 'TRUE';
But best done using sdo_within_distance:
select city
from geod_cities t
where sdo_within_distance(t.location, mdsys.SDO_GEOMETRY(2001,8307, sdo_point_type(-75.13,40,NULL),null,null), 'distance=1000') = 'TRUE';

Adding multiple FOI themes with MapViewer with jdbc_query

Hi,
I'd like to add two themes to a map with the Javascript Mapviewer.
When I use mapview.addThemeBasedFOI(theme); only the theme that finished loading first will display. Is it possible to add multiple themes or am I doing something wrong?
The second thing I tried was using a jdbc_query theme. My javascript looks like this:
           var baseURL = "http://" + document.location.host + "/mapviewer";
            // Create an MVMapView instance to display the map
            var mapview = new MVMapView(document.getElementById("map"), baseURL);
            // Add a base map layer as background.
            mapview.addBaseMapLayer(new MVBaseMap("mvdemo.demo_map"));
            // Add a theme-based FOI layer
            var theme = '<themes><theme name="JDBC_THEME2" >' +
                        '<jdbc_query asis="true" spatial_column="location" jdbc_srid="8307" ' +
                        'render_style="C.RB13_6" datasource="mvdemo">' +
                        '<![CDATA[select sdo_geom.sdo_buffer(A.location,1,0.005,' +
                        '\'unit=mile arc_tolerance=0.005\') location ' +
                        ' from customers A where sales<=100]]>' +
                        '</jdbc_query></theme><theme name="JDBC_THEME" >' +
                        '<jdbc_query asis="true" spatial_column="location" jdbc_srid="8307" ' +
                        'render_style="C.RED" datasource="mvdemo">' +
                        'select sdo_geom.sdo_buffer(A.location,1,0.005,' +
                        '\'unit=mile arc_tolerance=0.005\') location ' +
                        ' from customers A where sales>100' +
                        '</jdbc_query></theme></themes>' ;
            console.log(theme);
            buffertheme = new MVThemeBasedFOI('buffertheme', theme);
            mapview.addThemeBasedFOI(buffertheme);
            // Set the initial map center and zoom level
            mapview.setCenter(MVSdoGeometry.createPoint(-122.45, 37.7706, 8307));
            mapview.setZoomLevel(4);
            // Add a navigation panel on the right side of the map
            mapview.addNavigationPanel('east');
            // Add a scale bar
            mapview.addScaleBar();
            // Display the map.
            mapview.display();I used the examples from page 222 and 225 from the Mapviewer manual (mapviewer_10131_ug.pdf) and it uses the MVDEMO schema.
The xml for the themes:
<themes>
    <theme name="JDBC_THEME2">
        <jdbc_query asis="true" spatial_column="location" jdbc_srid="8307" render_style="C.RB13_6" datasource="mvdemo">
            <![CDATA[select sdo_geom.sdo_buffer(A.location,1,0.005,'unit=mile arc_tolerance=0.005') location from customers A where sales<=100]]></jdbc_query>
    </theme>
    <theme name="JDBC_THEME">
        <jdbc_query asis="true" spatial_column="location" jdbc_srid="8307" render_style="C.RED" datasource="mvdemo">
            select sdo_geom.sdo_buffer(A.location,1,0.005,'unit=mile arc_tolerance=0.005') location from customers A
            where sales>100
        </jdbc_query>
    </theme>
</themes>In this example I want to display 2 different colors, one for sales>100 and one for sales<=100. Again, only the first color is displaying. I searched for some examples and found <map_request> xml files where multiple themes are allowed, is it also allowed with the Javascript Mapviewer?
Thanks for you help!
Jeroen

Hi
Are you trying to concatenating or adding it ? i mean you said adding year measure1measure2
year is character type so i guess that you want to display like 2011 45000 isnt it
then use concatenation or try to change the measure value to dimension to keep side by side
Hope this helps u

Trying to get multiple cell values within a geometry

I am provided with 3 tables:
1 - The GeoRaster
2 - The geoRasterData table
3 - A VAT table who's PK is the cell value from the above tables
Currently the user can select a point in our application and by using the getCellValue we get the cell value which is the PK on the 3rd table and this gives us the details to return to the user.
We now want to give the worst scenario within a given geometry or distance. So if I get back all the cell values within a given geometry/distance I can then call my other functions against the 3rd table to get the worst scores.
I had a conversation open for this before where JeffreyXie had some brilliant input, but it got archived while I was waiting on Oracle to resolve a bug (about 7 months)
See:
Trying to get multiple cell values within a geometry
If I am looking to get a list of cell values that interact with my geometry/distance and then loop through them, is there a better way?
BTW, if anybody wants to play with this functionality, it only seems to work in 11.2.0.4.
Below is the code I was using last, I think it is trying to get the cell values but the numbers coming back are not correct, I think I am converting the binary to integer wrong.
Any ideas?
CREATE OR REPLACE FUNCTION GEOSUK.getCellValuesInGeom_FNC RETURN VARCHAR2 AS
gr sdo_georaster;
lb blob;
win1 sdo_geometry;
win2 sdo_number_array;
status VARCHAR2(1000) := NULL;
CDP varchar2(80);
FLT number := 0;
cdl number;
vals varchar2(32000) := null;
VAL number;
amt0 integer;
amt integer;
off integer;
len integer;
buf raw(32767);
MAXV number := null;
r1 raw(1);
r2 raw(2);
r4 raw(200);
r8 raw(8);
MATCH varchar2(10) := '';
ROW_COUNT integer := 0;
COL_COUNT integer := 0;
ROW_CUR integer := 0;
COL_CUR integer := 0;
CUR_XOFFSET integer := 0;
CUR_YOFFSET integer := 0;
ORIGINY integer := 0;
ORIGINX integer := 0;
XOFF number(38,0) := 0;
YOFF number(38,0) := 0;
BEGIN
status := '1';
SELECT a.georaster INTO gr FROM JBA_MEGARASTER_1012 a WHERE id=1;
-- first figure out the celldepth from the metadata
cdp := gr.metadata.extract('/georasterMetadata/rasterInfo/cellDepth/text()',
'xmlns=http://xmlns.oracle.com/spatial/georaster').getStringVal();
if cdp = '32BIT_REAL' then
flt := 1;
end if;
cdl := sdo_geor.getCellDepth(gr);
if cdl < 8 then
-- if celldepth<8bit, get the cell values as 8bit integers
cdl := 8;
end if;
dbms_lob.createTemporary(lb, TRUE);
status := '2';
-- querying/clipping polygon
win1 := SDO_GEOM.SDO_BUFFER(SDO_GEOMETRY(2001,27700,MDSYS.SDO_POINT_TYPE(473517,173650.3, NULL),NULL,NULL), 10, .005);
status := '1.2';
sdo_geor.getRasterSubset(gr, 0, win1, '1',
lb, win2, NULL, NULL, 'TRUE');
-- Then work on the resulting subset stored in lb.
status := '2.3';
DBMS_OUTPUT.PUT_LINE ( 'cdl: '||cdl );
len := dbms_lob.getlength(lb);
cdl := cdl / 8;
-- make sure to read all the bytes of a cell value at one run
amt := floor(32767 / cdl) * cdl;
amt0 := amt;
status := '3';
ROW_COUNT := (WIN2(3) - WIN2(1))+1;
COL_COUNT := (WIN2(4) - WIN2(2))+1;
--NEED TO FETCH FROM RASTER
ORIGINY := 979405;
ORIGINX := 91685;
--CALCUALATE BLOB AREA
YOFF := ORIGINY - (WIN2(1) * 5); --177005;
XOFF := ORIGINX + (WIN2(2) * 5); --530505;
status := '4';
--LOOP CELLS
off := 1;
WHILE off <= LEN LOOP
dbms_lob.read(lb, amt, off, buf);
for I in 1..AMT/CDL LOOP
if cdl = 1 then
r1 := utl_raw.substr(buf, (i-1)*cdl+1, cdl);
VAL := UTL_RAW.CAST_TO_BINARY_INTEGER(R1);
elsif cdl = 2 then
r2 := utl_raw.substr(buf, (i-1)*cdl+1, cdl);
val := utl_raw.cast_to_binary_integer(r2);
ELSIF CDL = 4 then
IF (((i-1)*cdl+1) + cdl) > len THEN
r4 := utl_raw.substr(buf, (i-1)*cdl+1, (len - ((i-1)*cdl+1)));
ELSE
r4 := utl_raw.substr(buf, (i-1)*cdl+1, cdl+1);
END IF;
if flt = 0 then
val := utl_raw.cast_to_binary_integer(r4);
else
val := utl_raw.cast_to_binary_float(r4);
end if;
elsif cdl = 8 then
r8 := utl_raw.substr(buf, (i-1)*cdl+1, cdl);
val := utl_raw.cast_to_binary_double(r8);
end if;
if MAXV is null or MAXV < VAL then
MAXV := VAL;
end if;
IF i = 1 THEN
VALS := VALS || VAL;
ELSE
VALS := VALS ||'|'|| VAL;
END IF;
end loop;
off := off+amt;
amt := amt0;
end loop;
dbms_lob.freeTemporary(lb);
status := '5';
RETURN VALS;
EXCEPTION
WHEN OTHERS THEN
RAISE_APPLICATION_ERROR(-20001, 'GENERAL ERROR IN MY PROC, Status: '||status||', SQL ERROR: '||SQLERRM);
END;

Hey guys,
Zzhang,
That's a good spot and as it happens I spotted that and that is why I am sure I am querying that lob wrong. I always get the a logic going past the total length of the lob.
I think I am ok using 11.2.0.4, if I can get this working it is really important to us, so saying to roll up to 11.2.0.4 for this would be no problem.
The error in 11.2.0.3 was an internal error: [kghstack_underflow_internal_3].
Something that I think I need to find out more about, but am struggling to get more information on is, I am assuming that the lob that is returned is all cell values or at lest an array of 4 byte (32 bit) chunks, although, I don't know this.
Is that a correct assumption or is there more to it?
Have either of you seen any documentation on how to query this lob?
Thanks

Getting end-of-file on communication channel error on this query

Hi guys,
I'm getting the end-of-file on communcation channel error when running the following query in SQL PLUS, If run it in a stored procedure called through code of JDBC, it gave "no more data to read from socket" error. Any idea what went wrong? kind of frustrated now. We are using the Oralce 9.0.1.4.0, which suppose to fix some sdo_uion and sdo_buffer bugs. Thanks a lot!!
select SDO_GEOM.SDO_BUFFER((SELECT SDO_AGGR_UNION(MDSYS.SDOAGGRTYPE(GEOLOC, 0.011119487)) FROM GEOTEL_SOURCE where MSA='5000' and COMPANY_NAME ='AMERICAN FIBER SYSTEMS'),1.0,5,'unit=MILE arc_tolerance=0.05') from GEOTEL_SOURCE a where a.MI_PRINX = 1;

Hi Daniel,
Just tried the 9.2.0.2 patch, seems to work better now. At least I don't get the end-of-file on communication channel error. But how about the speed thing? I isolated the problem, and find out that sdo_aggr_union is taking too long to finish( 1 Hour!!! for 2300 lines with the same city. Any clue to optimize it, I tried some hint like /*+ordered*/ No_Merge and something like that, does not improve though. Thanks!

Not using Index when SDO_RELATE in Spatial Query is used in LEFT OUTER JOIN

I want to know for every City (Point geometry) in which Municipality (Polygon geometry) it is.
Some cities will not be covered by any municipality (as there is no data for it), so its municipality name should be blank in the result
We have 4942 cities (point geometries)
and 500 municipalities (polygon geometry)
SELECT T1.NAME as City, T2.NAME as Municipality
FROM CITY T1
LEFT OUTER JOIN MUNICIPALITY T2 ON SDO_RELATE(T1.GEOM, T2.GEOM, 'MASK=ANYINTERACT') = 'TRUE'The explain plan for this query is:
SELECT STATEMENT
FILTER
    Filter Predicates
      MDSYS.SDO_RTREE_RELATE(T1.GEOM, T2.GEOM, 'mask=ANYINTERACT querytype=window ') = 'TRUE'
    MERGE JOIN
      TABLE ACCESS              CITY               FULL                            11
      BUFFER                                       SORT                        100605
          TABLE ACCESS          MUNICIPALITY       FULL                            20So the cost is in the BUFFER (whatever that is), it takes +2000 seconds to run this, it is not using the spatial index.
And we are not getting all rows, but only the ones interacting with a municipality, e.g. 2436 rows.
But I want all rows, including the ones not interacting with any Municipality.
When we want only those cities that actually are in a municipality, I use a different query and it will use the index.
SELECT T1.NAME as City, T2.NAME as Municipality
FROM CITY T1, MUNICIPALITY T2
WHERE SDO_RELATE(T1.GEOM, T2.GEOM, 'MASK=ANYINTERACT') = 'TRUE'I get (only) 2436 rows (as expected) in 5 seconds (it is fast) and the explain plan shows it is using the spatial index.
But in this case, I am not getting any cities not inside any municipality (of course)
SELECT STATEMENT
   NESTED LOOPS
      TABLE ACCESS                   MUNICIPALITY       FULL                22
      TABLE ACCESS                   CITY               BY INDEX ROWID      22
         DOMAIN INDEX                CITY_SDX                                0
            Access Predicates
               MDSYS.SDO_RTREE_RELATE(T1.GEOM, T2.GEOM, 'mask=ANYINTERACT querytype=window ') = 'TRUE'I always thought a LEFT OUTER JOIN would return all rows from the Table, whatever happens in the next,
but it seems the query has been rewritten so that it is now using a Filter Predicate in the end, which filters those geometries having no interaction.
As an example I also do thing alphanumerically, I do get 4942 rows, including the ones which have no Municipality name.
In this case the names must match, so its only for testing if the LEFT OUTER JOIN returns stuff correctly, which it does in this case.
SELECT T1.NAME as City, T2.NAME as Municipality
FROM CITY T1
LEFT OUTER JOIN MUNICIPALITY T2 ON T1.NAME = T2.NAMEIs this an Oracle Spatial bug, e.g. not return 4942 rows, but only 2436 rows on the first query?
Note all tests performed on Oracle 11g R2 (11.2.0.1.0)

Patrick,
Even so, your geoms in the relate were the wrong way around.
Also, I don't recall you saying (or showing) that you wanted the municipality geometry returned. Still,
no matter, easy to do.
Here are some additional suggestions. I don't have your data so I have had to use some of my own.
set serveroutput on timing on autotrace on
SELECT T1.SPECIES as City,
       (SELECT T2.ADMIN_NAME FROM AUSTRALIAN_STATES T2 WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE') as Municipality,
       (SELECT T2.GEOM       FROM AUSTRALIAN_STATES T2 WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE') as geom
FROM GUTDATA T1;
762 rows selected
Elapsed: 00:00:21.656
Plan hash value: 2160035213
| Id | Operation                   | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |                            |   762 | 49530 |     5   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| AUSTRALIAN_STATES          |     1 |   115 |     0   (0)| 00:00:01 |
|* 2 |   DOMAIN INDEX              | AUSTRALIAN_STATES_GEOM_SPX |       |       |     0   (0)| 00:00:01 |
|   3 | TABLE ACCESS BY INDEX ROWID| AUSTRALIAN_STATES          |     1 |   115 |     0   (0)| 00:00:01 |
|* 4 |   DOMAIN INDEX              | AUSTRALIAN_STATES_GEOM_SPX |       |       |     0   (0)| 00:00:01 |
|   5 | TABLE ACCESS FULL          | GUTDATA                    |   762 | 49530 |     5   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
   4 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
   Statistics
               7 user calls
           24576 physical read total bytes
               0 physical write total bytes
               0 spare statistic 3
               0 commit cleanout failures: cannot pin
               0 TBS Extension: bytes extended
               0 total number of times SMON posted
               0 SMON posted for undo segment recovery
               0 SMON posted for dropping temp segment
               0 segment prealloc tasksThe above can look messy as you add more (SELECT ...) attributes, but is is fast (though can't use in Materialized Views).
/* The set of all cities not in municipalities */
SELECT T1.SPECIES                 as City,
       cast(null as varchar2(42)) as municipality,
       cast(null as sdo_geometry) as geom
FROM GUTDATA T1
WHERE NOT EXISTS (SELECT 1
                     FROM AUSTRALIAN_STATES T2
                    WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
UNION ALL
/* The set of all cities in municipalities */
SELECT T1.SPECIES    as City,
       T2.ADMIN_NAME as Municipality,
       T2.GEOM       as geom
FROM GUTDATA T1
       INNER JOIN
       AUSTRALIAN_STATES T2 ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');
762 rows selected
Elapsed: 00:00:59.953
Plan hash value: 2854682795
| Id | Operation           | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT    |                            |    99 | 13450 |    38 (87)| 00:00:01 |
|   1 | UNION-ALL          |                            |       |       |            |          |
|* 2 |   FILTER            |                            |       |       |            |          |
|   3 |    TABLE ACCESS FULL| GUTDATA                    |   762 | 49530 |     5   (0)| 00:00:01 |
|* 4 |    DOMAIN INDEX     | AUSTRALIAN_STATES_GEOM_SPX |       |       |     0   (0)| 00:00:01 |
|   5 |   NESTED LOOPS      |                            |    61 | 10980 |    33   (0)| 00:00:01 |
|   6 |    TABLE ACCESS FULL| AUSTRALIAN_STATES          |     8 |   920 |     3   (0)| 00:00:01 |
|* 7 |    TABLE ACCESS FULL| GUTDATA                    |     8 |   520 |     4   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter( NOT EXISTS (SELECT 0 FROM "AUSTRALIAN_STATES" "T2" WHERE "MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE'))
   4 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
   7 - filter("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
   Statistics
               7 user calls
          131072 physical read total bytes
               0 physical write total bytes
               0 spare statistic 3
               0 commit cleanout failures: cannot pin
               0 TBS Extension: bytes extended
               0 total number of times SMON posted
               0 SMON posted for undo segment recovery
               0 SMON posted for dropping temp segment
               0 segment prealloc tasksMuch slower but Materialized View friendly.
This one is a bit more "natural" but still slower than the first.
set serveroutput on timing on autotrace on
/* The set of all cities in municipalities */
WITH municipal_cities As (
SELECT T1.ID         as City,
         T2.ADMIN_NAME as Municipality,
         T2.GEOM       as geom
    FROM GUTDATA T1
         INNER JOIN
         AUSTRALIAN_STATES T2 ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
SELECT T1.ID           as City,
       T2.Municipality as Municipality,
       T2.GEOM         as geom
FROM GUTDATA          T1
       LEFT OUTER JOIN
       municipal_cities T2
       ON (T2.CITY = T1.ID);
762 rows selected
Elapsed: 00:00:50.228
Plan hash value: 745978991
| Id | Operation             | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT      |                   |   762 | 44196 |    36   (3)| 00:00:01 |
|* 1 | HASH JOIN RIGHT OUTER|                   |   762 | 44196 |    36   (3)| 00:00:01 |
|   2 |   VIEW                |                   |    61 | 3294 |    33   (0)| 00:00:01 |
|   3 |    NESTED LOOPS       |                   |    61 | 10980 |    33   (0)| 00:00:01 |
|   4 |     TABLE ACCESS FULL | AUSTRALIAN_STATES |     8 |   920 |     3   (0)| 00:00:01 |
|* 5 |     TABLE ACCESS FULL | GUTDATA           |     8 |   520 |     4   (0)| 00:00:01 |
|   6 |   INDEX FAST FULL SCAN| GUTDATA_ID_PK     |   762 | 3048 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("T2"."CITY"(+)="T1"."ID")
   5 - filter("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
   Statistics
               7 user calls
           49152 physical read total bytes
               0 physical write total bytes
               0 spare statistic 3
               0 commit cleanout failures: cannot pin
               0 TBS Extension: bytes extended
               0 total number of times SMON posted
               0 SMON posted for undo segment recovery
               0 SMON posted for dropping temp segment
               0 segment prealloc tasksFinally, the Pièce de résistance: trick the LEFT OUTER JOIN operator...
set serveroutput on timing on autotrace on
SELECT T1.SPECIES    as City,
       T2.ADMIN_NAME as Municipality,
       T2.GEOM       as geom
FROM GUTDATA           T1
       LEFT OUTER JOIN
       AUSTRALIAN_STATES T2
       ON (t2.admin_name = to_char(t1.ID) OR
           SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');
762 rows selected
Elapsed: 00:00:50.273
Plan hash value: 158854308
| Id | Operation           | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT    |                   |   762 | 92964 | 2294   (1)| 00:00:28 |
|   1 | NESTED LOOPS OUTER |                   |   762 | 92964 | 2294   (1)| 00:00:28 |
|   2 |   TABLE ACCESS FULL | GUTDATA           |   762 | 49530 |     5   (0)| 00:00:01 |
|   3 |   VIEW              |                   |     1 |    57 |     3   (0)| 00:00:01 |
|* 4 |    TABLE ACCESS FULL| AUSTRALIAN_STATES |     1 |   115 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - filter("T2"."ADMIN_NAME"=TO_CHAR("T1"."ID") OR
              "MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
   Statistics
               7 user calls
               0 physical read total bytes
               0 physical write total bytes
               0 spare statistic 3
               0 commit cleanout failures: cannot pin
               0 TBS Extension: bytes extended
               0 total number of times SMON posted
               0 SMON posted for undo segment recovery
               0 SMON posted for dropping temp segment
               0 segment prealloc tasksTry these combinations to see what works for you.
Interestingly, for me, the following returns absolutely nothing.
SELECT T1.SPECIES    as City,
       T2.ADMIN_NAME as Municipality
FROM GUTDATA           T1
       LEFT OUTER JOIN
       AUSTRALIAN_STATES T2
       ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
MINUS
SELECT T1.SPECIES    as City,
       T2.ADMIN_NAME as Municipality
FROM GUTDATA           T1
       LEFT OUTER JOIN
       AUSTRALIAN_STATES T2
       ON (t2.admin_name = to_char(t1.ID) OR
           SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');(I leave it to you to see if you can see why as the LEFT OUTER JOIN seems to be working correctly for me but I am not going to dedicate time to detailed checking of results.)
Note all tests performed on Oracle 11g R2 (11.2.0.1.0)
If you get the answer you want: mark the post as answered to assign points.
regards
Simon

A bizarre ORA-13349 case in 9i

Hi all,
We have just migrated from 8.17 to 9.2 and encountered a rather strange validation error on a particular polygon geometry.
Subject Geometry:
Parcel polygon composed of 4 polylines and 3 arcs.
Validation SQL:
SELECT SDO_GEOM.VALIDATE_GEOMETRY(SPATIALAREA, mtolerance) FROM PARCEL835105;
Error:
ORA-13349 (polygon boundary crosses itself) ONLY occurs when mtolerance is between 0.05 and 0.009. The geometry is considered fine when mtolerance is above 0.06 or below 0.008
Observation:
We examined the polygon using GeoMedia tool by traversing its vertices and could not find any apparent error.
If you want to try the geometry you may create the following files by cutting-&-pasting the content underneath each file heading. Then run at the system prompt (DOS) IMPORT.BAT usr/pass@connectionstring.
Bo Guo
Maricopa County Assessor's Office
Phoenix, AZ
602-506-0930
**************** PARCEL835105.DAT ********
1525|2003| |pt||||1|1005|7|1|2|1|5|2|2|9|2|2|13|2|1|15|2|2|19|2|1|21|2|1|;658946.23100000003|870467.35999999999|658884.96200000006|870464.85400000005|658829.65517262102|870462.59209484397|658778.28773826023|870459.781195155|658727.01800000004|870455.54700000002|658692.40116387932|870451.87949395797|658657.85900000005|870447.56499999994|658657.79700328002|870442.51112167106|658743.64884854865|870452.05702360102|658829.85199999996|870457.59600000002|658941.16799999995|870462.14899999998|658946.23100000003|870467.35999999999|:||||
**************** PARCEL835105.PRE ********
CREATE TABLE PARCEL835105 (
ID NUMBER(10,0),
SPATIALAREA MDSYS.SDO_GEOMETRY,
APN VARCHAR2(12),
FLOOR NUMBER(10,0),
DGN VARCHAR2(12),
SOURCE_CD VARCHAR2(2), primary key (ID) );
Exit;
**************** PARCEL835105.POS ********
insert into USER_SDO_GEOM_METADATA values('PARCEL835105', 'SPATIALAREA' ,MDSYS.SDO_DIM_ARRAY( MDSYS.SDO_DIM_ELEMENT('X', 232850, 993600, 0.03), MDSYS.SDO_DIM_ELEMENT('Y', 526000, 1134000, 0.03)), NULL );
Commit;
Exit;
**************** PARCEL835105.CTL ********
LOAD DATA
INFILE 'PARCEL835105.Dat'
APPEND INTO TABLE PARCEL835105
FIELDS TERMINATED BY '|' OPTIONALLY ENCLOSED BY '"'
TRAILING NULLCOLS
ID,
SPATIALAREA COLUMN OBJECT
( sdo_gtype INTEGER EXTERNAL,
sdo_srid INTEGER EXTERNAL,
isnull FILLER CHAR,
SDO_POINT COLUMN OBJECT NULLIF SPATIALAREA.isnull="pt"
( X INTEGER EXTERNAL,
Y INTEGER EXTERNAL,
Z INTEGER EXTERNAL),
SDO_ELEM_INFO VARRAY terminated by ';'
(SDO_ORDINATES char(38)),
SDO_ORDINATES VARRAY terminated by ':'
(SDO_ORDINATES char(38))) ,
APN,
FLOOR,
DGN,
SOURCE_CD )
**************** IMPORT.BAT********
@echo off
REM Copyright (c) 1999-2002 by Intergraph Corporation. All Rights Reserved.
Rem Use this script to create tables and metadata with PL/SQL and populate tables with SQL*Loader.
if "%1"=="" goto usage
SQLPLUS %1 @"PARCEL835105.PRE"
SQLLDR %1 CONTROL= PARCEL835105
SQLPLUS %1 @"PARCEL835105.POS"
goto end
: usage
@echo Syntax of the command is: "Import <username>/<password>@<ConnectString>"
echo Examples:
echo Import scott/tiger@db_orcl
: end
pause

Doc ID: Note:1020247.102,Subject: Validating Geometry Returns ORA-13349 or ORA-13356 [published @ metalink]
Problem Description:
====================
Validating geometries for polygons in the Spatial Data Cartridge, may give: ORA-13349: polygon boundary crosses itself or ORA-13356 adjacent points in a geometry are redundant However, examining the polygon data shows that there are no crossing lines and no redundant points. This error may also be raised by SDO_BUFFER, which will appear to create an invalid polygon. Solution
Description:
=====================
This is caused by the SDO_TOLERANCE being set to an inappropriate value for the data in the layer. The tolerance will be taken into account when validating whether two points are the same or if two lines cross.
Explanation:
============
SDO_VALIDATE_GEOMETRY generates an ORA-13349 when it detects that the geometric properties of the data are incorrect, and that the shape crosses itself. The reason for the errors is that the buffer function sometimes needs to generate very small shapes, typically circular arcs. There are situations where the ordinates generated have a precision higher than the SDO_TOLERANCE setting. Once rounded using the SDO_TOLERANCE setting, then it is possible that the shape appears to cross itself (ORA-13349). Setting the tolerance to 0.0 will remove the errors, since rounding will no longer happen. An simple example is if there are two points on the polygon: 2.60, 3.00 and 2.56, 3.00 with the tolerance set to .05 When rounded these will both appear to be 2.6, 3.00 and give the ORA-13356 error. Setting the tolerance to .005 would avoid this error. For SDO_BUFFER this error should not be reported from 8.1.6 onwards.

SDO_BUFFER & multlinestring

Similar Messages

Maybe you are looking for