Geodetic spatial queries - sdo_relate
Hello,
The following script populates a spatial table with points on a query boundary and then queries that table using the query boundary. When using a srid of 8307 not all of the points are returned using sdo_relate. If the srid is NULL then all points 'on' the query boundary are returned.
In https://metalink.oracle.com/metalink/plsql/f?p=130:15:2437246749596129570
there is the statement...
"In a geodetic system, if there is a line defined from lat: 50, long: 30, lat:50, long: 35 that line does not go along the latitude 50 parallel.
Only the two end points will be at lat: 50, all the other interior points on that line will have a latitude value more than 50.
Due to this reason, the points along the lat: 50 are not part of the query window. "
Does anyone know the reasoning behind this statement? How can I determine what the interior points would be between a line defined as start point lat: 50, long: 30 to end point lat:50, long: 35?
Thanks in advance,
Rick
========= Script follows ============
geomdetic relate test case
This script demonstrates cases where sdo_relate, in a geodetic coordate system where
"A two point line on a given meridian, doesn't necessarily follow that meridian,
so any feature touching that meridian between those two points is not necessarily
touching that line""
The script generates an input query boundary using max and min values. It inserts
point features on the query boundary at input interval into a test table. '
A spatial query is executed against the test table using the query boundary.
DECLARE
TYPE ord_type IS TABLE OF NUMBER
INDEX BY BINARY_INTEGER;
x_tab ord_type;
y_tab ord_type;
maxlon NUMBER DEFAULT 65;
minlon NUMBER DEFAULT 64;
maxlat NUMBER DEFAULT 45 ;
minlat NUMBER DEFAULT 44;
INCREMENT NUMBER DEFAULT 0.001;
offset number default 0;
srid number default 8307;
curval NUMBER;
objectnotexists EXCEPTION;
PRAGMA EXCEPTION_INIT (objectnotexists, -942);
indexnotexists EXCEPTION;
PRAGMA EXCEPTION_INIT (indexnotexists, -1418);
PROCEDURE populate_array (
p_minval IN NUMBER,
p_maxval IN NUMBER,
p_increment IN NUMBER,
p_array IN OUT ord_type
IS
i BINARY_INTEGER DEFAULT 0;
BEGIN
curval := p_minval;
LOOP
p_array (i) := curval;
curval := curval + INCREMENT;
i := i + 1;
EXIT WHEN curval > p_maxval;
END LOOP;
END populate_array;
PROCEDURE insert_points_on_tangent (
p_tangent IN NUMBER,
p_ords IN ord_type,
orientation IN VARCHAR
IS
v_geom MDSYS.SDO_GEOMETRY;
i BINARY_INTEGER;
BEGIN
i := p_ords.FIRST; -- get subscript of first element
WHILE i IS NOT NULL
LOOP
IF orientation = 'Y'
THEN
v_geom :=
MDSYS.SDO_GEOMETRY (2001,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1, 1),
MDSYS.sdo_ordinate_array (p_tangent,
p_ords (i)
ELSE
v_geom :=
MDSYS.SDO_GEOMETRY (2001,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1, 1),
MDSYS.sdo_ordinate_array (p_ords (i),
p_tangent
END IF;
EXECUTE IMMEDIATE 'insert into sdo_relate_geom_test (geom, geom_type) values (:boundary, :geom_tag)'
USING v_geom, orientation || ' ' || i;
i := p_ords.NEXT (i); -- get subscript of next element
END LOOP;
END insert_points_on_tangent;
-- Create a table to hold the geometries.
PROCEDURE TEST
IS
v_geom MDSYS.SDO_GEOMETRY
DEFAULT MDSYS.SDO_GEOMETRY (2003,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1003, 1),
MDSYS.sdo_ordinate_array (minlon,
minlat,
maxlon,
minlat,
maxlon,
maxlat,
minlon,
maxlat,
minlon,
minlat
v_viewportgeom MDSYS.SDO_GEOMETRY
DEFAULT MDSYS.SDO_GEOMETRY (2003,
0,
NULL,
MDSYS.sdo_elem_info_array (1, 1003, 1),
MDSYS.sdo_ordinate_array (minlon,
minlat,
maxlon,
minlat,
maxlon,
maxlat,
minlon,
maxlat,
minlon,
minlat
v_expected NUMBER;
v_relate_results NUMBER;
v_filter_results NUMBER;
v_relate_results_arc NUMBER;
v_dimino MDSYS.SDO_DIM_ARRAY;
v_count_sql VARCHAR2 (1000)
DEFAULT 'select count(*) from sdo_relate_geom_test';
v_filter_sql VARCHAR2 (1000)
DEFAULT 'SELECT count(*) '
|| ' FROM sdo_relate_geom_test '
|| ' WHERE MDSYS.sdo_filter '
|| ' (geom, '
|| ' :ingeom, '
|| ' ''MASK= ANYINTERACT QUERYTYPE=WINDOW'' '
|| ' ) = ''TRUE'' ';
v_relate_sql VARCHAR2 (1000)
DEFAULT 'SELECT count(*) '
|| ' FROM sdo_relate_geom_test '
|| ' WHERE MDSYS.sdo_relate '
|| ' (geom, '
|| ' :ingeom, '
|| ' ''MASK= ANYINTERACT QUERYTYPE=WINDOW'' '
|| ' ) = ''TRUE'' ';
BEGIN
EXECUTE IMMEDIATE v_count_sql
INTO v_expected;
EXECUTE IMMEDIATE v_filter_sql
INTO v_filter_results
USING v_geom;
EXECUTE IMMEDIATE v_relate_sql
INTO v_relate_results
USING v_geom;
DBMS_OUTPUT.put_line ( ' boundary minLat '
|| minlat
|| ' minLon '
|| minlon
|| ' maxLat '
|| maxlat
|| ' maxLon '
|| maxlon
||' increment '
|| INCREMENT
DBMS_OUTPUT.put_line ( 'expected '
|| v_expected
|| ' relate returned '
|| v_relate_results
|| ', '
|| 'filter returned '
|| v_filter_results
|| '. '
DBMS_OUTPUT.put_line('');
END TEST;
BEGIN
BEGIN
EXECUTE IMMEDIATE 'drop table sdo_relate_geom_test';
EXCEPTION
WHEN objectnotexists
THEN
NULL;
END;
EXECUTE IMMEDIATE 'create table sdo_relate_geom_test(geom mdsys.sdo_geometry, geom_type VARCHAR2(100))';
-- generate the points we want to test
populate_array (minlon, maxlon, INCREMENT, x_tab);
populate_array (minlat, maxlat, INCREMENT, y_tab);
-- insert the points on the query boundary
insert_points_on_tangent (minlon + offset, y_tab, 'Y');
insert_points_on_tangent (maxlon - offset, y_tab, 'Y');
insert_points_on_tangent (minlat + offset, x_tab, 'X');
insert_points_on_tangent (maxlat - offset, x_tab, 'X');
DELETE user_sdo_geom_metadata
WHERE table_name = 'SDO_RELATE_GEOM_TEST';
INSERT INTO user_sdo_geom_metadata
(table_name, column_name,
diminfo,
srid
VALUES ('SDO_RELATE_GEOM_TEST', 'GEOM',
MDSYS.sdo_dim_array (MDSYS.sdo_dim_element ('x',
-180,
180,
.00000005
MDSYS.sdo_dim_element ('y',
-90,
90,
.00000005
srid
BEGIN
EXECUTE IMMEDIATE 'drop index SDO_RELATE_GEOM_TEST_spa_idx';
EXCEPTION
WHEN indexnotexists
THEN
NULL;
END;
EXECUTE IMMEDIATE 'create index SDO_RELATE_GEOM_TEST_spa_idx on SDO_RELATE_GEOM_TEST(geom) indextype is mdsys.spatial_index';
TEST;
END;
/
In https://metalink.oracle.com/metalink/plsql/f?p=130:15:2437246749596129570
there is the statement...
"In a geodetic system, if there is a line defined from lat: 50, long: 30, lat:50, long: 35 that line does not go along the latitude 50 parallel.
Only the two end points will be at lat: 50, all the other interior points on that line will have a latitude value more than 50.
Due to this reason, the points along the lat: 50 are not part of the query window. "
Does anyone know the reasoning behind this statement? How can I determine what the interior points would be between a line defined as start point lat: 50, long: 30 to end point lat:50, long: 35?
In Oracle Spatial's support for geodetic coordinates, the line segments connecting consecutive vertices of a polygon or line string are geodesics - the shortest paths between the vertices on the earth spheroid. The shortest path between {30, 50} and {35, 50) does not coincide with the 50 latitude parallel, but goes to higher latitude. Only at the equator does the geodesic connecting points of constant latitude coincide with the latitude parallel.
Similar Messages
-
Spatial Queries Not Always Producing Accurate Results
Hi,
Spatial queries are not always producing accurate results. Here are the issues. We would appreciate any clarification you could provide to resolve these issues.
1. When querying for points inside a polygon that is not an MBR (minimum bounded rectangle), some of the coordinates returned are not inside the polygon. It is as though the primary filter is working, but not the secondary filter when using sdo_relate. How can we validate that the spatial query using sdo_relate is using the secondary filter?
2. SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT returns true when validating geometries even though we find results that are invalid.
3. Illegal geodetic coordinates can be inserted into a table: latitude > 90.0, latitude < -90.0, longitude > 180.0 or longitude < -180.0.
4. Querying for coordinates outside the MBR for the world where illegal coordinates existed did NOT return any rows, yet there were coordinates of long, lat: 181,91.
The following are examples and information relating to the above-referenced points.
select * from USER_SDO_GEOM_METADATA
TABLE_NAME COLUMN_NAME DIMINFO(SDO_DIMNAME, SDO_LB, SDO_UB, SDO_TOLERANCE) SRID
LASTKNOWNPOSITIONS THE_GEOM SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05), SDO_DIM_ELEMENT('Y', -90, 90, .05)) 8307
POSITIONS THE_GEOM SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -180, 180, .05), SDO_DIM_ELEMENT('Y', -90, 90, .05)) 8307
Example 1: Query for coordinates inside NON-rectangular polygon includes points outside of polygon.
SELECT l.vesselid, l.latitude, l.longitude, TO_CHAR(l.observationtime,
'YYYY-MM-DD HH24:MI:SS') as obstime FROM lastknownpositions l where
SDO_RELATE(l.the_geom,SDO_GEOMETRY(2003, 8307, NULL,
SDO_ELEM_INFO_ARRAY(1, 1003, 1),
SDO_ORDINATE_ARRAY(-98.20268,18.05079,-57.30101,18.00705,-57.08229,
54.66061,-98.59638,32.87842,-98.20268,18.05079)),'mask=inside')='TRUE'
This query returns the following coordinates that are outside of the polygon:
vesselid : 1152 obstime : 2005-08-24 06:00:00 long : -82.1 lat : 45.3
vesselid : 3140 obstime : 2005-08-28 12:00:00 long : -80.6 lat : 44.6
vesselid : 1253 obstime : 2005-08-22 09:00:00 long : -80.0 lat : 45.3
Example 2a: Using SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT
Select areaid, the_geom,
SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(the_geom, 0.005) from area where
areaid=24
ResultSet:
AREAID THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO,
SDO_ORDINATES) SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(THE_GEOM,0.005)
24 SDO_GEOMETRY(2003, 8307, NULL, SDO_ELEM_INFO_ARRAY(1, 1003, 1), SDO_ORDINATE_ARRAY(-98.20268, 18.05079, -57.30101, 18.00705, -57.08229, 54.66061, -98.59638, 32.87842, -98.20268, 18.05079)) TRUE
Example 2b: Using SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT
Select positionid, vesselid, the_geom,
SDO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(the_geom, 0.005) from positions where vesselid=1152
ResultSet:
POSITIONID VESSELID THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z),
SDO_ELEM_INFO, SDO_ORDINATES) DO_GEOM.VALIDATE_GEOMETRY_WITH_CONTEXT(THE_GEOM,0.005)
743811 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-82.1, 45.3, NULL), NULL, NULL) TRUE
743812 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-82.1, 45.3, NULL), NULL, NULL) TRUE
743813 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-80.2, 42.5, NULL), NULL, NULL) TRUE
743814 1152 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-80.2, 42.5, NULL), NULL, NULL) TRUE
Example 3: Invalid Coordinate values found in POSITIONS table.
SELECT p.positionid, p.latitude, p.longitude, p.the_geom FROM positions p
WHERE p.latitude < -180.0
2 lines from ResultSet:
POSITIONID LATITUDE LONGITUDE THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
714915 -210.85408 -79.74449 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-79.74449, -210.85408, NULL), NULL, NULL)
714938 -211.13632 -79.951256 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-79.951256, -211.13632, NULL), NULL, NULL)
SELECT p.positionid, p.latitude, p.longitude, p.the_geom FROM positions p
WHERE p.longitude > 180.0
3 lines from ResultSet:
POSITIONID LATITUDE LONGITUDE THE_GEOM(SDO_GTYPE, SDO_SRID, SDO_POINT(X, Y, Z), SDO_ELEM_INFO, SDO_ORDINATES)
588434 91 181 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(181, 91, NULL), NULL, NULL)
589493 91 181 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(181, 91, NULL), NULL, NULL)
589494 91 181 SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(181, 91, NULL), NULL, NULL)
Example 4: Failure to locate illegal coordinates by querying for disjoint coordinates outside of MBR for the world:
SELECT p.vesselid, p.latitude, p.longitude, p.the_geom,
TO_CHAR(p.observationtime, 'YYYY-MM-DD HH24:MI:SS') as obstime,
SDO_GEOM.RELATE(p.the_geom, 'determine',
SDO_GEOMETRY(2003, 8307, NULL,SDO_ELEM_INFO_ARRAY(1, 1003, 1),
SDO_ORDINATE_ARRAY(-180.0,-90.0,180.0,-90.0,180.0,90.0,
-180.0,90.0,-180.0,-90.0)), .005) relationship FROM positions p where
SDO_GEOM.RELATE(p.the_geom, 'disjoint', SDO_GEOMETRY(2003, 8307,
NULL,SDO_ELEM_INFO_ARRAY(1, 1003, 1),
SDO_ORDINATE_ARRAY(-180.0,-90.0,180.0,-90.0,180.0,90.0,-80.0,90.0,
-180.0,-90.0)),.005)='TRUE'
no rows selected
Carol SaahHi Carol,
1) I think the results are correct. Note in a geodetic coordinate system adjacent points in a linestring or polygon are connected via geodesics. You are probably applying planar thinking to an ellipsoidal problem! I don't have time to do the full analysis right now, but a first guess is that is what is happening.
2) The query window seems to be valid. I don't think this is a problem.
3) Oracle will let you insert most anything into a table. In the index, it probably wraps. If you validate, I think the validation routines will tell you is is illegal if you use the signature with diminfo, where the coordinate system bounds are included in the validation.
4) Your query window is not valid. Your data is not valid. As the previous reply stated, you need to have valid data. If you think in terms of a geodetic coordinate system, you will realize that -180.0,-90.0 and 180.0,-90.0 are really the same point. Also, Oracle has a rule that polygon geometries cannot be greater than half the surface of the Earth.
Hope this helps. -
Spatial Queries are CPU bound and show very heavy use of query buffers
Hi,
Spatial Queries:
When using tkprof to analyse spatial queries it is clear that
there are implicit queries being done by Oracle spatial which
use vast amounts of buffers, and seem unable to cache basic
information from query to query - thus resulting in our machine
being CPU bound when stress testing Oracle Spatial, for example
the example below shows how information which is fixed for a
table and not likely to change very often is being retrieved
inefficiently (note the 26729 query buffers being used to do 6
executions of what should be immediately available!!!):
TKPROF: Release 8.1.7.0.0 - Production on Tue Oct 16 09:43:38
2001
(c) Copyright 2000 Oracle Corporation. All rights reserved.
SELECT ATTR_NO, ATTR_NAME, ATTR_TYPE_NAME, ATTR_TYPE_OWNER
FROM
ALL_TYPE_ATTRS WHERE OWNER = :1 AND TYPE_NAME = :2 ORDER BY
ATTR_NO
call count cpu elapsed disk query rows
Parse 6 0.00 0.01 0 0 0
Execute 6 0.00 0.01 0 0 0
Fetch 6 0.23 0.41 0 26729 5
total 18 0.23 0.43 0 26729 5
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 37 (NAGYE)
Rows Row Source Operation
0 SORT ORDER BY
0 FILTER
1 NESTED LOOPS
1 NESTED LOOPS
290 NESTED LOOPS
290 NESTED LOOPS
290 NESTED LOOPS
290 NESTED LOOPS
290 TABLE ACCESS FULL ATTRIBUTE$
578 TABLE ACCESS CLUSTER TYPE$
578 TABLE ACCESS CLUSTER TYPE$
578 INDEX UNIQUE SCAN (object id 255)
578 TABLE ACCESS BY INDEX ROWID OBJ$
578 INDEX RANGE SCAN (object id 35)
578 TABLE ACCESS CLUSTER USER$
578 INDEX UNIQUE SCAN (object id 11)
289 TABLE ACCESS BY INDEX ROWID OBJ$
578 INDEX RANGE SCAN (object id 35)
0 TABLE ACCESS CLUSTER USER$
0 INDEX UNIQUE SCAN (object id 11)
0 FIXED TABLE FULL X$KZSPR
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN (object id 101)
error during parse of EXPLAIN PLAN statement
ORA-01039: insufficient privileges on underlying objects of the
view
and again:
SELECT diminfo, nvl(srid,0)
FROM
ALL_SDO_GEOM_METADATA WHERE OWNER = 'NAGYE' AND TABLE_NAME =
NLS_UPPER('TILE_MED_LINES_MBR') AND '"'||COLUMN_NAME||'"'
= '"GEOM"'
call count cpu elapsed disk query
current rows
Parse 20 0.00 0.04 0
0 0 0
Execute 20 0.00 0.00 0
0 0 0
Fetch 20 0.50 0.50 0 5960
100 20
total 60 0.50 0.54 0 5960
100 20
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 37 (NAGYE) (recursive depth: 1)
Rows Row Source Operation
1 FILTER
2 TABLE ACCESS BY INDEX ROWID SDO_GEOM_METADATA_TABLE
2 INDEX RANGE SCAN (object id 24672)
1 UNION-ALL
1 FILTER
1 NESTED LOOPS
1 NESTED LOOPS
1 NESTED LOOPS OUTER
1 NESTED LOOPS OUTER
1 NESTED LOOPS OUTER
1 NESTED LOOPS OUTER
1 NESTED LOOPS
1 TABLE ACCESS FULL OBJ$
1 TABLE ACCESS CLUSTER TAB$
1 INDEX UNIQUE SCAN (object id 3)
0 TABLE ACCESS BY INDEX ROWID OBJ$
1 INDEX UNIQUE SCAN (object id 33)
0 INDEX UNIQUE SCAN (object id 33)
0 TABLE ACCESS CLUSTER USER$
1 INDEX UNIQUE SCAN (object id 11)
1 TABLE ACCESS CLUSTER SEG$
1 INDEX UNIQUE SCAN (object id 9)
1 TABLE ACCESS CLUSTER TS$
1 INDEX UNIQUE SCAN (object id 7)
1 TABLE ACCESS CLUSTER USER$
1 INDEX UNIQUE SCAN (object id 11)
0 FILTER
0 NESTED LOOPS
0 NESTED LOOPS OUTER
0 NESTED LOOPS
0 TABLE ACCESS FULL USER$
0 TABLE ACCESS BY INDEX ROWID OBJ$
0 INDEX RANGE SCAN (object id 34)
0 INDEX UNIQUE SCAN (object id 97)
0 INDEX UNIQUE SCAN (object id 96)
0 FIXED TABLE FULL X$KZSPR
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN (object id 101)
0 FIXED TABLE FULL X$KZSPR
0 NESTED LOOPS
0 FIXED TABLE FULL X$KZSRO
0 INDEX RANGE SCAN (object id 101)
error during parse of EXPLAIN PLAN statement
ORA-01039: insufficient privileges on underlying objects of the
view
Note: The actual query being performed is:
select a.id, a.geom
from
tile_med_lines_mbr a where sdo_relate(a.geom,mdsys.sdo_geometry
(2003,NULL,
NULL,mdsys.sdo_elem_info_array
(1,1003,3),mdsys.sdo_ordinate_array(151.21121,
-33.86325,151.21132,-33.863136)), 'mask=anyinteract
querytype=WINDOW') =
'TRUE'
call count cpu elapsed disk query
current rows
Parse 1 0.00 0.00 0 0 0 0
Execute 1 0.08 0.08 0 4 0 0
Fetch 5 1.62 21.70 0 56 0 827
total 7 1.70 21.78 0 60 0 827
Misses in library cache during parse: 0
Optimizer goal: CHOOSE
Parsing user id: 37 (NAGYE)
Rows Row Source Operation
827 TABLE ACCESS BY INDEX ROWID TILE_MED_LINES_MBR
828 DOMAIN INDEX
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
827 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF
'TILE_MED_LINES_MBR'
828 DOMAIN INDEX OF 'TILE_MLINES_SPIND'
CPU: none, I/O: none
call count cpu elapsed disk query
current rows
Parse 1 0.00 0.00 0 92
Execute 1 0.00 0.00 0 22
Fetch 1 0.00 0.00 38 236
total 3 0.00 0.00 38 350
Misses in library cache during parse: 1
Optimizer goal: CHOOSE
Parsing user id: 37 (NAGYE)
Rows Row Source Operation
12 TABLE ACCESS BY INDEX ROWID ROADELEMENT_MBR
178 DOMAIN INDEX
Rows Execution Plan
0 SELECT STATEMENT GOAL: CHOOSE
12 TABLE ACCESS GOAL: ANALYZED (BY INDEX ROWID) OF
'ROADELEMENT_MBR'
178 DOMAIN INDEX OF 'RE_MBR_SPIND'
CPU: none, I/O: none
Can Oracle improve the performance of Oracle spatial by
improving the implementation so as to perform alternative
implicit queries so as not to use these vast amounts of memory?
Cheers
Alex EadieHi Ravi,
Thankyou for your reply.
Here are some more details for you:
Yes the queries are cached in that it gets its data from RAM and
not from disk however the number of buffers used internally by
Oracle RDBMS/Spatial is rather large and results in significant
CPU usage (namely > 5000 per query or >40MByte). Which I'm sure
you'd agree? Those numerous internal queries taking >10ms CPU
time each, which is culmulative.
A single real of ours query of will take between 180ms and 580ms
depending on the number of results returned.
An example query is:
select a.id, a.geom
from tile_med_lines_mbr a where sdo_relate
(a.geom,mdsys.sdo_geometry
(2003,NULL, NULL,mdsys.sdo_elem_info_array
(1,1003,3),mdsys.sdo_ordinate_array(151.21121,
-33.86325,151.21132,-33.863136)), 'mask=anyinteract
querytype=WINDOW') = 'TRUE'
Our 500Mhz PC Server database can only execute 3 processes
running these queries simultaneously to go to 100% CPU loaded.
The disk is hardly utilized.
The data is the main roads in Sydney, Australia.
The tables, data and indexes were created as shown below:
1. Create the Oracle tables:
create table tile_med_nodes_mbr (
id number not null,
geom mdsys.sdo_geometry not null,
xl number not null,
yl number not null,
xh number not null,
yh number not null);
create table tile_med_lines_mbr (
id number not null,
fromid number not null,
toid number not null,
geom mdsys.sdo_geometry not null,
xl number not null,
yl number not null,
xh number not null,
yh number not null);
2. Use the sqlldr Oracle loader utility to load the data
into Oracle.
% sqlldr userid=csiro_scats/demo control=nodes.ctl
% sqlldr userid=csiro_scats/demo control=lines.ctl
3. Determine the covering spatial extent for the tile
mosaic and use this to create the geometry metadata.
% sqlplus
SQLPLUS> set numw 12
SQLPLUS> select min(xl), min(yl), max(xh), max(yh)
from (select xl, yl, xh, yh
from tile_med_nodes_mbr union
select xl, yl, xh, yh
from tile_med_lines_mbr);
insert into USER_SDO_GEOM_METADATA
(TABLE_NAME, COLUMN_NAME, DIMINFO)
VALUES ('TILE_MED_NODES_MBR', 'GEOM',
MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('X', 151.21093421,
151.21205421, 0.000000050),
MDSYS.SDO_DIM_ELEMENT('Y', -33.86347146,
-33.86234146, 0.000000050)));
insert into USER_SDO_GEOM_METADATA
(TABLE_NAME, COLUMN_NAME, DIMINFO)
VALUES ('TILE_MED_LINES_MBR', 'GEOM',
MDSYS.SDO_DIM_ARRAY
(MDSYS.SDO_DIM_ELEMENT('X', 151.21093421,
151.21205421, 0.000000050),
MDSYS.SDO_DIM_ELEMENT('Y', -33.86347146,
-33.86234146, 0.000000050)));
4. Validate the data loaded:
create table result
(UNIQ_ID number, result varchar2(10));
execute sdo_geom.validate_layer
('TILE_MED_NODES_MBR','GEOM','ID','RESULT');
select result, count(result)
from RESULT
group by result;
truncate table result;
execute sdo_geom.validate_layer
('TILE_MED_LINES_MBR','GEOM','ID','RESULT');
select result, count(result)
from RESULT
group by result;
drop table result;
5. Fix any problems reported in the result table.
6. Create a spatial index, use the spatial index advisor to
determine the sdo_level.
create index tile_mlines_spind on
tile_med_lines_mbr (geom) indextype is
mdsys.spatial_index parameters
( 'sdo_level=7,initial=1M,next=1M,pctincrease=0');
7. Analyse table:
analyze table TILE_MED_LINES_MBR compute statistics;
8. Find the spatial index table name:
select sdo_index_table, sdo_column_name
from user_sdo_index_metadata
where sdo_index_name in
(select index_name
from user_indexes
where ityp_name = 'SPATIAL_INDEX'
and table_name = 'TILE_MED_LINES_MBR');
9. Analyse spatial index table:
analyze table TILE_MLINES_SPIND_FL7$
compute statistics;
I hope this helps.
Cheers
Alex Eadie -
How to create spatial query (sdo_relate) on 2 views
Hi, I want to create a spatial query in the form of:
select /*+ORDERED*/ column1,column2
from view1,view2
where sdo_relate(view2.geometry,view1.geometry,'mask= ... ')Both views are very fast and return a smal number of rows out of a large dataset. I would expect that running the spatial query on this selection should be fast but when performing the above query it takes quite some time.
It seems that the spatial query is performed on the underlying tables before the views make their selection.
What is a good way to handle this kind of problem? How to make the spatial query to be executed on the resultset of the views?
thanks ReneHi Udo,
Let me tell you a bit more about the requirements of the application.
We have a table with geometries. Some geometries are buildings, others are roads, trees, parking areas, etc.
We let users specify what geometries they are interested in. This can be the type (tree, building) or a list of types, plus some other selection such as type of tree, name of road etc. Based on the specifications the application creates a view that returns exactly the geometries the user is interested in.
Users may not only be interested in just a tree but may be looking for a tree located inside a building, or a building within a certain distance from a road. This then would be the query I am talking about in this post. Two views and a spatial relationship between them.
Depending on the definition of the views and the data currently loaded the number of rows returned by the views will vary. I can't be there all the time making sure that the correct table is queried first and the correct hints are given. This is why we have the CBO. But it seems to do a poor job when it comes to spatial queries.
Rene -
Continual library cache misses in trace file for spatial queries
Hi all,
Could somebody explain to me how the SQL parse engine works for spatial queries.
My understanding is that Oracle creates a hash value for SQL that is parsed with no errors. This hash value is then stored in the library cache ready to be matched against other incoming SQL statements. This provides one of the main reasons for using parametising SQL in languages such as PL/SQL, .Net etc and improves performance on query intensive applications.
However i have noticed that for spatial, any queries except for refreshes of identical ones already sent, the SQL engines re parses the query. This can take upto 0.2 seconds which is causing a performance bottle neck.
When looking at the full trace file of a single spatial query using SDO_FILTER with a query window the amount of additional internal queries that are performed is quiet a lot. Are these additional queries included in the total parse time?
I am wondering why for spatial queries the only way to get a hit in the library cache was to refresh an exact same SQL that had been previously sent?
Thanks
DanielThose additional internal queries are not included in the parse time,
if they are used in the execution time.
Edited by: yhu on Mar 4, 2011 10:52 AM -
Spatial queries using Discoverer 3i
We are looking for a web reporting tool for an Oracle 8i Spatial database. Spatial queries are very important to us. Would it make sense and would it be possible to use Oracle Discoverer 3i? This product does not seem to talk the language of a 'spatial user'.
Thanks Dan,
Presumably, it would currently be possible to use Discoverer on database views with fixed spatial where-clauses. Is that right? If so, would it currently also be possible to have a parameterised spatial where-clause, allowing a user for instance to define the spatial view for his particular region. Does Discoverer somehow allow for this?
null -
Combining 2 spatial queries into 1
Hi there. I want to merge two different spatial queries both of which return a single aspect of what I need. The first query returns the distinct group feature ids of all those geometries falling within a specified tolerance of a particular point, i.e. each geometry belongs to one feature id type:
select distinct a2.cfcc from GEOMETRY_MAP.GEOM_POINT$_TABLE a1,
attribute_map.landmark_table a2 where SDO_WITHIN_DISTANCE
(location, (MDSYS.SDO_GEOMETRY(2001, 8265, MDSYS.SDO_POINT_TYPE(-104.9,39.9,null),NULL, NULL)), 'DISTANCE = 10000')='TRUE'
and a1.land = a2.land order by cfcc;
The following results are returned (one for each feature id) e.g. D43 is the id for schools but many schools may have fallen within the specified distance:
CFCC
D43
D44
D61
D65
The second query returns the feature ids of geometries AND their distances from the specified point and looks as follows:
select distinct a2.cfcc, sdo_geom.sdo_distance(location, b.pgeom, 0.005) distance from GEOMETRY_MAP.GEOM_POINT$_TABLE a1, attribute_map.landmark_table a2, (select MDSYS.SDO_GEOMETRY(2001,8265,MDSYS.SDO_POINT_TYPE(-104.9,39.9,null), NULL, NULL) pgeom from dual)b where a1.land = a2.land and SDO_WITHIN_DISTANCE (location, b.pgeom, 'DISTANCE = 10000')='TRUE' order by cfcc, distance;
The results of this query are:
CFCC DISTANCE
D43 4025.459
D43 5585.05361
D43 5589.70435
D61 7770.4209
D65 6223.59763
D65 7929.03858
As you can see the second query returns not just the feature id but the associated distance of each individual feature of that type. What I would like to do is to merge the two result sets so that only the closest individual feature of a particular type and its distance from the input point is returned, i.e. I only need the closest school as oppose to all the closest schools. Any ideas? Thanks a lot, JoeHi Richard. Thnaks for your reply. I should have mentioned that more than one feature type is returned, i.e. not just schools, and so ROWNUM = 1 would not work in this scenario. Any other ideas. Cheers, Joe
-
Sample SQL code ( Oracle Spatial queries)
Hi All,
Can anyone tell me where can I get sample spatial queries.
Please tell me the urls for spatial queries.
Thank you
AnjuHi All,
Can anyone tell me where can I get sample spatial queries.
Please tell me the urls for spatial queries.
Thank you
AnjuHow about the spatial users guide which is available on
http://technet.oracle.com/doc/inter.815/a67295/toc.htm
It also contains example statements.
There is also a
spatial_users_guide_817.pdf available
Gerjan -
Error while running spatial queries on a table with more than one geometry.
Hello,
I'm using GeoServer with Oracle Spatial database, and this is a second time I run into some problems because we use tables with more than one geometry.
When GeoServer renders objects with more than one geometry on the map, it creates a query where it asks for objects which one of the two geometries interacts with the query window. This type of query always fails with "End of TNS data channel" error.
We are running Oracle Standard 11.1.0.7.0.
Here is a small script to demonstrate the error. Could anyone confirm that they also have this type of error? Or suggest a fix?
What this script does:
1. Create table object1 with two geometry columns, geom1, geom2.
2. Create metadata (projected coordinate system).
3. Insert a row.
4. Create spacial indices on both columns.
5. Run a SDO_RELATE query on one column. Everything is fine.
6. Run a SDO_RELATE query on both columns. ERROR: "End of TNS data channel"
7. Clean.
CREATE TABLE object1
id NUMBER PRIMARY KEY,
geom1 SDO_GEOMETRY,
geom2 SDO_GEOMETRY
INSERT INTO user_sdo_geom_metadata (table_name, column_name, srid, diminfo)
VALUES
'OBJECT1',
'GEOM1',
2180,
SDO_DIM_ARRAY
SDO_DIM_ELEMENT('X', 400000, 700000, 0.05),
SDO_DIM_ELEMENT('Y', 300000, 600000, 0.05)
INSERT INTO user_sdo_geom_metadata (table_name, column_name, srid, diminfo)
VALUES
'OBJECT1',
'GEOM2',
2180,
SDO_DIM_ARRAY
SDO_DIM_ELEMENT('X', 400000, 700000, 0.05),
SDO_DIM_ELEMENT('Y', 300000, 600000, 0.05)
INSERT INTO object1 VALUES(1, SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(500000, 400000, NULL), NULL, NULL), SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(550000, 450000, NULL), NULL, NULL));
CREATE INDEX object1_geom1_sidx ON object1(geom1) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
CREATE INDEX object1_geom2_sidx ON object1(geom2) INDEXTYPE IS MDSYS.SPATIAL_INDEX;
SELECT *
FROM object1
WHERE
SDO_RELATE("GEOM1", SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(500000, 400000, NULL), NULL, NULL), 'MASK=ANYINTERACT') = 'TRUE';
SELECT *
FROM object1
WHERE
SDO_RELATE("GEOM1", SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(500000, 400000, NULL), NULL, NULL), 'MASK=ANYINTERACT') = 'TRUE' OR
SDO_RELATE("GEOM2", SDO_GEOMETRY(2001, 2180, SDO_POINT_TYPE(500000, 400000, NULL), NULL, NULL), 'MASK=ANYINTERACT') = 'TRUE';
DELETE FROM user_sdo_geom_metadata WHERE table_name = 'OBJECT1';
DROP INDEX object1_geom1_sidx;
DROP INDEX object1_geom2_sidx;
DROP TABLE object1;
Thanks for help.This error appears in GeoServer and SQLPLUS.
I have set up a completly new database installation to test this error and everything works fine. I tried it again on the previous database but I still get the same error. I also tried to restart the database, but with no luck, the error is still there. I geuss something is wrong with the database installation.
Anyone knows what could cause an error like this "End of TNS data channel"? -
Memory Leak With Spatial queries
We are using 8.1.6 on NT (4.0) for spatial data queries. We are facing memory leak problems. At the starting our job will run very fast and after some time it will start slipping. I'm monitoring PGA size from v$sessionstat/v$sysstat and it is regularly increasing. Same is the case for memory on NT machine when I'm monitoring thru performance monitor. I have already applied the spatial patch available for 8.1.6 but no improvement.
Please let me know If there is any workaround. When I'm submitting my job in parts and shutdown the database in between then It is releasing all the memory and It is working fine. Without shutting the database it is not relasing the memory even though I stop my spatial data batch job.
nullHi,
Thanks for your responses.
This is the query:
SELECT a.geo_id, mdsys.sdo_geom.sdo_length(
mdsys.sdo_cs.transform(
mdsys.sdo_geometry(2002, 8307, null,
mdsys.sdo_elem_info_array(1,2,1),
mdsys.sdo_ordinate_array(' | |
longi | |
', ' | |
lati | |
a.geo_geometry.sdo_point.x,
a.geo_geometry.sdo_point.y )),
mdsys.sdo_dim_array(mdsys.sdo_dim_element(' | |
'''' | |
'X' | |
'''' | |
',-180,180, .00000005),
mdsys.sdo_dim_element(' | |
'''' | |
'Y' | |
'''' | |
',-90,90, .00000005)), 41004),
.00000005) * 6.213712e-04 distance_in_miles
FROM ' | |
t_name | |
' a
WHERE mdsys.sdo_nn(a.geo_geometry,
mdsys.sdo_geometry(1, 8307,
mdsys.sdo_point_type(' | |
longi | |
', ' | |
lati | |
', null),
null, null),' | |
'''' | |
'SDO_NUM_RES=5' | |
'''' | |
') = ' | |
'''' | |
'TRUE' | |
'''' | |
AND a.geo_id ' | |
filter | |
ORDER BY 2;
Here we are passing the tname and filter dynamically based on certain conditions and the memory leak is almost 100K to 200K per query.
First I tried to closing the session only but that didn't work. Database shutdown is only able to release the memory. I'm monitoring v$sysstat/v$sesstat and size of oracle.exe in NT performance monitor. Please let me know If something else need to be monitor.
Thanks.
Sandeep
null -
Speeding up of spatial Queries - SDO_Intersection
HI, I'm running a basic query - calculating the area of spatial intersection sbetween two polygonal datasets:
select s.Designation, SUM (
sdo_geom.sdo_area(
sdo_geom.sdo_intersection (s.geoloc, m.geoloc, 0.0005),
*0.0005, 'unit = HECTARE')) total_overlap_area*
**from SPA_v s, os_bdyline_mlw m*
where sdo_relate (s.geoloc, m.geoloc, 'mask=overlapbdyintersect') = 'TRUE'
The problem is that the query is taking a long, long time to run > 8 hours
First of all the datasets are quite complex, they've been captured at a scale of 1:2500 and 1:10,000 on the Ordnance Survey British National Grid, (the formerbeing of 1mm accuracy, therefore the tolerances involved).
Spatial Indexes have been created on the Geoloc - (geometry) - column.
Is there anything I can do to speed this query up (I'm going to have to create this for further datasets) - I've tried reducing the tolerances to 0.5, but hten have problems where I get this error messages:
ERROR at line 4:
ORA-13050: unable to construct spatial object
ORA-06512: at "MDSYS.SDO_3GL", line 715
ORA-06512: at "MDSYS.SDO_GEOM", line 3016
ORA-06512: at "MDSYS.SDO_GEOM", line 3065
Any help gretfully received :-)
Thanks,
BruceHi Ivan, thanks for the response.
Yep, I've validated all of the geometries.
There are 21 SPA's in Wales, and am only using the Boundaryline data for Wales - principally because there are far fewer nodes in this dataset than there would be if I had used the Mean Low Water Mark, derived from OS Mastermap (at 1:2500.
Obviously this is going cause some small errors creeping in where the two datsets do not precisely meet, but this would probably be within the acceptable range. The other thing I could do would be to thin the SPA dataset so that it would be at 0.05 tolerance (OS 1:10,000 has a node separation of 10 cm)
Thanks,
Bruce -
Cannot do spatial queries across a view.
I have two tables: MAGPGS, which holds current data, and MAGPGS_HISTORY, which holds historical data. I want to be able to create a view and query BOTH tables at once.
I have another table MPPCCA which contains some geometries, and I want to see how these tables interract.
I can run
select p.gdo_gid,m.gdo_gid
from magpgs p, mppcca m
where mdsys.sdo_relate(p.geom,m.geometry1,
'mask=anyinteract')='TRUE';
and
select p.gdo_gid,m.gdo_gid
from magpgs_history p, mppcca m
where mdsys.sdo_relate(p.geom,m.geometry1,
'mask=anyinteract')='TRUE';
successfully, but when I try and run the same query on a view I get this
SQL> select p.gdo_gid,m.gdo_gid
2 from magpgs_all p, mppcca m
3 where mdsys.sdo_relate(p.geom,m.geometry1,
4 'mask=anyinteract')='TRUE';
select p.gdo_gid,m.gdo_gid
ERROR at line 1:
ORA-13226: interface not supported without a spatial index
ORA-06512: at "MDSYS.MD", line 1723
ORA-06512: at "MDSYS.MDERR", line 8
ORA-06512: at "MDSYS.SDO_3GL", line 58
The MAGPGS_ALL view has been created via EM as
SELECT * FROM MAGPGS
UNION ALL
SELECT * FROM MAGPGS_HISTORY.
Obviously EM has then updated my query with the real column names, and I have subsequently recompiled the view.
Having read previous posts, I have tried my query with an entry for the view in the USER_SDO_GEOM_METADATA table, and without an entry, with the same result.
I have also tried rewriting the SQL as per another previous post which identified a workaround if the query was re-written thus
select p.gdo_gid
from magpgs_all p
where exists (select 1 from mppcca m
where mdsys.sdo_relate(p.geom,m.geometry1,
'mask=anyinteract')='TRUE');
but again, with no success. Does anybody have any idea what else I can try?
MTIA
RobHi Rob,
This is similar to bug 4268528 which I opened a few months ago. I believe it should work, but it is possible that it shouldn't based on the original response. I've updated it with a case that is closer to yours. -
Example Oracle Spatial Queries for NAVTEQ Data
Hi,
I recently installed NAVTEQ RDF data into an Oracle database. I am new to Oracle Spatial and am looking for some example queries using the NAVTEQ data in the Oracle database.
For example, suppose I have a point (latitude,longitude). What are the queries for each of these:
1) find roads or faces within 5 miles of that point;
2) find roads or faces that cover that point
Thanks!
BowdenHi,
There are a lot of of ways to license the data (county, state, country), there are different flavors (mapping, geocoding, and routing), and there are different licensing options for the Oracle platform (user based and cpu/core based). I cannot think of a use case that would approach the cost below.
Feel free to drop me an email (daniel dot abugov at navteq dot com) and we can discuss.
Dan Abugov
NAVTEQ Enterprise Business Development and Consulting -
Hi,
I'm working with a point table with approximately 6100 tuples (each has a point geometry)
When I run the query:
SELECT ID, shape FROM POINT_TAB WHERE SDO_FILTER(shape, MDSYS.SDO_GEOMETRY(2003, 1000001, null, MDSYS.SDO_ELEM_INFO_ARRAY( 1, 1003, 3), MDSYS.SDO_ORDINATE_ARRAY( 568220.418621453, 8628249.80447949, 575257.418621453, 8632873.80447949) ), 'querytype=window') = 'TRUE';
it takes about 12 seconds.
However when I run an equivalent query using the Spatial Index Advisor it takes about 1 second to draw the points on screen.
I've created an R-Tree index on this table.
Please any cues?
Thanks a lot,
Claudio.Hi Daniel,
Here it is the info you´ve requested:
USER_SDO_GEOM_METADATA
table_name: POINT_TAB
column_name: SHAPE
SDO_DIMINFO: SDO_DIM_ARRAY(SDO_DIM_ELEMENT('X', -47302, 630691,6, ,5), SDO_DIM_ELEMENT('Y', 8013976, 9044443, ,5))
SRID: 1000001
Oracle Version: 9.2.0.1.0
INDEX creation:
CREATE INDEX Point_RTREE_IDX ON POINT_TAB(shape)
INDEXTYPE IS MDSYS.SPATIAL_INDEX
The query returns 134 rows (out of 6151)
We are using a customized SRID:
WKTEXT: PROJCS["UTM Zone 24, Southern Hemisphere (Aratu)", GEOGCS [ "Aratu", DATUM ["Aratu", SPHEROID ["International 1924", 6378388.000000, 297.000000]], PRIMEM [ "Longitude of Origin", -39.000000 ], UNIT ["Decimal Degree", 0.00048481368110953599]], PROJECTION ["Transverse Mercator"], PARAMETER ["Scale_Factor", 0.999600], PARAMETER ["Central_Meridian", -39.000000], PARAMETER ["False_Easting", 500000.000000], PARAMETER ["False_Northing", 10000000.000000], UNIT ["Meter", 1.000000000000]]
TRACE:
Execution Plan
0 SELECT STATEMENT Optimizer=CHOOSE (Cost=70 Card=405 Bytes=15 96915)
1 0 TABLE ACCESS (BY INDEX ROWID) OF 'POCOS_TAB' (Cost=70 Card=405 Bytes=1596915)
2 1 DOMAIN INDEX OF 'POCOS_RTREE_IDX'
Many thanks,
Claudio. -
Executing spatial queries on someone else's tables
I am trying to execute a spatial
query using a table owned by
someone else.
The SQL is...
select a.plancoupe, a.coupecrop, a.ha
from dba1.coupes a, dba1.coupes b
where b.plancoupe = 'CM004H' and
mdsys.sdo_within_distance(a.geom,b.geom,
'distance=1000 querytype=WINDOW')
= 'TRUE'
The query works fine when I am connected
as dba1, but when I connect as someone
else I get...
ERROR at line 1:
ORA-29902: error in executing ODCIIndexStart() routine
ORA-13211: failed to tessellate the window object
ORA-13209: internal error while reading SDO_INDEX_METADATA table
ORA-06512: at "MDSYS.SDO_INDEX_METHOD", line 73
ORA-06512: at line 1
I have granted SELECT permissions on the
table in question to PUBLIC and also to
dba1.sdo_geom_metadata and the spatial
index table generated by the spatial
indexing creation routines...
Any ideas?
regards
SImonHi Simon,
From your e-mail below, I assume you are
running Oracle 8.1.5.
Here is what you need to do for 8.1.5.
Hope this helps.
Please let me know if you have any questions. Thanks.
Dan
======
In Oracle 8.1.6, your query will work
if you do the following:
1) Grant select on dba1.coupes
2) Grant select on the spatial index
table created on dba1.coupes
In Oracle 8.1.5 ONLY, do steps 3 and 4:
3) In addition to step 1 and 2 above,
grant select on sdo_geom_metadata
4) As the Oracle MDSYS user, you must run
the following:
connect mdsys/mdsys
drop view sdo_index_metadata;
create view sdo_index_metadata as
select SDO_INDEX_OWNER, SDO_INDEX_NAME, SDO_INDEX_TABLE, SDO_INDEX_PRIMARY,
SDO_TSNAME, SDO_COLUMN_NAME,
SDO_LEVEL, SDO_NUMTILES,
SDO_MAXLEVEL, SDO_COMMIT_INTERVAL,
SDO_FIXED_META,
SDO_TABLESPACE,
SDO_INITIAL_EXTENT,
SDO_NEXT_EXTENT,
SDO_PCTINCREASE,
SDO_MIN_EXTENTS,
SDO_MAX_EXTENTS
from SDO_INDEX_METADATA_TABLE
where
(exists
(select table_name from all_tables
where table_name=sdo_index_table and owner=sdo_index_owner)
or
exists
(select view_name from all_views
where view_name=sdo_index_table and owner=sdo_index_owner)
or
exists
(select table_name from all_object_tables
where table_name=sdo_index_table and owner=sdo_index_owner)
grant select on sdo_index_metadata to public;
null
Maybe you are looking for
-
How do I fix my homepage for Internet Explorer use, when using dreamweaver?
Hi, I have recently created my first two webpages, and they looked like they were working when I was using Firefox. But when using Internet Explorer one of the pages drop the text down to an area of the screen where it's impossible to read it. Can so
-
Whats the best way to move files from a hard drive that wont boot?
I made a bootable USB disk and it appears to work fine. I can still read and open files on the old disk (admin account only) from the new USB drive the old one doesn't boot. I don't have a backup but would like to move files to the USB and then refor
-
I have a macbook pro-how do i create address labels?
I have a Macbook Pro- how do I create address labels?
-
Selection screen output obligatory field
Hi all, I have two radio buttons, if i selected one radio button one selection screen will come for entries another will be invisible. in that selection screen i have all are mandatory fields. so it is not allowing to another radio button with out en
-
How to have spreadsheet like columns in report (like an Excel grid)
<p>I am trying to make a report in landscape format with around 15 columns across the sheet. The data is sales numbers per months plus total, budget and deviation (calculated).</p><p>The data should be in an <strong><u>Excel-like grid</u></strong>. T