Friday Jul 31, 2015

Submit your abstract for Oracle Spatial & BIWA Summit '16!

For the second year, Oracle Spatial Summit will once again be part of BIWA Summit at Oracle HQ in January 2016!

We want to hear your story -- and encourage you to submit your proposal soon. Proposals will be accepted through  November 2.   Don't wait, though -- we're accepting submissions on a rolling basis.  The sooner you submit, the better your chances.

We're looking for innovative Oracle Spatial and Graph, and MapViewer use cases in government, utilities, transportation, energy, telco,  retail and insurance, or other industries.  Large geospatial enterprise systems, and cloud, big data, BI deployments are of interest.

View more guidelines here, and view 2015 Summit sessions.

BIWA has a great event planned - with tracks for Advanced Analytics, Big Data, BI, Data Warehousing and Integration, and IoT, great keynote speakers, and Hands On Labs.

Submit your abstract here (http://www.ioug.org/p/cm/ld/fid=1000).

Good luck.  We hope you'll join us for Summit 2016!

Tuesday May 19, 2015

Dedicated blog for Oracle Big Data Spatial and Graph

With the launch of the new Oracle Big Data Spatial and Graph product we have also established a new blog dedicated to spatial analytics on the Hadoop platform and in-memory property graph processing (here).

Friday Mar 13, 2015

Using SDO_UTIL Functions to Construct Geodetic Shapes

Guest Post By: Nick Salem, Distinguished Engineer, Neustar

Note: Thanks to Nick Salem, Technical Chair of the Oracle Spatial SIG , for contributing another valuable tip and script example!  This is very useful for those who want to learn how to create grids for trade area/demographic analysis.

Oracle Spatial & Graph provides a feature rich toolkit for building and manipulating various types of geometries. There are a lot of great helper functions that you can utilize to construct a specific shape type. At Neustar, we leverage these functions to create square and hexagonal grids that we can overlay over a site’s trade area or some market. These grids can be then scored to show the variation of data across an area.

Below is a picture from Neustar’s ElementOne platform displaying a 0.5 mile grid layer over a 3 mile radius of a prospect bank site. The grids are scored by the number of households that have a bank savings account from high to low. Square grids are simple polygons that are easy to create in a planar surface since they have edges of equal length. However in a geodetic projection, you cannot simple use simple geometric calculations to construct these shapes or at least not as accurately as you may want especially if you are covering a larger area. Oracle provides the SDO_UTIL.CONVERT_UNIT and the SDO_UTIL.POINT_AT_BEARING functions that can be helpful in creating shapes on geodetic surfaces. You can use the CONVERT_UNIT function to convert units from degrees to radians and the POINT_AT_BEARING to place individual coordinates of a geometry.


Here’s a picture of a 1 mile hexagonal grid tessellation for the number of households with a home equity loan for the county of Anne Arundel in Maryland. Hexagonal grids have one advantage over square grids in that they are more circular in shape and so the distance from the center to the sides and edges is even.

Next I am going to show a simple PL/SQL script to create a simple trapezoid shape using the SDO_UTIL.CONVERT_UNIT and SDO_UNIT.POINT_AT_BEARING functions. In this example, I begin with a starting point located in San Diego county and then go in a counter clockwise order to plot the subsequent coordinates that will make up the trapezoid polygon. The angle passed into the SDO_UTIL.POINT_AT_BEARING function is measured clockwise from due north (i.e. bearing 0 is north, bearing 90 is east, bearing 180 is south, bearing 270 is west). I am creating a trapezoid polygon here as an example since a trapezoid can represent the top or bottom part of a hexagon.

Simple PL/SQL script example:

declare
startPoint sdo_geometry;
nextPoint sdo_geometry;

coords sdo_ordinate_array :=sdo_ordinate_array();
shape sdo_geometry;

begin

-- first starting point

startPoint := sdo_geometry(2001,4326,
                                 sdo_point_type(-117.0655,32.7475,null),null,null);
coords.extend(2);
coords(coords.count-1) := startPoint.sdo_point.x;
coords(coords.count) := startPoint.sdo_point.y;

-- place second coordinate 5,000 meters away using 330 (northwest) degree angle

nextPoint := sdo_util.point_at_bearing( start_point => startPoint,
                                         bearing => sdo_util.convert_unit(330,'degree','radian'),
                                         distance => 5000 );
coords.extend(2);
coords(coords.count-1) := nextPoint.sdo_point.x;
coords(coords.count) := nextPoint.sdo_point.y;

-- place third coordinate 3,000 meters away using 270 (west) degrees angle

startPoint := nextPoint;
nextPoint := sdo_util.point_at_bearing( start_point => startPoint,
                                         bearing => sdo_util.convert_unit(270,'degree','radian'),
                                         distance => 3000 );
coords.extend(2);
coords(coords.count-1) := nextPoint.sdo_point.x;
coords(coords.count) := nextPoint.sdo_point.y;

-- place fourth coordinate 5,000 meters away using 210 (southwest) degrees angle

startPoint := nextPoint;
nextPoint := sdo_util.point_at_bearing( start_point => startPoint,
                                         bearing => sdo_util.convert_unit(210,'degree','radian'),
                                         distance => 5000 );
coords.extend(2);
coords(coords.count-1) := nextPoint.sdo_point.x;
coords(coords.count) := nextPoint.sdo_point.y;

-- add starting coordinate as 5th coordinate to close the polygon

coords.extend(2);
coords(coords.count-1) := coords(1);
coords(coords.count) := coords(2);

-- construct shape geometry

shape :=sdo_geometry( 2003, 4326,null,
                           sdo_elem_info_array(1,1003,1), coords ) ;
end;

Here’s the result of the shape geometry from script above displayed on a map.

In conclusion, Oracle Spatial & Graph provides us with some nice helper functions that we can use to construct shapes on a geodetic surface. In this post, we demonstrated how one can use the SDO_UTIL.POINT_AT_BEARING and SDO_UTIL.CONVERT_UNIT to plot coordinate points for a geometric polygon.


Monday Jan 19, 2015

The Importance of Organizing Spatial Data By Proximity

Guest Post By: Nick Salem, Distinguished Engineer, Neustar

Note: Thanks to Nick Salem, Technical Chair of the Oracle Spatial SIG , for contributing this valuable tuning and performance tip that will be useful to most Oracle Spatial users!

The goal of this post is to shed some light on a technique that I feel is many times overlooked by users working to tune large spatial datasets: to organize the rows in a table by their spatial proximity. Dan Geringer alluded to this in the post “Tips on tuning SDO_NN (nearest neighbor) queries” . What I want to highlight is that this technique is not only beneficial for SDO_NN queries, but also for basically all queries that use any of the spatial query operators like SDO_FILTER, SDO_RELATE, SDO_WITHIN_DISTANCE, as well as the SDO_RELATE helper operators such as SDO_ANYINTERACT, SDO_INSIDE and so on. The SDO_JOIN operator by itself may not benefit from this approach because it relies solely on the spatial index, but if you decide to join the resultset of the SDO_JOIN operation back to the input tables of the join operation, then you will most likely also benefit from having the data stored by proximity.

To understand the dynamics of this, one has to understand in general how Oracle queries work. When a user issues a spatial query, a spatial index is used to find the rowids for the rows that need to be returned. Oracle uses these rowids to retrieve the database blocks from disk into the buffer cache where it can process the data. Each database block can contain one or more rows of data. In order for Oracle to retrieve data for a query, it needs to retrieve all the blocks needed to satisfy a query. The more blocks that need to be scanned, the more I/O operations are performed and the longer the query will take. For example, a spatial query resulting in the scan of one or two adjacent blocks will return a lot faster than the same spatial query needing to scan a large number of disparate blocks to process the same results. Of course, this issue is not confined to just spatial queries. In fact, most Oracle DBAs are aware of this with the concept of the index clustering factor which describes the relationship between the order of an index and its corresponding table. For non-spatial data, achieving an optimal index clustering factor can be as easy as ordering the data in a table by a scalar data type column that you plan to index and then creating that index. For spatial data, this can be a little trickier because one cannot just simply order by the SDO_GEOMETRY column. In Dan’s post “Tips on tuning SDO_NN (nearest neighbor) queries”, he shows an example using the MD.HHENCODE_BYLEVEL function to return a value that you can use to sort your spatial data by.

In this post, I will show an example of a use case I tested that highlights the impact on performance when ordering spatial data by proximity. The example will include taking the US Business listing table and creating two copies: one that is not ordered by proximity, and the other ordered by proximity using the MD.HHENCODE_BYLEVEL function. Then, I will test running a simple SDO_WITHIN_DISTANCE query on both tables to retrieve the sum of employees for an arbitrary 5 mile radius and compare the results.

Example Pre-requisites

In this example, I am starting with a 16 million row table containing all the US business locations with approx 30 columns called BUSINESS1. This table is not ordered by spatial proximity. BUSINESS1 also has a spatial index created on column GEOM.

Step 1) Next I will create table BUSINESS2, which will be an exact copy of BUSINESS1, but will be ordered by proximity using the MD.HHENCODE_BY_LEVEL function as described in Dan’s post.


