Putting the data back in spatial data infrastructure

The COVID-19 pandemic has demonstrated the critical importance of sharing all types of data, both spatial and non-spatial. Spatial data infrastructure (SDI) development in Canada has progressed to the point where COVID-19 information could be shared efficiently and effectively among public health officials as well as with the general public. While there are many successful implementations of online COVID-19 resources for use by many stakeholders, there are still many efficiencies that should be implemented to improve data sharing. Read this blog post to see examples of online maps, learn how to assess your SDI based on a maturity assessment model and find out what data should be included in your SDI to make the most of your data and SDI investments.

If our online response to this pandemic has taught us anything, it’s that data sharing is difficult but essential to helping decision makers understand situations and make informed choices. Clearly pandemic management has a significant spatial data component, ranging from locations of outbreaks to contact tracing to PPE location monitoring. Fortunately, Canada’s spatial data infrastructure (SDI) and Esri web services have allowed developers and users to quickly share spatial and non-spatial data across the globe. This has allowed for the creation of many online tools, including outbreak hotspot maps using near-real-time data. In addition, online dashboards and graphs help decision makers understand and analyze current trends for predicting scenarios and deciding what to do to combat the virus.

The Public Health Agency of Canada’s COVID-19 Situational Awareness Dashboard

As a nation, we still have plenty of work to do to continue building a modern, comprehensive SDI that meets the needs of Canadians in a cost-efficient manner. We know now that spatial data and spatial data sharing are essential and even critical infrastructure for Canada’s health and wellbeing. Now is not the time to stop making important investments in Canada’s SDI to improve efficiency and extend benefits. For example, government agencies are still creating the same (or similar) geospatial data many times over in slightly different forms, and then not (or not proficiently) sharing this data to the best advantage of either governments or taxpayers.

One of the best ways of determining the current state of SDIs in Canada and what needs to be improved is to perform an SDI maturity model assessment similar to the URISA GIS Capability Maturity Model or the Slimgim maturity model. Either of these methods could be adapted for use in assessing an organization’s maturity in employing and enhancing their SDI. Maturity models are very effective as they can be applied to organizations that are just starting out or to seasoned veteran SDI organizations. For example, based on the URISA model, an assessment of the essential SDIs in Canada could look at:

• Components that enable SDI in the organization. This assesses the technology, data and human capabilities to deliver effective SDI services.
• Components that make SDI operate smoothly in the organization. This assesses the management, collaboration policies and workflows of the organization and their ability to deliver effective SDI services.

The use of a maturity model assessment is a different approach to assessing SDIs in Canada than has been used in the past. For example, previously I’ve used the score card method as outlined in my blog post, “Why Canada needs to continue developing its spatial data infrastructure”. The major advantage of a capability maturity model (CMM) approach is that CMMs are relatively well known and understood. Also, they can be and have been applied across many sectors, from language services to security assessments to IM/IT evaluations.

Characteristics of maturity model levels

Recently, several new SDIs have been under consideration or under construction. These SDIs will support a broad range of applications such as marine, environmental assessments, city infrastructure and public health. There is nothing wrong with developing each of these SDIs independently to support each specific application because the organizations that are funding the initiatives need to support their clients, users and business needs. However, each new SDI should be interoperable with the other Canadian SDIs to ensure that data ingest and export can be performed with maximum efficiency, and that each SDI can make use of services available in the other SDIs.

When developing an SDI, consider the following to ensure interoperability:

1. Stakeholders: All those involved with the development, operation and use of the SDI
2. Requirements: The list of applications, data, use cases and technology that the SDI must perform
3. Usage scenarios: Typical products or services that the SDI would be used for
4. Technical architecture: On-premises, SaaS, PaaS, IaaS or a hybrid
5. Applications: Tools to search, ingest, edit, analyze, visualize and publish data
6. Base geospatial data: Type and source of the basemap data
7. Thematic or business data: Type and source of the thematic data layers
8. Operation: The way that the parts of the SDI system work internally and externally
9. Organization: How the body of involved people are arranged to meet the SDI requirements
10. Governance: Identification of groups with authority, decision-making and accountability roles

In terms of data, there are many general categories of data that should be identified and considered in an SDI. These are:

1. Base(map) geospatial data: This data is generally common to many SDIs and is available from the Community Map of Canada and ArcGIS Online.
2. Thematic (business or operational) geospatial data: These map layers support the specific requirements of the SDI and can range from environment to air quality to bathymetry.
3. Imagery data: These georeferenced datasets are raster format and could be sourced from satellite-, aircraft-, drone- or ground-based sensors. Special consideration should be given to storage and transmission of imagery due to these files’ potentially large size.
4. Spatially-related data: These datasets support the specific requirements of the SDI, but they contain elements that require further processing to determine the specific spatial location (e.g., latitude and longitude) of the data. Spatially-related data is generally tabular and may contain street addresses, census subdivisions or postal codes.
5. Sensor-based data: These data streams are sourced from sensors often based on Internet of Things (IoT) architectures. They often are acquired as a real-time stream of sensor values collected at a known (stationary or moving) location. Examples of sensor data include stream gauges, traffic counts and vehicle sensors.
6. Real-time video: These data streams are a specific type of sensor-based data and are categorized separately because their data volumes and real-time requirements cause them to need special handling. These video streams are generally ground based. Examples include traffic cameras, security cameras and video surveillance.
7. Non-spatial data: These datasets contain attributes or other data that are independent of all geometry considerations. Examples include system documentation, policy documents and data model specifications.
8. Metadata: These datasets contain data that describes and gives information about other data. Examples of types of metadata include ISO 19115 metadata and Dublin Core.

Some of the types of data that must be considered within an SDI. From top to bottom: basemap, imagery, thematic data, traffic camera, documentation and metadata.

SDIs in Canada have effectively proven their immense value during this pandemic, but now is not the time to sit back. Issues still remain with the breath, depth and currency of the data. Some sites continue to respond slowly and do not scale in performance when needed. Also, more SDIs are required in the public health agencies so that data can be more readily shared. There’s lots of work to do and solutions are available to help out. So what’s stopping you from improving your existing SDI or creating a new SDI for the benefit of your stakeholders and the broader geospatial community?