Applying Oracle Spatial to a Very Large Insurance Problem

A presentation by Scott Tracy and Jennifer Lemus of ISO Innovative Analytics and David Lapp of Farallon Geographics at the Location Intelligence Conference in April dealt with refining the process of understanding spatial risk for automobile insurance companies. This presentation was interesting because the end solution, while geographic in nature, was not a mapping solution but rather a database solution – no maps were required or desired.

The Challenge
ISO Innovative Analytics was faced with the challenge of creating a set of risk factors derived from unstructured data, to be applied to a myriad of geographies. The risk factors had to be customizable and valid wherever the company has customers.

Basic automobile insurance rates are typically based on personal driving history, type of vehicle insured, and the nature of the driving environment and conditions in which the vehicle will operate. These risks have historically been determined by ZIP Code.

But a ZIP Code is really too large, in most cases, to be useful. In the presentation, we looked at 94109 in San Francisco (below). Robert Louis Stevenson’s poetic descriptions are included. This example shows the range of people, conditions and potential risk within this very non-homogeneous ZIP Code.

ZIP Code 94109 is non-homogeneous. Used with permission. (Click for larger image)

Factors that affect risk can include the street types, the presence of mass transit, the population density, commuter patterns, the adjacent businesses and even the weather. The table below shows the effect of different traffic generators on risk.

The effect of different traffic generators on risk. Used with permission. (Click for larger image)

In addition to the traffic generator factors, the solution had to address the fact that ISO Innovative Analytics has about 300,000,000 records that needed geo-processing. This graphic from the presentation shows the breakdown of the data quantity to be processed.

Quantity of data to be processed. Used with permission. (Click for larger image)

If you look at the past, present and future value counts, the scope of this project and the need for it to be scalable becomes even more apparent.

The solution had to be scalable, fast and flexible. Farallon Geographics looked at several possibilities such as developing software in-house, using a traditional GIS or using a spatial RDBMS. An in-house software development program would not be as time efficient and could exceed the budget for the project. Using a traditional GIS would require not only the GIS but also an adjacent database to store and retrieve data. A spatial database that was of industrial strength, such as Oracle, made the most sense in this case.

The Solution
Oracle Spatial 10g was selected – it could handle a lot of data and allow the data to be accessed by other systems (including GIS systems, query languages and APIs). Plus it offered server side geoprocessing. In addition, ISO uses SAS for standard analytics and Oracle Spatial 10g could accommodate that.

The system architecture of the selected solution. Used with permission. (Click for larger image)

Summary
It is interesting to see a large-scale geospatial solution accomplished all within a database. As Oracle Spatial continues to develop, the question of “do you always need a GIS to do geospatial processing” becomes more salient. For this application, apparently not. While the requirements could have been met with another solution, the question is, would another solution have been as easy to implement and as elegant?