CREATE TABLE business2 PCTFREE 0 NOLOGGING PARALLEL
as
SELECT /*+ parallel(8) */
  b.*
FROM
  business1 b
ORDER BY
  row_number() over (order by md.hhencode_bylevel(
     b.geom.sdo_point.x,-180,180,27,
     b.geom.sdo_point.y,-90,90,26)) ;

* Note: the MD.HHENCODE_BYLEVEL function takes an x and y coordinate and so the example works well with the US Business points. If you are working with polygons instead of points, you will need to retrieve the centroid of the shape and then pass the X/Y point coordinates to function. For more info, please refer to Dan Geringer’s original post “Tips on tuning SDO_NN (nearest neighbor) queries” to see an example of how this is done.

* Note: only use PCTFREE 0 for read only tables. In this example, the BUSINESS2 is read only and using PCTFREE 0 allows more rows to be packed into a single database block.

Step 2) add diminfo and create spatial index

begin

mdsys.sdo_meta.change_all_sdo_geom_metadata( USER, ‘BUSINESS2’, ‘GEOM’, mdsys.sdo_dim_array (
     mdsys.sdo_dim_element('X', -180, 180, .5),
     mdsys.sdo_dim_element('Y', -90, 90, .5) ),8307);
end;
/

CREATE INDEX xsp_business2 ON business2(geom)
INDEXTYPE is mdsys.spatial_index PARAMETERS(' SDO_RTR_PCTFREE=0 WORK_TABLESPACE=WORK');

