Simplifying Spatial Data Collection using Optional Attributes and Ontologies

Whether you’re building a Spatial Data Infrastructure, creating a digital twin for a smart city or maintaining a large network data set, you’re probably collecting data from lots of different sources.

Perhaps you’re even making use of a data submission portal such as 1Data Gateway to streamline this data collection process?

You might find your data has subtle differences depending on how it was collected. The metadata might be different, due to different capture techniques or data authors, or perhaps your data relates to a subset of a larger schema.

These factors could make it difficult for you to compare the datasets, validate them, and collate them into one larger data set.

Customising your workflow with 1Integrate

1Integrate can now ignore attribute metadata differences (such as field length and precision) when opening data or a schema.

This is useful if you want to load a subset of data into a larger schema.

This has always been possible in 1Integrate (e.g. using temporary attributes to account for missing attributes), but now 1Integrate 3.3 and 1Data Gateway 2.5 unlock more flexible workflows to achieve this with a smaller maintenance overhead.

Use Case – US State Data Supply Chain

Let’s say, for example, you’re a US State department implementing a data supply chain workflow with a large schema that has recommended, or optional, attributes. You want to collect data through 1Data Gateway, validate it, and then incorporate it into your larger data set.

1. Set up your Session in 1Integrate.
   1. Add an Open Schema Task and define your schema. This is the full schema with every feature type and attribute, including required and optional components.
   2. Set up your Open Data Task with the same schema. This task will be used inside 1Data Gateway for the user submission.
2. Set up your specification in 1Data Gateway
   1. Select the submission defined in 1Integrate
   2. Configure the specification enabling Allow unmapped target data?

Now anyone submitting data can map the attributes they do have, without having to worry about the optional ones that they don’t maintain.

Working with Ontologies

Another creative use of this new feature is that we can now load an ontology, a hierarchical relation between feature layers, using the Open Schema task. 1Integrate has always been able to handle ontology, but now 1Data Gateway projects can leverage this capability too.

The key use of ontology within 1Integrate is that it allows you to create validation and enhancement rules and actions against a parent feature layer which will be applied to all descendent feature layers.

However, ontology provides many benefits, beyond this simplified rule writing. For example, a standard implementation of 1Integrate will supply a spatial report layer when identifying a non-conformance. This “Markup” layer provides information such as the location and a description of the issue allowing users to quickly navigate to and resolve the non-conformance. Markups can relate to a point, line or area geometry, or a non-spatial table.

As part of the spatial report layer, an issue summarization table can provide a quick glance for users detailing the feature layers and violations identified. Without the use of an ontology, you would need to deploy up to four different rules to build the summary table. Ontology provides the ability to create a single action at the top-level and collate the information into the summary table.

Use Case – Emergency Services

For 1Spatial’s NG911 Emergency Services solution, ontology allows a data contributor to perform more cross-feature layer validations. One of the biggest benefits is to ensure that the NENA Globally Unique Identifier is truly unique across all feature layers.

While 1Integrate had this capability before, without ontology, each feature layer must have its own validation and each validation would need to compare against every feature layer supplied. Since NENA defines Required, Strongly Recommended and Recommended layers, each deployment would have a specialized set of layers to compare. Ontology allows a single rule to compare all NENA layers.