At the recent World Map Forum in Hyderabad, I presented a paper in the SDI Seminar entitled “Spatial Data Infrastructures – A New Approach”. In the talk I noted that, in some sense, SDI technology and standards had suffered from focusing on the wrong problem space and thus, at least in part, this had lead to emphasis on the wrong standards and technology.
The essence of the talk went something like this… Rather than focusing first on national datasets and services, SDI should focus at the urban level, especially on medium to large cities. The rationale for this approach is simple enough: cities are where most of us live. Cities consume most of the planet’s energy, and generate most of the pollution and green house gases. Cities are where we need to deal with questions of overcrowding and water pollution. Security is, of course, a national, or even international, concern – but when a security event takes place, such as the ones that occurred in Mumbai, Madrid, and London, we must deal with them in a city. If there are environmental security threats, whether storms or bird flu, we will confront these threats in cities. Smart energy management is touted as part of the solution to both climate change and energy security, no argument there, but to realize these saving, it is within cities that we will have to act.
Problems such as security, energy management, pollution control, and crime prevention can be partly alleviated through better city design, information re-use, and support for collaboration amongst all of the agencies that interact in city development. Imagine a world where the mere act of everyone (architects, engineers, contractors, developers, lawyers, citizens) just doing their job led to the ongoing creation and maintenance of a complete “as built” model of the entire city. Such a model would then be used by architects to plan new buildings, by police and fire departments to enhance public safety, and by ordinary citizens to look at the potential impact of new proposed developments.
In effect, the development of SDI can be likened to the development of other types of information technology including the Internet, databases, and GIS. If we consider any vertical application (say in the urban context) such as a system for emergency response or urban planning, and thought about how we would develop it say 20 years ago, we would have found that a great deal of the money would have gone into the development of software just to provide a basic network, and messaging and persistence functionality. Since that time, the IT industry has extracted these components (e.g. databases) out of general software development, and any such solution for these problems would undoubtedly build on things like DBMS, GIS, and IP networks. Not to do so would, today, be a non starter. We believe that this also true for the emergence of SDI technology.
If one looks at the various types of vertical applications for urban environments (e.g. crisis management, urban planning, e-Government, homeland security, and so on) it is pretty clear that all of these deal with geographic information (e.g. where are the roads, where are the vehicles, etc.), and almost all involve the integration of data and services across multiple agencies in the government and in the private sector. Many of these require data to be delivered in real time (i.e. fast enough to contribute to the solution of the problem at hand), need to be event driven, and benefit from varied types of visual presentation including maps, charts, and 3D models.
SDI technology can be seen as providing part of a solution infrastructure not provided by GIS, databases, and the Internet, and their associated client tools. SDI deals with the secure movement of information (geospatial or otherwise), discovery and access to data processing services (geospatial or otherwise), and collaboration between organizations and individuals.
The choice for implementers is to try and build the SDI part of the solution themselves or to leverage existing SDI frameworks that can provide:
- Unobtrusive connectivity to data sources and services (e.g. databases and applications).
- Data transformations for source/target data differences such as differences in schemas, units of measure, and coordinate systems.
- Secure real time delivery of access to services and data.
- Fine grained delivery of data on a change-only basis.
- Publication/Subscription for both data and services.
You will see that these capabilities deal with a great number of the key requirements for vertical solutions such as urban planning, collaboration, crisis management, and emergency response, and many others. You will also note that, by refocusing SDI on urban environments, we lose nothing in terms of its application to national level problems of data discovery and data access.
Now, I am sure that someone will raise the objection that, while data and technology are easy to deal with, the real problem is people and organizations. To a significant degree, this view is correct. As in any IT problem (or any problem at all) the most important and difficult problems to deal with are people problems. I could not disagree. Therefore, given that organizational and people issues are paramount, how should this influence the design and selection of SDI technology?
To begin with, we believe that this requires SDI technology to be unobtrusive, meaning that it can be inserted into existing applications and databases with little or no changes to their existing database schemas, user-application interactions, or security. SDI should simply allow the application or database to benefit from secure delivery of data or data processing services. The more invisible the SDI, the better it is.
A further implication of the importance of people and organizations is the need to see SDI as supporting business process integration. One of the difficulties experienced by SDI implementations thus far has been the inability to populate and maintain metadata catalogues. This is because few people like filling out forms of any kind, and they like it even less if they are not directly connected to the result. I fill out my taxes because I have to and, in some years, I might even get a refund.
In the business integration approach, a large part of the metadata is a consequence of the business process itself, and thus can be obtained automatically, within the business process itself, and with little or no human interaction. This minimizes unnecessary and unexplainable actions on the parts of the user, and makes the SDI that much easier to accept. They basically use the SDI without knowing about it. Again, the more invisible the SDI, the better it is.
Finally, we would argue that being cognizant of people issues means providing data directly to the user’s application or database, but only the data that they want, and only when they want it (typically when something significant happens). This means that SDI should function not only on a user query basis (“e.g. find the data and request it”) but also on a publication/subscription basis. Providers should make known what they have to publish, and subscribers should be able to discover and subscribe to it on a change-only basis. Once an “advertisement” has been posted by the provider, they should be out of the loop. Once a subscriber creates or modifies their subscription, they should not have to worry about how the data gets to them or what remote service is invoked. You don’t chart the delivery of your magazine subscription each month do you?