* Note: it is recommended to use a WORK_TABLESPACE that is a different tablespace than the one where the index will be created. Although optional, the use of a WORK_TABLESPACE can reduce the fragmentation of your spatial index which is important for performance.

* Note: only use SDO_RTR_PCTFREE=0 for read only data. In this example, the US BUSINESS listing table is pretty much a read only dataset and gets completely replaced every month.

Step 3) Perform query comparison test

In SQL*PLUS, set timing and flush the buffer cache

SQL> SET TIMING ON;
SQL>
SQL> ALTER SYSTEM FLUSH BUFFER_CACHE;

System altered.

* Note: you should not flush the buffer cache on a production system. But in a test environment, flushing the buffer cache can help with testing comparative performance by ensuring there are no blocks in the SGA from prior queries that could skew performance results.

Run the first query on the non-spatially ordered table

select
  sum(b.num_of_employees)
from
 business1 b
where
  sdo_within_distance( b.geom,
                       mdsys.sdo_geometry(2001,8307,
                       mdsys.sdo_point_type( -117.047071, 32.75521, null),null,null),
                       'distance=5 unit=mile' ) = 'TRUE';

SUM(B.NUM_OF_EMPLOYEES)
-----------------------
                 137964

Elapsed: 00:00:35.14

Run the query on the spatially ordered business table and compare results.

select
  sum(b.num_of_employees)
from
 business2 b
where
  sdo_within_distance( b.geom,
                       mdsys.sdo_geometry(2001,8307,
                       mdsys.sdo_point_type( -117.047071, 32.75521, null),null,null),
                       'distance=5 unit=mile' ) = 'TRUE';

SUM(B.NUM_OF_EMPLOYEES)
-----------------------
                 137964

Elapsed: 00:00:01.49

Conclusion

In this example, I was able to achieve more than 20X better performance just by taking the same table and ordering by a geographic extent. The queries in the example utilized the spatial operator SDO_WITHIN_DISTANCE to return the sum of employees with a 5 mile radius around a location. Since both tables (BUSINESS1 and BUSINESS2) are identical except in storage of the order of rows of data, the spatial index performance should be pretty much the same. The difference in performance that we are seeing is due to the amount of disk and memory I/O processing caused by the different number of blocks that needed to be accessed for each of the queries. This is a substantial improvement in performance and highlights the importance of the order of spatial data by geographic proximity. And as mentioned in the beginning of the post, ordering spatial data may boost any spatial query operations, whether you are performing within distance queries, sdo relate queries, nearest neighbor or performing map visualizations. Results can vary based on size of table, the speed of disk I/O and also the order of the original dataset. It is possible that the original dataset you are working with is already organized by some geographic extent such as county or ZIP Code so additional ordering using the method described in this post could result in some performance gains but nothing as significant as the 20X I have experienced. But if the order of the table is completely random and not tied to any geographic extent, then you can expect to see greater performance gains. All in all, I definitely recommend looking into organizing larger and more frequently queried spatial data by geographic proximity as a best practice technique for optimizing your spatial data.


Monday Oct 06, 2014

OOW 2014 Spatial SIG Meetup Discussion

sigphoto

At Oracle OpenWorld last week in San Francisco, the Oracle Spatial SIG invited users to join an informal meetup -- at the OTN Lounge in Moscone South.  Users from the US and Europe, from industries such as rail, local city government, national land management agencies, and defense, met with SIG Board and  Oracle Spatial product team members to discuss questions around Oracle Spatial and MapViewer implementations.

Topics included: 

-- challenges of and strategies for handling complex geometries

-- enterprise deployments with various GIS tools

-- MapViewer capabilities such as HTML5 / JSon support, editing, and new mobile/BI features

Read a full recap of the discussion topics here.

And check out more photos from the event. 

Monday Aug 11, 2014

Save the dates! Jan 27-29, 2015 -- Oracle Spatial Summit 2015

Oracle Corporation
header image

Oracle Spatial Summit 2015

Moving to California as part of the Oracle BIWA Summit 2015

divider line
shadow

Save the dates! Jan 27-29, 2015

Oracle Conference Center at Oracle HQ Campus, Redwood Shores, CA

  • Learn directly from the senior management and developers of Oracle’s industry-leading spatial technologies -- Dan Geringer, Siva Ravada, Xavier Lopez, Jayant Sharma and Jim Steiner.
  • Participate in Hands-On-Labs for Oracle Spatial and MapViewer.
  • Hear from leading practitioners and customers about their experiences with Oracle’s spatial technologies, Exadata, OBIEE and more.
  • Experience Oracle BIWA with expert and customer sessions on Business Intelligence, Data Warehouse, and Big Data technologies.

SUBMIT YOUR SESSION ABSTRACT FOR THE ORACLE SPATIAL SUMMIT 2015 NOW!

Hardware and Software, Engineered to Work Together
Copyright © 2014, Oracle and/or its affiliates.
All rights reserved.
Contact Us | Legal Notices and Terms of Use | Privacy Statement

Tuesday Jul 29, 2014

How much space do your SDO_GEOMETRY tables consume?

 By Karin Patenge, Principle Sales Consultant, Oracle Germany

I would like to briefly offer a simple function to calculate the memory allocated for SDO_GEOMETRY tables. This takes into account only tables, LOB and index segments (this is not applicable for partitioned tables).


