The situation is even worse when you want to do an update, since you cannot know beforehand which feature (or even which bits of geometry) the update applies to. The situation is improved if there are unique identifiers for the geometry elements, but would be immeasurably better if there were actual feature types, feature instances, and unique feature identifiers.

Of course if the aggregator says that to a supplier, and the supplier is able to comply, that may only move the problem farther upstream, as that supplier may also be a consumer and aggregator of “line work” from someone else. Ultimately, the problem can only be solved by capturing features at the source, meaning directly in the software/systems from which features arise, such as GPS tracks, interactive crowd source editing (á la OSM), digitization of features in orthoimages or stereo models, and the extraction of features from LIDAR. The key thing is that we need to have access to the desired feature types to be populated at the point of data capture.

A consequence of this viewpoint is that feature type hierarchies and feature catalogues (abstract models of features as objects with typed properties, and even feature schemas) must become much more public objects, and must be shared by both the data producer and the data consumer. Major data users (e.g. municipalities, airports) need to carefully define and publish their schemas and their data dictionaries on the Internet, together with the schemas for global feature identification, preferably using a Registry Service such as Galdos INdicio™. Data capture contractors can then use these feature schemas to directly capture the desired feature instances, regardless of the raw data or analytical methods used.

Of course, publishing feature schemas naturally leads to having standard feature models, which we are now starting to see in things like CityGML and IFC for large scale information, and with national standards for smaller scale data. In fact, it may now be the case that standard feature models are more advanced for large scale data than for smaller scale data. This makes a lot of sense, since the headaches of “line work” to feature “conversion” are immeasurably greater with 3D geometry and topology and large scale information.

It is worth noting that, for feature capture at source to be effective, it is not necessary that all of the properties of the feature be captured. The most important thing is that the geometric description of the feature be captured, and that the feature be assigned a unique identifier. This is particularly important for ensuring a modicum of topological and semantic integrity if feature instances share geometry with one another that must be captured, especially if, by definition, two features share a common boundary. These types of constraints should, of course, be part of the feature model.

If, today, you still live in a “feature less” world, it is time to push back – and push feature creation back to the source. You can do your part by creating and publishing your data dictionary and feature schemas online. Capturing features as early as possible in the food chain will simplify life for everyone.

This article argues that the technical side of Spatial Data Infrastructures must be seen as a kind of Universal Service Bus, with the objective of enabling rapid interconnection of data and services to create new multi-party applications spanning multiple jurisdictions and large geographic areas. Any other interpretation of Spatial Data Infrastructure technology can be forgotten.

A Universal Registry Service

The objective of any service bus is to provide a universal mechanism whereby providers of data and services can register their offerings in such a manner that data and service consumers can easily find and integrate with or consume them. Because it applies to any service and any data type, we will call this a “Universal Registry Service”. We will also assume that it is universal in the sense of supporting open standards for both the service interfaces and for the underlying data model.

To be effective, such a Universal Registry Service must be highly extensible, and yet it must still provide direct support for key data types such as the geometry (e.g. location, shape) and interconnectedness (topology) of information concerning the real world. Users will want to find services based on various criteria, including geospatial, classification, associations, and other properties; for example, a typical query might be “find me a service for showing the distribution of crime rate and educational facilities, and which can assist us with computations on this information for the State of California”. Moreover users may be interested in data processing services, or data access services, or both – a user may go looking for data to find services, or go looking for services to find data. The extensibility of the Universal Registry Service cannot be over emphasized. Registries developed only as the basis of data and/or service catalogues such as CSW-ISO or CSW-INSPIRE are far too limiting for this purpose. What is required is a registry service with an extensible data model such as CSW-ebRIM.

CSW-ebRIM provides a complete, non-relational data model that makes it easy to capture information about web services, data stores, documents, and sensor data streams, including all of the associated supporting artifacts (e.g. schemas, CRS definitions, units of measure). CSW-ebRIM is able to express relationships between various objects such as data, services, and other artifacts, and it provides powerful classification mechanisms that make it easy to create and exploit all manner of taxonomies and hierarchies. CSW-ebRIM is also a completely spatial data model, enabling any data object to have one or more geospatial properties; in addition, it makes schema definition simpler and schema migration much easier than conventional relational or geo-relational models.

A Universal Service Bus

The key infrastructure for the sharing of data and for the wide area integration of data and services is the Enterprise Service Bus (ESB). Once a service is discovered (e.g. through the Universal Registry Service – as in the diagram below), the consumer accesses the service by sending messages across the ESB. In many cases, of course, one would like this process of discovery and integration to be both automatic and re-usable. In many cases, the objective of discovery and integration is to build a multi-agency application. The Universal Service Bus (USB) — which we define as a component that provides interactive access to and orchestration of services, together with automated data publication/subscription — should make that easy. Even in cases where the objective is simply data access, consumers should be provided with the ability to request the data once and have the data stay automatically in synch with the source, at least until the consumer decides that different data is required. The USB should provide a maximum of utility and services to the community.

A Universal Service Bus and Registry Service

The Universal Service Bus must enable providers of data and services to easily “advertise” service endpoints and determine if they can subscribe to that service, make interactive requests, or both. Ideally, consumers of data and services can create subscriptions by selecting from the advertised offers, possibly adding additional constraints such as constraining the data to a particular region, or to a particular time windows, etc. Subscriptions can then be either push (e.g. automatically detect changes at the source) or pull (e.g. based on time markers) the desired data to the consumer. Whenever the conditions of a subscription are met, data changes should be automatically transferred from publisher to consumer. No action should be required by either party. Data should be deliverable from database to database, or GIS to GIS, and may involve dynamic data transformations applied en route, such as change of coordinates or change of schema. The process should be largely transparent to both parties. There should be no need for the publisher to maintain lists of subscribers, and no need for custom security handling. All data transfers should be reliable, secure, fine-grained and automatic.

