Exchange data models and interoperability in spatial data infrastructure
Do you know what an exchange data model is and why it is important to have a good exchange data model? Are you stuck with a legacy data model for your database and are not quite sure how to migrate to or at least interoperate with a more modern data model? Read this blog to find out about exchange data models and how to manage them.
I was asked recently to review an exchange data model that was designed specifically for use in emergency management applications. Reviewing a data model is straightforward; however, the issue is that Esri Canada also wants to use this same data model for a variety of other applications such as utility management, real estate and transportation. Because multi-purpose data models can be complex, the question arises: can an exchange data model be developed to support diverse applications without being bloated with additional fields and attributes irrelevant to emergency management data exchange?
To find out more, let’s look at what an exchange data model is and what it’s supposed to do.
There are many ways to assess an exchange data model from both the logical perspective (logic model) and the database design perspective (physical model). First and foremost, the data model needs to be suitable for its intended purpose by having the requisite spatial and attribute field definitions for all the mandatory information. In addition, the model needs to be well designed, comprehensive, complete, logical, interoperable, have suitable cardinality, support metadata, perform well and potentially enforce data standards.
GIS practitioners see data model as a way of representing and storing geographic locations of terrestrial entities in a computer. To do this, the traditional GIS vector format is often used consisting of a representation of geographic entities as points, lines or polygons measured at a specific location at a point in time. Most often, each item of the location data includes attributes that distinguish the geographic entities being represented. For example, a road segment could be represented as a line segment with attribute fields containing information such as the name of the road, number of lanes, type of pavement and average daily traffic volume. Exchange data models are often similar to conventional operational (legacy) database data models.
GIS vector data representation diagram depicting the use of location-based vector data (points, lines and polygons) to represent various geographic entities which are stored in a database and then combined to create a map.
The most important functional requirement of an exchange data model in an SDI environment is interoperability. Data interoperability enables the sharing and integration of geospatial data between systems in different organizations and across applications and industries. This, of course, is a cornerstone tenet of a spatial data infrastructure and reaffirms the usefulness of exchange data models.
Sharing of data
Generally, SDI data sharing can be accomplished using two different approaches to creating the exchange data format.
The first approach is to have a way of converting one data model (for example, the legacy database) to another data model (for example, the exchange format) using Extract, Transform and Load (ETL) technology. In other words, field mapping of one dataset to the other dataset. This field mapping can take a lot of work to construct, especially if the two data models are complex. However, once set up, the ETL will usually function well in an operational environment. This method is most often used when there are legacy data models that are too difficult or expensive to be modified or replaced completely.
The second common approach of sharing geospatial data is to use common data models across the SDI. This means, having a “standards-based” data model that each system implements directly and the data is then shared using this data model. However, don’t confuse the standard data model with the “standards-based” interoperable interfaces such as WFS, CSW, GML, KML and shapefile. The interface is the way the systems send data to each other, the data model is how the data is “formatted” within the data container when it is exchanged. For example, data could be exchanged using a shapefile while the data model specifies how the data is “formatted” and stored in the shapefile.
The exchange data model, transferring spatial data from System A to System B, defines how the data is formatted inside the data exchange container (or file) so that System A can write the data that System B can read flawlessly.
Some examples of geospatial vector data models include Canada’s digital topographic reference product produced by Natural Resources Canada (CanVec); the Land Administration Domain Model (LADM); and Esri Canada’s Canadian Municipal Data Model (CMDM).
As noted at the beginning of this blog, the task of reviewing the emergency management data model is complex as the data model could be assessed using either of the two data-sharing approaches. Some of the systems within the emergency management SDI might use the data model as a native format but some other systems might need to ETL the data from the exchange data model into the legacy data model or vice-versa. However, with any kind of data exchange, the key requirement is that no data should be lost, changed or corrupted.
Keeping in mind the significance of emergency management applications, it’s essential that we give the data model a thorough review making sure that it fully meets the requirements of any data-sharing environment.