create or replace function alloc_space_in_mbytes (tablename in varchar2)
return number 
is
table size number;
begin
  select 
    sum (bytes) into table size
  from (
    select 
      segment_name, 
      bytes  
    from 
      USER_SEGMENTS - table segments             
    where  
      segment_name = tablename
    union all
    select 
      s.segment_name segment_name, 
      s.bytes bytes
    from 
      user_lobs l, - Lobsegmente
      USER_SEGMENTS s
    where 
      l.table_name = tablename and
      s.segment_name = l.segment_name
    union all
    select 
      s.segment_name segment_name, 
      s.bytes bytes
    from 
      USER_INDEXES i, - index segments
      USER_SEGMENTS s
    where 
      i.table_name = tablename and
      s.segment_name = i.index_name);

  table size: = tablesize/1024/1024; - Conversion in MB
  return table size;
end;
/
The call to the function can then look like this:
select
  alloc_space_in_mbytes ('GEOM_TABLE_UNTRIMMED') untrimmed, 
  alloc_space_in_mbytes ('GEOM_TABLE_TRIMMED') trimmed
from dual
/
A test table with 218 237 polygons, a total of 60,754,462 bases and existing spatial index result in the following values:

SDO_ORDINATE_ARRAY values with predominantly 12 to 13 decimal places: 1643.5 MB
SDO_ORDINATE_ARRAY values truncated to 5 decimal places: 1033.5 MB

Friday May 02, 2014

Tips on tuning SDO_NN (nearest neighbor) queries

By:  Daniel Geringer, Senior Development Manager, Oracle Spatial and Graph 

Many times I come across customers who ask for help tuning their SDO_NN queries.

I generally group SDO_NN queries into two categories.
The category defines which SDO_NN parameter to use, SDO_NUM_RES or SDO_BATCH_SIZE.
Choose either SDO_NUM_RES or SDO_BATCH_SIZE, never both.

SDO_NUM_RES -    Find the nearest candidates only with respect to proximity to the window geometry.
                                     There are no additional conditions in the WHERE clause. 
SDO_BATCH_SIZE - Find the nearest candidates, and match additional conditions in the WHERE clause.
                                       For example, find the 5 nearest banks with name = 'CITIBANK'


For "SDO_NN with SDO_BATCH_SIZE", a template is recommended.
Optimizations have been developed when the template is used for "SDO_NN with SDO_BATCH_SIZE" queries.

The template must include the FIRST_ROWS hint and ORDER BY distance for the optimization to take effect.
The following is an example of the template.

--
--  Find 30 closest banks named CITIBANK to the window geometry no further than 8046.72 meters (or 5 miles) away.
--   This SDO_BATCH_SIZE query includes the first_rows hint, and also ORDER BY distance.
--
--   Specifying the cutoff distance is not required, but it can also really help performance.
--   For example, distance=8046.72 means stop searching once you reach 5 miles away from the window geometry.
--
SELECT bank_id, distance
FROM (SELECT /*+ first_rows */ a.bank_id, sdo_nn_distance(1) distance
             FROM banks a
             WHERE sdo_nn (geometry, window_geometry, 'SDO_BATCH_SIZE=10 distance=8046.72', 1)='TRUE'
                 AND a.bank_name = 'CITIBANK'
             ORDER BY distance)
WHERE rownum <=  30;


Not always necessary, but for SDO_NN queries against very dense data (for example, when searching customers in a city with a large population), major performance gains can be achieved by ordering the data in your table spatially by a linear key.

The idea is to order the table during load, where rows containing geometries close to each other
get placed in the same database block. That way, when nearest neighbor gets the next sdo_batch_size set of rows,
and checks additional conditions for a match, the data for the additional condition checks are likely to be in a
database block that is already cached in the SGA. 

If the table is not ordered spatially, potentially, every nearest neighbor candidate (obtained by the spatial index)
might have its additional attributes in database blocks spread all over the place.  This results in much more
disk reads vs in-memory hits to compare the additional conditions in the query.

SDO_NN with SDO_BATCH_SIZE can perform much faster when this is done.
Below are a polygon and point example of how to order a table spatially by a linear key:

--------------------------------------------------------------------------------
-- Make a copy of the POLYGON table.  Call it POLYGON_ORDERED.
--------------------------------------------------------------------------------
connect / as sysdba
grant execute on mdsys.md to some_user;
exit;

connect some_user/some_user
SET TIMING ON
ALTER SESSION ENABLE PARALLEL DDL;
ALTER SESSION ENABLE PARALLEL DML;
ALTER SESSION ENABLE PARALLEL QUERY;
DROP TABLE polygon_ordered;
CREATE TABLE polygon_ordered NOLOGGING TABLESPACE users PARALLEL AS
WITH
  part1 AS (SELECT /*+ parallel (8) */
                   column1,
                   column2,
                   column3,
                   geom,
                   sdo_geom.sdo_centroid(geom,.05) centroid
              FROM polygon_table)
SELECT /*+ parallel (8) */
       p1.column1,
       p1.column2,
       p1.column3,
       p1.geom,
       row_number() OVER (ORDER BY md.hhencode_bylevel (p1.centroid.sdo_point.x, -180, 180, 27,
                                                                                                     p1.centroid.sdo_point.y,  -90,  90, 26)) rn
FROM part1 p1;


--------------------------------------------------------------------------------
-- Make a copy of the POINT table.  Call it POINT_ORDERED.
--------------------------------------------------------------------------------
connect / as sysdba
grant execute on mdsys.md to some_user;
exit;