We should be going beyond conventional notions of SDI and geo-database replication to think in terms of Universal Service Buses and Universal Registry Services. This is the means to faster and more cost-effective deployment of multi-agency applications.

While social networks have been enormously important in linking people together, there is another kind of linking that will be at least as important in the coming years, although it will never be as visible. This is linking within the community of machines. By a community of machines, I do not mean the network of machines that supports only (or almost exclusively) human interaction, although at some point any community of machines must indeed interact with humans. I am referring to the network of machines that acquire, process, interpret, and present information to humans, often in real time, in order for us to make more effective and timely decisions about events in the world around us. This community of machines is much less understood in the popular media and in the popular imagination, and yet it is every bit as vital to our future.

What then do machines need to communicate with one another, and what does it mean that we have a community of machines?

I should start by saying that I am not in any way talking about artificial intelligence, at least not in the sense of machines being self-aware or having any idea of what they are doing. The sort of communication that I am talking about does, however, relate to conveying meaning from one machine to another. Consider, for example, the difference between sending a picture of a Word document and the Word document itself. In the first case, only a human being could determine the title of the document, or perhaps the author and the date of publication. In the second case, a computer program could quite easily extract all three pieces of information. The difference between these two cases is in the information that is transmitted and in how it is encoded. We might phrase this in terms of the kinds of questions that could be answered by processing the received information using a computer program. Note that we are not talking about deducing implicit meaning by processing the received information. We don’t expect to determine whether or not the author was happy or not when the document was being written; while it might be inferred from the author’s choice of words, we are talking only about the explicit encoding of information. I know who the author is, because the word “author” appears in front of their name. In a similar way, in machine-readable data, there is an explicit model of the document that says such-and-such a string denotes the author of the document.

A similar example arises in the transmission of design information. In conventional Computer Aided Drawing (CAD), a drawing is encoded as a set of geometric elements (lines, squares, points, symbols, etc.) without regard to what these elements mean within the application domain in which they are used. A human being can easily understand and read CAD drawings, and interpret the labels (e.g. door, beam, ground wire) to associate meaning with the geometric elements. A computer program cannot. In conventional CAD drawings, we cannot ask the software to color the doors red; we can only highlight a layer in the drawing and color it red, or select a set of line elements and do the same.

In the so-called Building Information Model (BIM) encodings, a built structure is modeled in terms of entities and entity relationships that are meaningful (to humans) in a selected domain (e.g. building structures), and associated with these entities and relationships are geometric and topological elements or properties. In BIM encodings, unlike conventional CAD drawings, it makes perfect sense to ask the software to color all the windows red, or all of the doors blue.

These two examples illustrate the basic elements of machine communication. The critical part is that there is a model for the information exchanged in the communication. This model provides the context by which the information is understood by humans, and can be processed (e.g. colour the windows red, italicize the author’s name) by machines. Note that, broadly speaking, two different sets of humans are involved in the process. In the first group are the end recipients of the information, the ones who say “Yes, I read other works by Dickens”. In the second group are the programmers that create the programs that receive, process, and transform the data for consumption by the first group. The first group cares about the actual content of what is transmitted, but may not care at all about the difference between the picture of the document and the document itself (as long as they get pictures of every page). The second group requires the model of the transmitted information in order to do anything beyond the most basic receipt and storage of what is received. Machine communication is really about the communication between programmers with respect to models of the data to be exchanged between machines.

So why does all this matter? To begin with, whether we make the measurements remotely or in situ, measurements that are transmitted from sensing devices are typically processed through multiple steps before they are presented for human viewing and interpretation. In the case of remotely sensed imagery, for example, the images are processed to compensate for atmospheric effects or to classify or “interpret” the image (e.g. find areas that are “bright” in the IR indicating the presence of water) and, of course, to enable the image to be geo-registered. Having the data be machine-readable is more or less essential in dealing with any kind of measurement information; however, it goes much farther than that. Think about the shape or geometry of roads and buildings. A picture may be worth a thousand words, but it does not tell us which buildings are connected to one another, or how those connections are achieved. Nor can a picture tell us which sensor values should be associated with which wall surface area or room volume. But machines can “know” these things and be architected to share this information with one another.

One often hears the expression “We cannot control or understand what we cannot measure”. This is indeed true. Moreover, the problems that we are facing in our physical environment are very serious and we will need to take a more scientific/engineering approach to these problems, using the best measurements we can acquire, and the best models that we can construct.

Evidence-based decision making is critical to all our futures and, increasingly, those are urban futures. We can better prepare for an earthquake if we can forecast which buildings or structures are most at risk, determine which routes might offer the safest access to and exit from impacted areas, and estimate what might be the potential effect on human life if the infrastructure supporting water, transportation, electricity, and so forth is impacted by the event. Such forecasts require not only models of earthquakes, but also extensive information on the distribution of structures, roadways, and utilities, their types, date of construction, and value, as well as detailed demographics by age, income, etc. To continuously acquire, process, forecast, and distribute the simulation results to emergency decision makers requires ongoing communication amongst multiple machines, including those responsible for property assessment, building/roadway/utility design, event (e.g. earthquake) simulation, and for the communication of impact scenarios to emergency planners and responders. A permanent and evolving “social” network of machines is essential to such an activity. The same argument can be made in our preparations for and responses to floods, hurricanes, rising sea levels, increasing drought, and rising global temperatures.

One can truly say that the last decade has been the decade of social networks and, while I think there will be no decline in their importance, the next decade will belong more to structured machine-readable data — the social network of machines.