Spatial Databases Spark Debate
I participated on a panel at the Pitney Bowes MapWorld conference on what was to be a discussion of the trends on Location Intelligence. But the panel quickly turned the discussion toward a rather lengthy dialog on spatial databases and whether the kinds of transaction limitations in Oracle Spatial or MS SQL Server warrant putting ALL geospatial data into the database.
The amount of tuning that needs to be done might not serve all applications efficiently. John Cassidy from Tele Atlas argued that his company specifically does not deliver data in any one format and to let the customer determine how best to store a link-node data set of street files. This became especially relevant when considering how often some customers want updates to street files making versioning and database replication key considerations. Arthur Berrill of Pitney Bowes MapInfo argued that a tiered database design approach to both data and applications needs to be considered in order to maximize performance. Ed Katibah of Microsoft, an audience member, offered that both Virtual Earth and Google Earth use a distributed file system for raster data management and specifically eschew a spatial database storage approach. Katibah also argued that data should be stored in multiple databases, a more federated approach, with different architectures specific to the specialized application that needs to be served. JS Turcotte of Korem was equally skeptical about putting everything into a single database. He noted that companies like Teradata and Netezza, that typically manage very large databases and have indicated support for geospatial information, have not offered any viable solutions.There was some consensus that web services and OGC WMS/WFS specifications offer supporting alternatives as a means to data access.