connect some_user/some_user
SET TIMING ON
ALTER SESSION ENABLE PARALLEL DDL;
ALTER SESSION ENABLE PARALLEL DML;
ALTER SESSION ENABLE PARALLEL QUERY;
DROP TABLE point_ordered;
CREATE TABLE point_ordered NOLOGGING TABLESPACE users PARALLEL AS
WITH
  part1 AS (SELECT /*+ parallel (8) */
                   column1,
                   column2,
                   column3,
                   geom
              FROM point_table)
SELECT /*+ parallel (8) */
       p1.column1,
       p1.column2,
       p1.column3,
       row_number() OVER (ORDER BY md.hhencode_bylevel (p1.geom.sdo_point.x, -180, 180, 27,
                                                                                                     p1.geom.sdo_point.y,  -90,  90, 26)) rn
FROM part1 p1;

Tuesday Apr 01, 2014

Tips for using the Oracle Spatial and Graph geocoding engine to convert addresses directly in the Oracle database

By Karin Patenge, Principal Sales Consultant, Oracle Germany

Many OLTP systems and data warehouse implementations would benefit from having an address cleansing process included which at the same time associates geographic coordinates with each address for spatial analytics. Together with reference datasets from HERE/Nokia or TomTom the Oracle Geocoder can provide this functionality out-of-the-box.

The Geocoding engine in Oracle Spatial and Graph can be accessed using PL/SQL, via the SDO_GCDR package, which belongs to the user MDSYS. In addition to the the actual conversion of an address line into a point geometry (SDO_GEOMETRY with the geometry type 2001) using GEOCODE_AS_GEOMETRY, this package includes the GEOCODE function:

select SDO_GCDR.GEOCODE(user, SDO_KEYWORDARRAY('Schiffbauergasse 14', '14467 Potsdam'),'DE', 'DEFAULT') from dual;

This function provides the second important capability of the geocoder (in addition to the calculation of the geo-coordinates), namely to perform address verification. The return value is an object of type SDO_GEO_ADDR. Based on the address match against the reference dataset, this function returns information such as the quality of the match as well as the completed or corrected address from the reference dataset.

The command describe SDO_GEO_ADDR displays the structure of the object. The result for the query above can be found below, but without looking in the Oracle Spatial Developer's Guide only some parts are meaningful.

MDSYS.SDO_GEO_ADDR(MDSYS.SDO_KEYWORDARRAY(),
 NULL,NULL,NULL,NULL,NULL,
 'Potsdam','BRANDENBURG','DE','14467',
 NULL,NULL,NULL,NULL,NULL,NULL,'F','F',
 NULL,NULL,'L',0,64959047,'??????????B281CP?',4,'DEFAULT',
 13.04793,52.39935,'???11111110??400?')

To understand the output more easily, here is a PL/SQL script that extracts the array values and interprets the ERRORMESSAGE, MATCHVECTOR and MATCHMODE strings.

create or replace procedure format_geo_addr (
  address SDO_GEO_ADDR
)
AS
  type strings is table of varchar2(30);
  match_names strings := strings (
    '?            ',
    '0 (MATCHED)  ',
    '1 (ABSENT)   ',
    '2 (CORRECTED)',
    '3 (IGNORED)  ',
    '4 (SUPPLIED) '
  );
  address_elements strings := strings (
    null,
    null,
    'X Address Point',
    'O POI Name',
    '# House or building number',
    'E Street prefix',
    'N Street base name',
    'U Street suffix',
    'T Street type',
    'S Secondary unit',
    'B Built-up area or city',
    null,
    null,
    '1 Region',
    'C Country',
    'P Postal code',
    'P Postal add-on code'
  );
  element_match varchar2(128);
  element_match_code char(1);

