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 Stevensons poetic descriptions are included. This example shows the range of people, conditions and potential risk within this very non-homogeneous ZIP Code.
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.
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.
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.
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.
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?