Building The Geoweb
Why Use Incremental Updates for Geographic Information?
management, emergency response, security and defense.
Currency and Costs
What about broader applications such as urban infrastructure development, and environmental and resource mapping? What are the drivers in these domains for incremental or change-only updates? Ideally, in all these domains, current information would be available. But what does current mean? It might mean daily, weekly or monthly.
BUILDINGTHEGEOWEB
hen looking at a typical pattern for geographic information sharing today, it generally involves the ad hoc transfer of files followed by the batch processing of those files by the data consumer. Quite often, the transfer contains data that already are possessed by the consumer, who is responsible for determining what has changed and making the appropriate changes to their target database. Why does this situation still continue?
W
So why pay for the transfer and integration of 1GB of data when 10KB or less is sufficient?
Hard Time
BY RON LAKE
Ron Lake is president, Galdos Systems Inc.; e-mail: rlake@ galdosinc.com, blog: www. galdosinc.com/ archives/category/ media-center/blog.
In some applications, the state of the geography must be communicated to users in hard real time, meaning any differences between the real world and the model of that world in an application have a very high or even unbounded cost (e.g., costs in the tens or hundreds of millions or more, human deaths, etc.). This is clearly the case for applications such as emergency response, homeland security and defense. Sending a file with the location of all ships on the U.S. coast (some have moved, some haven’t, etc.) and requiring the consumer to determine which ship’s positions have changed would seem like a non starter. It clearly would be much more effective only to report the positions of those ships that have actually moved. Similarly, if emergency events (e.g., flood, explosions, etc.) take place, information on these dynamic events would be expected, without all the surrounding static information. As the impact area of one of these events evolves, the new impact area or its changes would be desired, rather than the history of the impact area with all the information that isn’t changing. In emergency and defense systems, the need to separate dynamic and static information is solved by having different encodings and protocols (e.g., OASIS Common Alerting Protocol). This often results in more complex systems in which anomalies such as getting a road closure but not the current road geometry are possible. Incremental updates seem to be required, at least for dynamic information, in evidently real-time applications such as air-traffic
Assuming there’s a desired measure of currency, the need for incremental update can be based on the ratio of changed and unchanged features within the update interval. For example, Ordnance Survey tracks the location of some 400 million features, of which only about 5,000 features change in an average day. This ratio is about 0.001 percent. Because the data volume of 400 million features is quite large, the efficiency of bulk updates is clearly quite low in this case. It could be argued that most people don’t want all 400 million features, and a much smaller data volume is required in most practical cases (e.g., “just send me the data for the city of London”). Nonetheless, assuming that the distribution of changes is relatively uniform, the ratio stays the same. I don’t know whether this ratio is typical for urban environments, but I expect it’s actually quite conservative (i.e., a typical value is much smaller). So why pay for the transfer and integration of 1GB of data when 10KB or less is sufficient? The cost of data transfer is only part of the cost of receiving and integrating geographic information updates. The cost of integration likely is greater than the transfer, and incremental updates will have a larger impact than the volume of data transferred. This will be explored in a future “Building the GeoWeb” column.
32
GEOWORLD
/JULY2O10