BEGIN
  if address is not null then
    dbms_output.put_line ('- ID                  ' || address.ID);
    dbms_output.put_line ('- ADDRESSLINES');
    if address.addresslines is not null then
      for i in 1..address.addresslines.count() loop
        dbms_output.put_line ('- ADDRESSLINES['||i||']           ' || address.ADDRESSLINES(i));
      end loop;
    end if;
    dbms_output.put_line ('- PLACENAME           ' || address.PLACENAME);
    dbms_output.put_line ('- STREETNAME          ' || address.STREETNAME);
    dbms_output.put_line ('- INTERSECTSTREET     ' || address.INTERSECTSTREET);
    dbms_output.put_line ('- SECUNIT             ' || address.SECUNIT);
    dbms_output.put_line ('- SETTLEMENT          ' || address.SETTLEMENT);
    dbms_output.put_line ('- MUNICIPALITY        ' || address.MUNICIPALITY);
    dbms_output.put_line ('- REGION              ' || address.REGION);
    dbms_output.put_line ('- COUNTRY             ' || address.COUNTRY);
    dbms_output.put_line ('- POSTALCODE          ' || address.POSTALCODE);
    dbms_output.put_line ('- POSTALADDONCODE     ' || address.POSTALADDONCODE);
    dbms_output.put_line ('- FULLPOSTALCODE      ' || address.FULLPOSTALCODE);
    dbms_output.put_line ('- POBOX               ' || address.POBOX);
    dbms_output.put_line ('- HOUSENUMBER         ' || address.HOUSENUMBER);
    dbms_output.put_line ('- BASENAME            ' || address.BASENAME);
    dbms_output.put_line ('- STREETTYPE          ' || address.STREETTYPE);
    dbms_output.put_line ('- STREETTYPEBEFORE    ' || address.STREETTYPEBEFORE);
    dbms_output.put_line ('- STREETTYPEATTACHED  ' || address.STREETTYPEATTACHED);
    dbms_output.put_line ('- STREETPREFIX        ' || address.STREETPREFIX);
    dbms_output.put_line ('- STREETSUFFIX        ' || address.STREETSUFFIX);
    dbms_output.put_line ('- SIDE                ' || address.SIDE);
    dbms_output.put_line ('- PERCENT             ' || address.PERCENT);
    dbms_output.put_line ('- EDGEID              ' || address.EDGEID);
    dbms_output.put_line ('- ERRORMESSAGE        ' || address.ERRORMESSAGE);
    if address.MATCHVECTOR is not null then
      dbms_output.put_line ('- MATCHVECTOR         ' || address.MATCHVECTOR);
      for i in 1..length(address.MATCHVECTOR) loop
        if address_elements(i) is not null then
          if substr (address.matchvector,i,1) = '?' then
            element_match_code := 0;
          else
            element_match_code := substr(address.matchvector,i,1) + 1;
          end if;
          dbms_output.put_line ('-   '|| substr(address.errormessage,i,1)  || ' ' ||
            match_names (element_match_code + 1) || ' ' ||
            address_elements (i)
          );
        end if;
      end loop;
    end if;
    if address.MATCHVECTOR is not null then
      dbms_output.put_line ('- MATCHCODE           ' || address.MATCHCODE || ' = ' ||
        case address.MATCHCODE
          when  0 then 'Ambiguous'
          when  1 then 'Exact match'
          when  2 then 'Street type not matched'
          when  3 then 'House number not matched'
          when  4 then 'Street name not matched'
          when 10 then 'Postal code not matched'
          when 11 then 'City not matched'
        end
      );
    end if;
    dbms_output.put_line ('- MATCHMODE           ' || address.MATCHMODE);
    dbms_output.put_line ('- LONGITUDE           ' || address.LONGITUDE);
    dbms_output.put_line ('- LATITUDE            ' || address.LATITUDE);
  else
    dbms_output.put_line ('**** NO MATCH ****');
  end if;
end;
/
show errors

create or replace procedure format_addr_array (
  address_list SDO_ADDR_ARRAY
)

as
begin
  if address_list is not null and address_list.count() > 0 then
    for i in 1..address_list.count() loop
      dbms_output.put_line ('ADDRESS['||i||']');
      format_geo_addr (address_list(i));
    end loop;
  else
    dbms_output.put_line ('**** NO MATCH ****');
  end if;
end;
/
show errors

Now the GEOCODE function can be called again, but this time in conjunction with the format function:

exec format_geo_addr (SDO_GCDR.GEOCODE(user, SDO_KEYWORDARRAY('Schiffbauergasse 14', '14467 Potsdam'), 'DE', 'DEFAULT'));

And the resulting output is now formatted in a manner that is much easier to understand.


- ID                  0
- ADDRESSLINES
- PLACENAME          
- STREETNAME          Schiffbauergasse
- INTERSECTSTREET    
- SECUNIT            
- SETTLEMENT         
- MUNICIPALITY        Potsdam
- REGION              BRANDENBURG
- COUNTRY             DE
- POSTALCODE          14467
- POSTALADDONCODE    
- FULLPOSTALCODE     
- POBOX              
- HOUSENUMBER         14
- BASENAME            SCHIFFBAUER
- STREETTYPE          GASSE
- STREETTYPEBEFORE    F
- STREETTYPEATTACHED  F
- STREETPREFIX       
- STREETSUFFIX       
- SIDE                R
- PERCENT             .75
- EDGEID              748777426
- ERRORMESSAGE        ????#ENUT?B281CP?
- MATCHVECTOR         ???10101010??400?
-   ? ?             X Address Point
-   ? 1 (ABSENT)    O POI Name
-   # 0 (MATCHED)   # House or building number
-   E 1 (ABSENT)    E Street prefix
-   N 0 (MATCHED)   N Street base name
-   U 1 (ABSENT)    U Street suffix
-   T 0 (MATCHED)   T Street type
-   ? 1 (ABSENT)    S Secondary unit
-   B 0 (MATCHED)   B Built-up area or city
-   1 4 (SUPPLIED)  1 Region
-   C 0 (MATCHED)   C Country
-   P 0 (MATCHED)   P Postal code
-   ? ?             P Postal add-on code
- MATCHCODE           1 = Exact match
- MATCHMODE           DEFAULT
- LONGITUDE           13.0745378367008
- LATITUDE            52.4041174822031

Note: The reference dataset used for this test with the Oracle Spatial and Graph geocoder was provided by HERE/Nokia.

Upcoming Webinars: MapViewer at City of Toronto for Public Safety, Customers Achieve 300x Performance Gains with Oracle Spatial and Graph

A note to share information about two upcoming Directions Media webinars on April 23 and May 6.

City of Toronto Enhances Public Safety Using Real-time Big Data and Map Rendering with Oracle and AGSI, Wed., April 23, 2:00PM US EDT

Learn how the City of Toronto Police Services can search, review and map social media traffic in real time to quickly identify and respond to incidents, improving public safety. See live demos of their system using Oracle MapViewer's HTML5 capabilities, Oracle Spatial, and a social media mapping platform from partner AGSI. Carol Palmer of Oracle will co-present this webinar with Mike Jander of AGSI, and City of Toronto, hosted by Directions Media.

