|
 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?
More about this author...
|