Learn more and register for this free webinar -
http://www.directionsmag.com/webinars/register/city-of-toronto-enhances-public-safety-using-real-time-big-data-and-ma/389356?DM_webinars_section&utm_medium=web&utm_campaign=389356


Learn How Customers Are Experiencing 300x Performance Gains with Oracle Spatial and Graph, Tues., May 6, 2:00PM US EDT (Free Webinar)

Nick Salem of Neustar and Steve Pierce of Think Huddle will share their realized performance benchmarks using Oracle Spatial and Graph. With Oracle Spatial and Graph in Database 12c, customers can address the largest geospatial workloads and experience performance increases of 50 to 300 times for vector operations, with minimal configuration changes. Jim Steiner of Oracle will also discuss performance gains from parallel raster processing and Exadata.

Learn more and register for this free webinar -
http://www.directionsmag.com/webinars/register/learn-how-customers-are-experiencing-300x-performance-gains-with-oracl/390239?DM_webinars_section&utm_medium=web&utm_campaign=390239

Monday Feb 24, 2014

Performance Boost with Aggregating Geometries - with 12c Spatial Vector Performance Acceleration

Nick Salem of Neustar recently shared some impressive performance gains realized using Oracle Spatial 12c Vector Performance Acceleration, in a Google+ post.   He observed performance gains of 40X to 300X -- with a use case aggregating all ZIP Code geographies in California using a SDO_AGGR_UNION operations (plain and with group by/mod functions as described in 11g documented best practices). 

Read more details of his test case and results here.  https://plus.google.com/114373574274269737617/posts/2caAypKxwff

Thanks for sharing, Nick!

Monday Feb 17, 2014

Oracle Spatial and Graph is now compliant with OGC WFS 1.1.0 and WFS-T 1.1.0

An update from Baris Kazar of the Spatial development team: 

We are happy to announce that Oracle Spatial and Graph for 12c Release 1 is now fully compliant with OGC's WFS 1.1.0 and WFS-T 1.1.0 standards.  

http://www.opengeospatial.org/resource/products/details/?pid=1197

For more information on Oracle Spatial and Graph standards compliance

http://www.opengeospatial.org/resource/products/compliant#Oracle_USA - full list of OGC standards compliance for  all Oracle Spatial product versions

http://www.oracle.com/technetwork/database/options/spatialandgraph/documentation/spatial-stds-support-094078.html -  Oracle Spatial Technologies Standards Page


Wednesday Feb 05, 2014

Data Validation with Esri and Oracle Spatial

By:  Daniel Geringer, Senior Development Manager, Oracle Spatial and Graph

One of the things users can run into when using Esri with Oracle Spatial can be problems with data validation when loading data using Esri utilities into Oracle Spatial data types. From my experience, the solution is a relatively straightforward change in the workflow used to load data.

Here is an excerpt from a user problem where it sounds like Esri is calling Oracle's validation on load (not Esri's validation).

I don't believe Esri's validation would be sensitive to the database version.

  • It seems there are tighter tolerances (or the tolerances work) in 11.2.0.3 and features that were not reporting as invalid in 11.2.0.2 are now reporting as invalid features (mainly self-intersecting polygons) in the 11.2.0.3.  We are assuming that for some reason the SDE tools are crashing when they hit an invalid feature.

This sounds more like a workflow defined by Esri than differences in validation.  I think the issue is once Esri encounters an invalid geometry, it stops loading the rest (even if they are valid).  I believe Esri chooses this workflow to ensure all geometries in a layer are valid.  I agree the outcome is optimal, and what Oracle recommends too.  A deficiency in the workflow is:

1. It prevents valid geometries from being loaded after an invalid one is encountered
2. Not loading the invalid geometry does not provide a way to inspect it

From a product perspective, a change in the Esri workflow would have to be implemented by Esri.  (Maybe the default behavior can remain the same, but enable a switch that populates invalid geometries into a different table for inspection at a later time. This is just one suggestion.  There may be other options.)

Currently, the best way to circumvent this is to do what this customer did, and load data with Oracle or third party tools like FME.  Once the data is loaded, Oracle also recommends validation, and removing/isolating invalid geometries until they can be fixed.  I discuss a strategy to do this in a best practices presentation. 

One thing I keep hearing is the claim that Esri and Oracle validate differently.

  • Both ESRI and Oracle validate by OGC rules. 
  • The only difference I see is when the data is geodetic.  Esri does not consider geodesic paths between vertices for linestrings or polygons, but Oracle does. 
  • There is only one case I have come across that is valid in Esri, but not in Oracle or by OGC standards. 
    • Imagine a box with a triangle void, where the triangle only touches the box at one point. 
    • Esri can model this as a single exterior ring with no voids, and considers it valid.  This does not comply with OGC standards.
    • Oracle and the OGC standard state that this case is valid if it is modeled with two rings, one exterior and one interior, where the interior ring touches the exterior at one point.
  • Other than geodetic data validation, I believe both Esri and Oracle offer comprehensive validation, and for all intents and purposes, the validation offered by both solutions is equivalent.

Friday Jan 10, 2014

New Point-in-Polygon function in Oracle Spatial and Graph 12c

By: Jim Steiner, Siva Ravada, Rick Anderson

With the increased adoption of Exadata for spatial workloads, we have been looking at ways to exploit more and more of the capabilities of this architecture to address problems faced in large scale spatial analysis. The new point-in-polygon function in Spatial can result in 100s of times faster UPDATE and INSERT operations with no degradation in query performance for large scale point-in-polygon operations. Mask operations (DISJOINT, TOUCH, INSIDE, ANYINTERACT) can be performed with the point-in-polygon function.

When working with point data and performing point-in-polygon analysis the existing spatial operators to do a fast query on the data if there is a Spatial index on the point data. However, in many cases, the data volume is very high, so creating and maintaining the index becomes very expensive. With 12c, we exploit Exadata smartscan by implementing a different model to take advantage of all the CPUs to do point in polygon operations and not have the overhead of a Spatial index. The mdsys.PointInPolygon() function returns those rows that reside within a specified polygon geometry. This parallel-enabled Point-In-Polygon function takes an arbitrary set of rows whose first column is a point's x-coordinate value and the second column is a point's y-coordinate value.

The mdsys.PointInPolygon() function API is the following:

mdsys.sdo_PointInPolygon(cur SYS_REFCURSOR,
                         geom_obj IN SDO_GEOMETRY,
                         tol IN NUMBER,
                         params IN VARCHAR2 DEFAULT NULL);

The "cur" parameter is used to select an "x" and "y" point coordinate from a

user table. The two columns must be of type NUMBER; this is NOT a geometry

parameter.

The "geom_obj" parameter is either a polygon geometry from a table, or a

Transient instance of a polygon geometry, against which all of the selected points from "cur" will be validated.

The "tol" parameter is the desired tolerance value, which must be greater than the value "0.0".



The following examples show the performance benefits of this new approach:

Here we select all rows from the "weather_sensor" table and query those rows against a transient polygon geometry instance. Only 1 weather_sensor row (out of 4) resides within the specified polygon.

SQL> SELECT *

2 FROM TABLE(mdsys.sdo_PointInPolygon(

3 CURSOR(select * from weather_sensor),

4 MDSYS.SDO_GEOMETRY(

5 2003,

6 NULL,

7 NULL,

8 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),

9 MDSYS.SDO_ORDINATE_ARRAY(5, 1, 8, 1, 8, 6, 5, 7, 5, 1)),

10 0.05));

In order to utilize parallel query servers, you must either specify the

"/*+ PARALLEL(4) */" optimizer hint, or enable parallel query execution,

using the command:

alter session force parallel query;

Below is the same as above, but uses 4 parallel query servers:

SQL> SELECT /*+ PARALLEL(4) */ *

2 FROM TABLE(mdsys.sdo_PointInPolygon(

3 CURSOR(select * from weather_sensor),

4 MDSYS.SDO_GEOMETRY(

5 2003,

6 NULL,

7 NULL,

8 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),

9 MDSYS.SDO_ORDINATE_ARRAY(5, 1, 8, 1, 8, 6, 5, 7, 5, 1)),

10 0.05));

There can be a huge performance benefit to using parallel query servers.

The following "worst-case" example queries 1-million rows against a transient

polygon geometry instance, using the non-parallel query execution:

SQL> -- instead of the actual data...

SQL>

SQL> -- Test "non-parallel" execution first

SQL> timing start "sdo_PointInPolygon()"

SQL> SELECT COUNT(*)

2 FROM TABLE(mdsys.sdo_PointInPolygon(

3 CURSOR(select * from pip_data),

4 MDSYS.SDO_GEOMETRY(

5 2003,

6 NULL,

7 NULL,

8 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),

9 MDSYS.SDO_ORDINATE_ARRAY(5, 1, 8, 1, 8, 6, 5, 7, 5, 1)),

10 0.05));

timing for: sdo_PointInPolygon()

Elapsed: 00:05:00.73

Enabling the parallel query servers dramatically reduces the query execution time:

SQL> -- Now test using 4 parallel query servers

SQL> timing start "sdo_PointInPolygon()"

SQL> SELECT /*+ PARALLEL(4) */ COUNT(*)

2 FROM TABLE(mdsys.sdo_PointInPolygon(

3 CURSOR(select * from pip_data),

4 MDSYS.SDO_GEOMETRY(

5 2003,

6 NULL,

7 NULL,

8 MDSYS.SDO_ELEM_INFO_ARRAY(1, 1003, 1),

9 MDSYS.SDO_ORDINATE_ARRAY(5, 1, 8, 1, 8, 6, 5, 7, 5, 1)),

10 0.05));

SQL> timing stop

timing for: sdo_PointInPolygon()

Elapsed: 00:02:18.18

For more information about this new feature, link to the documentation URL:
SDO_PointInPolygon


Thursday Dec 19, 2013

Welcome!

Welcome to the official blog for the spatial features of Oracle Spatial and Graph, an option of Oracle Database!  Our development and product managers will be posting the latest product updates, and relevant technical tips here.

Feel free to let us know in the comments of any questions, feedback, or suggested topics.

We look forward to sharing info and interacting with our great user community on this blog!

About

The official blog for the spatial features of Oracle Spatial and Graph, an option of Oracle Database - brought to you by the product managers and developers. Get technical tips, product information, and the latest news here. Visit our official product website at http://www.oracle.com/technetwork/database/options/spatialandgraph/overview/spatialfeatures-1902020.html

Search

Categories
Archives
« August 2015
SunMonTueWedThuFriSat
      
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
     
Today