Publication Date: 2018-01-26

Approval Date: 2018-01-22

Posted Date: 2017-12-03

Reference number of this document: OGC 17-020r1

Reference URL for this document: http://www.opengis.net/doc/PER/t13-NG003

Category: Public Engineering Report

Editors: Johannes Echterhoff, Clemens Portele

Title: OGC Testbed-13: NAS Profiling Engineering Report

OGC Engineering Report

COPYRIGHT

Copyright © 2018 Open Geospatial Consortium. To obtain additional rights of use, visit http://www.opengeospatial.org/

WARNING

This document is not an OGC Standard. This document is an OGC Public Engineering Report created as a deliverable in an OGC Interoperability Initiative and is not an official position of the OGC membership. It is distributed for review and comment. It is subject to change without notice and may not be referred to as an OGC Standard. Further, any OGC Engineering Report should not be referenced as required or mandatory technology in procurements. However, the discussions in this document could very well lead to the definition of an OGC Standard.

LICENSE AGREEMENT

Permission is hereby granted by the Open Geospatial Consortium, ("Licensor"), free of charge and subject to the terms set forth below, to any person obtaining a copy of this Intellectual Property and any associated documentation, to deal in the Intellectual Property without restriction (except as set forth below), including without limitation the rights to implement, use, copy, modify, merge, publish, distribute, and/or sublicense copies of the Intellectual Property, and to permit persons to whom the Intellectual Property is furnished to do so, provided that all copyright notices on the intellectual property are retained intact and that each person to whom the Intellectual Property is furnished agrees to the terms of this Agreement.

If you modify the Intellectual Property, all copies of the modified Intellectual Property must include, in addition to the above copyright notice, a notice that the Intellectual Property includes modifications that have not been approved or adopted by LICENSOR.

THIS LICENSE IS A COPYRIGHT LICENSE ONLY, AND DOES NOT CONVEY ANY RIGHTS UNDER ANY PATENTS THAT MAY BE IN FORCE ANYWHERE IN THE WORLD. THE INTELLECTUAL PROPERTY IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, AND NONINFRINGEMENT OF THIRD PARTY RIGHTS. THE COPYRIGHT HOLDER OR HOLDERS INCLUDED IN THIS NOTICE DO NOT WARRANT THAT THE FUNCTIONS CONTAINED IN THE INTELLECTUAL PROPERTY WILL MEET YOUR REQUIREMENTS OR THAT THE OPERATION OF THE INTELLECTUAL PROPERTY WILL BE UNINTERRUPTED OR ERROR FREE. ANY USE OF THE INTELLECTUAL PROPERTY SHALL BE MADE ENTIRELY AT THE USER’S OWN RISK. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR ANY CONTRIBUTOR OF INTELLECTUAL PROPERTY RIGHTS TO THE INTELLECTUAL PROPERTY BE LIABLE FOR ANY CLAIM, OR ANY DIRECT, SPECIAL, INDIRECT OR CONSEQUENTIAL DAMAGES, OR ANY DAMAGES WHATSOEVER RESULTING FROM ANY ALLEGED INFRINGEMENT OR ANY LOSS OF USE, DATA OR PROFITS, WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR UNDER ANY OTHER LEGAL THEORY, ARISING OUT OF OR IN CONNECTION WITH THE IMPLEMENTATION, USE, COMMERCIALIZATION OR PERFORMANCE OF THIS INTELLECTUAL PROPERTY.

This license is effective until terminated. You may terminate it at any time by destroying the Intellectual Property together with all copies in any form. The license will also terminate if you fail to comply with any term or condition of this Agreement. Except as provided in the following sentence, no such termination of this license shall require the termination of any third party end-user sublicense to the Intellectual Property which is in force as of the date of notice of such termination. In addition, should the Intellectual Property, or the operation of the Intellectual Property, infringe, or in LICENSOR’s sole opinion be likely to infringe, any patent, copyright, trademark or other right of a third party, you agree that LICENSOR, in its sole discretion, may terminate this license without any compensation or liability to you, your licensees or any other party. You agree upon termination of any kind to destroy or cause to be destroyed the Intellectual Property together with all copies in any form, whether held by you or by any third party.

Except as contained in this notice, the name of LICENSOR or of any other holder of a copyright in all or part of the Intellectual Property shall not be used in advertising or otherwise to promote the sale, use or other dealings in this Intellectual Property without prior written authorization of LICENSOR or such copyright holder. LICENSOR is and shall at all times be the sole entity that may authorize you or any third party to use certification marks, trademarks or other special designations to indicate compliance with any LICENSOR standards or specifications.

This Agreement is governed by the laws of the Commonwealth of Massachusetts. The application to this Agreement of the United Nations Convention on Contracts for the International Sale of Goods is hereby expressly excluded. In the event any provision of this Agreement shall be deemed unenforceable, void or invalid, such provision shall be modified so as to make it valid and enforceable, and as so modified the entire Agreement shall remain in full force and effect. No decision, action or inaction by LICENSOR shall be construed to be a waiver of any rights or remedies available to it.

None of the Intellectual Property or underlying information or technology may be downloaded or otherwise exported or reexported in violation of U.S. export laws and regulations. In addition, you are responsible for complying with any local laws in your jurisdiction which may impact your right to import, export or use the Intellectual Property, and you represent that you have complied with any regulations or registration procedures required by applicable law to make this license enforceable.

1. Summary

The National System for Geospatial-Intelligence (NSG) Application Schema (NAS) is an ISO 19109 compliant application schema that defines the conceptual model for identifying and encoding feature data in the U.S. National System for Geospatial-Intelligence (NSG). NGA utilizes the open source software tool ShapeChange as an integral piece in NAS development. This tool is used to take NAS-based UML models and create Extensible Markup Language (XML) and Resource Description Framework (RDF) based schemas. Testbed-12 began development of capabilities for extracting profiles supporting specific mission functions from the full NAS content. Testbed-13 further refined the approach to NAS Profiling by investigating how a specific profile ("Urban Military Profile") can be processed in an automated way and used to derive implementation schemas for the OGC standards CDB and CityGML.

This OGC Engineering Report describes:

  • The specification of a NAS-based Military Urban Profile as a Unified Modeling Language (UML) model (chapter 5);

  • How mission-specific sub-profiles can be specified and maintained using ShapeChange and the new ShapeChange Profile Management Tool (chapter 6); and

  • How the model and profile information are processed to derive output for

This work provides insights into:

  • The requirements and constraints on managing profiles of complex ISO 19109 compliant application schemas such as the NAS; and

  • Using a model-driven approach to generate implementation schemas of an ISO 19109 compliant application schema profile for different environments.

The target audience of this document is anyone interested in these topics. The implementation environments discussed in this report are the OGC standards CDB and CityGML. The profiled application schema is the NAS.

This report assumes that readers are familiar with the key concepts and technologies discussed in this document. This document does not provide an introduction to them, but the table below provides a brief summary and pointers to more information.

Table 1. Key concepts and technologies discussed in this document
Topic Overview and additional information

Modeling spatial data

The content and structure of spatial data along with any constraints important for the integrity of the data is typically specified in an application schema, a conceptual schema for data required by one or more applications.

The fundamental unit of spatial data is the feature, which is a digital record of anything in the real-world that matters for the target applications. An application schema, therefore, models features.

Application schemas are modeled as specified by ISO 19109 (Rules for application schemas), typically using UML as the formal language to describe the schema.

Note
 A feature modeled according to ISO 19109 can, but does not need to have, geometric properties. This is an important distinction to certain implementation technologies, where a feature must have at least one, and often exactly one, geometric property.
Note
 ISO has also specified recently how to describe application schemas using OWL, but this approach has limitations since the base types used in application schemas for spatial and temporal geometry or topology, metadata, coordinate reference systems, etc. are only specified in the ISO standards - using UML diagrams. The associated UML model for those types ("ISO/TC 211 Harmonized Model") is incomplete, too, as it, for example, lacks documentation for most elements in the model. OWL ontologies derived from that model exist, but include many UML artifacts and do not reuse existing ontologies used by the semantic web community.

Two aspects are essential here:

  1. A machine-readable data description is required for automated mechanisms for data management.

  2. A schema on the conceptual level greatly helps to interpret data and transform it consistently between different representations, for example, between an XML or JavaScript Object Notation (JSON) file used for data exchange between systems and a tabular database used to store and maintain the data.

Model-driven software development

A software development methodology that focuses on creating and exploiting models on a conceptual level (e.g., an ISO 19109 application schema). As conceptual schemas, these aim at abstract representations of the knowledge and activities that govern a particular application domain, rather than the computing concepts to handle data.

Once mature, such models can be used to consistently derive implementation schemas (like XML schemas, JSON schemas, SQL DDL, Esri Geodatabases, etc.), code (like Java class stubs and interfaces) or other representations (like documentation) in an automated way and using consistent rules.

The Object Management Group (OMG) introduced the terms Platform Independent Model (PIM) and Platform Specific Model (PSM) to distinguish between models that are independent of a particular technology or platform and those that describe how that model could be realized on a particular type of platform.

This is related to item 2 in the previous row. For spatial data, the focus in standardization has mostly been on deriving implementation schemas for XML-based data exchange. The concepts are specified in ISO 19118 (Encoding). The OGC Geography Markup Language (GML) specifies in Annex E standard rules to convert an application schema in UML to a GML application schema (XML Schema).

ShapeChange

ShapeChange is a tool that supports model driven software development using ISO 19109 application schemas. Originally developed in the early 2000s to support the automated generation of GML application schemas from ISO 19109 application schemas in UML it has since then been extended to support additional targets including

  • JSON schema

  • SQL DDL

  • Esri Geodatabases

  • RDF/OWL

  • other XML encoding rules

  • Schematron

  • documentation in HTML or DOCX

The standard encoding rule like the one in Annex E of GML (see above) have been extended to support additional conversions to implementation schemas, often supporting richer UML profiles used by communities. This is also the case for the NAS, see below.

ShapeChange also supports transformations of models. Often the transformations are used to convert a conceptual, platform-independent model to a platform-specific model. A commonly used transformation is the Flattener, which can be used to simplify complex data structures, for example for use in tabular data structures like in SQL, Esri Geodatabases and the GML Simple Feature Level 0 Profile.

NAS

The National System for Geospatial Intelligence (NSG) Application Schema (NAS) specifies an NSG-wide model for geospatial data.

Part 1 of the NAS specifies a technology-neutral logical Platform Independent Model that determines the syntactic structure used to represent the semantics specified by the NSG Entity Catalog (NEC). From it, using Model Driven Architecture (MDA) techniques, technology-tied Platform Specific Models (PSM) may be automatically derived and directly employed in system development. This includes, for example, GML application schemas.

ShapeChange has been used in several OGC testbeds to derive and enhance the processes for deriving such PSMs for the NAS. Several additional conversion rules have been specified - and implemented in ShapeChange - to derive adequate PSMs for the NAS.

NAS Profiles

As the NAS specifies an NSG-wide model for geospatial data that supports a wide variety of domains and missions it is advantageous to define subsets of the NAS that meet specific requirements. These NAS profiles may be published and then used to develop a variety of derived artifacts. See here for more information.

In OGC Testbed-12, profiling of ISO 19109 application schemas and especially the NAS was analyzed [1]. See in particular the chapter Profiling.

Feature types vs. object types

In addition to features, an application schema may model data types (structured data, without identity), unions (data types with choices between a set of options), enumerations (closed list of codes), and code lists (open list of codes).

The UML profiles of some application schemas also contain another type of classes, so called "object types", to represent classes that are not feature types. These classes have no stereotype, or a specific stereotype like <<type>>. Typically, such object types represent plain objects with identity. They are used to encode structured data in a referenceable way (since an object has identity). Some application schemas have a more specific characterization of what an object type represents. In the NAS, for example, object types do not have geometry, and support analytical use cases. NAS feature types, on the other hand, do have geometry, and support mapping and visualization use cases.

ShapeChange distinguishes between feature and object types. Transformation and conversion rules can treat these two types of classes differently, depending upon the intended outcome. However, ShapeChange does not assume that feature types always have geometry, and that object types do not.

When processing an application schema with ShapeChange, it is important to understand which modeling constructs can be represented in a specific output (such as a feature catalogue, an SQL DDL schema, an XML Schema, an ontology, or an ArcGIS workspace), how the representation looks like, and the implications. In an SQL DDL schema, for example, feature and object types can be represented by tables. In an ontology, they are both represented by OWL classes. In an ArcGIS workspace, on the other hand, features are considered to be objects whose spatial extent is given by a single simple feature geometry. Objects that do not have a spatial extent are represented by object classes.

When deriving implementation schemas from a given application schema, care must be taken on how the feature and object types from the application schema are processed and how they will eventually be represented in the implementation schema.

CDB

The OGC CDB standard defines a standardized model and structure for a single, "versionable", virtual representation of the earth. A CDB structured data store provides for a geospatial content and model definition repository that is plug-and-play interoperable between database authoring workstations. CDB was approved as an OGC standard in 2016.

CityGML

CityGML is an open data model and XML-based format for the storage and exchange of virtual 3D city models. It is a GML application schema. The aim of the development of CityGML is to reach a common definition of the basic entities, attributes, and relations of a 3D city model. This is especially important with respect to the cost-effective sustainable maintenance of 3D city models, allowing the reuse of the same data in different application fields.

A CityGML Application Domain Extension (ADE) specifies additions to the CityGML data model. Such additions comprise the introduction of new properties to existing CityGML classes or the definition of new features types in a new XML namespace. Section 10.13 in CityGML 2.0 specifies rules for ADEs.

The relationship between the NAS and CityGML has already been investigated in OGC Testbed-6 in 2009 - using the current versions of the NAS and CityGML at that time. For the NAS, an urban profile called UTDS was used. The findings are documented in the report OWS-6 UTDS-CityGML Implementation Profile.

1.1. Requirements

The following requirements have been addressed by the work documented in this Engineering Report:

  • Extend ShapeChange to support generating (NAS-based) output to configure the feature data in a CDB dataset consistent with a NAS profile UML model

  • Create the files that specify the structure and content of a vector dataset based on a NAS profile UML model for use in CDB

  • Extend ShapeChange to support generating a schema representing a CityGML ADE from a NAS profile UML model

  • Create a CityGML ADE from a NAS profile UML model

  • Document the requirements for NAS profile UML models to derive the CDB and CityGML outputs

1.2. Prior-After Comparison

1.2.1. Related OGC Working Groups

Work on the NAS has been reported to the Defense & Intelligence (D&I) Domain Working Group (DWG) on several occasions. The NAS Profiling work will be reported to this DWG.

The current situation in relevant OGC Standards Working Groups (SWG) is:

  • CDB SWG:

    • The current version OGC CDB 1.0 supports only a fixed set of feature types in Tiled Vector Datasets, supports no schema information and has limitations inherited from the use of the Digital Geographic Information Exchange Standard (DIGEST) as the starting point for organizing features and attributes and from the use of Shapefiles for storing feature tiles.

    • Change Requests for CDB 2.0 may be submitted until December 31, 2017.

  • CityGML SWG:

    • Section 10.13 in CityGML 2.0 specifies rules for ADEs. An ADE is an XML schema that imports CityGML schemas and extends them in either of two ways:

      • New feature types are defined within the ADE namespace and are based on CityGML feature types (abstract or concrete).

      • Existing CityGML feature types are extended by application specific properties (global property elements in the ADE namespace).

    • Beyond this, CityGML does not specify any constraints on how XML Schema may be used in an ADE.

Since the findings and recommendations may also be of interest to these SWGs, they will also be communicated to them.

1.2.2. Summary of the findings and recommendations

General remarks

This section summarizes the findings and recommendations related to the CDB and CityGML standards and their implementations.

The findings and recommendations related to CDB are more specific than they are for CityGML. The main reason is that the NAS is in some ways closer to CityGML than it is to CDB.

CityGML is conceptually and technically based on the same OGC and ISO standards that also underpin the NAS. This includes the capability for defining application schemas according to the General Feature Model, using encodings supporting such application schemas, etc.

This is not the case for CDB, which uses a different framework, has no support for application schemas and very limited capabilities to support user-defined classification of feature data, etc.

Therefore, not surprisingly the work documented in this ER has identified more clearly what information from the NAS (or similar application schemas) can or cannot be represented properly in CDB. There are far less constraints to consider in the transformation from NAS to CityGML than there are in the transformation from NAS to CDB.

Out-of-scope work items for this testbed activity are:

  • What are the typical implementation efforts required to transform NAS data to CDB or CityGML?

  • What are the typical implementation efforts required to support such data in CDB implementations?

  • What are the typical implementation efforts required to support such data in CityGML implementations (server and clients)?

  • What is the impact, if another profile of the NAS is used?

  • What are the criteria for transforming NAS into CDB or CityGML and using/developing implementations supporting these standards over using/developing implementations that support NAS data directly?

A future work item recommendation is building on the results of this testbed and investigating the above questions.

CDB

As CDB is now an OGC standard, it seems reasonable to consider if there are potential benefits from improving the alignment between CDB and the OGC standards baseline / the common practices in the OGC community.

One aspect is related to the scope of CDB. If the focus of CDB is not only performant visualization, but also includes support for spatial analytics and feature data, the CDB SWG should consider supporting the ISO/OGC General Feature Model and the concept of application schemas as specified in ISO 19109.

Currently, CDB does not support application schemas and is limited to only a fixed set of feature types and feature properties are limited to simple values (text or numbers).

Potential support for application schemas in CDB 2.0 would imply that implementations would need to support more flexible and potentially richer content. That is, there would also be a cost involved, which needs to be balanced with the benefits from the new capability.

When considering adding support for application schemas in CDB, several aspects need consideration:

  • Encoding:
    Currently, CDB uses Shapefiles to encode feature data. In the future, CDB should support other encodings, too, including standardized encodings and encodings that support descriptions of the schema of the data. Potential candidates include GML, Esri Geodatabases, GeoPackage, etc. The NAS specifies encodings for GML and Esri Geodatabases. Since no NAS data was used in CDB in Testbed-13, no recommendations about future encodings were discussed in Testbed-13.

Note
 GeoJSON is another candidate for a commonly used encoding, but it needs to be understood that GeoJSON is by design essentially schema-less.

  • Schema description:
    Each encoding that supports application schemas comes with rules on how to express the application schema in an implementation schema for the encoding. In GeoPackage and Esri Geodatabases, the schema information is stored in tables, for GML the schema is provided as an XML schema ("GML application schema").
    Since no encoding recommendation was made as part of the NAS profiling work in Testbed-13, one approach had to be selected for expressing a schema for NAS data in CDB. It was decided to specify the NAS profile as a GML application schema, because

    • GML is already one of the encodings of NAS data,

    • the conversion of an application schema to a GML application schema is well-defined, and

    • GML application schemas can support simple schemas (GML Simple Feature Level 0 profile) as well as more complex schemas.

  • Schema complexity, rich content:
    For Testbed-13, it was decided to limit the complexity to the GML Simple Features Level 0 Profile. This decision was taken for practical reasons: to be compatible with the complexity supported by Shapefiles and, therefore, implementations of OGC CDB 1.0. Chapter 7 has details about the limitations and constraints of such an approach for representing NAS data that makes use of the rich capabilities of the application schema, for example, object metadata or other objects without geometry that are shared between multiple features. If NAS data does not make use of these capabilities, the limitations are less significant.
    If CDB is not mainly about performant visualization, the CDB SWG should consider supporting richer data representations, including, for example, objects that are not features.

  • Feature and attribute dictionaries:
    Currently, semantic information about CDB feature data is provided through feature and attribute dictionaries. The feature dictionary is fixed and specified as part of the standard. For attributes, a pre-defined list of attributes is part of the standard, but additional attributes may be defined. See Chapter 8 for details.
    For cases where an application schema is provided, it should be clarified if the feature and attribute dictionaries are still required and, if the answer is "yes", what their relationship is.
    Note that CDB dictionaries currently do not support a capability to express relationships between features.
    Whatever the role of the dictionaries is in a future CDB standard, several changes should be considered:

    • Remove the DIGEST legacy, including

      • the rigid patterns for codes of feature and attribute types,

      • the fixed two-level hierarchy for categories and sub-categories of feature types and their codes

      • the rules for subtypes of feature types

    • Clarify how multiple dictionaries should be handled, for example it is unclear if units of measure need to be redefined in every attribute dictionary and how identifier conflicts are handled.

See also the OGC Testbed-13 CDB Engineering Report for discussion about additional aspects of CDB.

CityGML

As discussed in Chapter 9 the expectation for a CityGML Application Domain Extension (ADE) for a NAS profile is that it should reflect the conceptual model as well as possible. That is, transformations to simplified structures in the implementation schema should be used only where required by CityGML.

Another aspect to take into account is that it is the expectation in the CityGML community that tool support for an ADE will always require software development.

A consequence of this is that an ADE is an option for a profile of the NAS that is standardized by the community or as part of the NSG, but less for a "mission-specific" profile of the NAS that is created for a specific dataset or data collection effort.

The general question of how ADEs should best be specified seems to be a work-in-progress. Different ADEs under development are taking different approaches.

A related question is, if CityGML would benefit from a conformance class that states which modelling capabilities may be used in an ADE so that CityGML-aware software supporting that ADE conformance class could be expected to handle it without software development (similar to the Simple Feature profiles for GML). This would allow the generation of ADEs for "mission-specific" NAS profiles, too.

Note
 This is only raised as a question and is not phrased as a recommendation or change request as an analysis of the potential benefits is out-of-scope of the worked documented in this report.

If an ADE has been defined, and software is available that supports this ADE, then defining "mission-specific" profiles of the ADE to strictly subset the content could be possible following an approach similar to GML profiles or metadata profiles. Further details are provided in the future work section on CityGML ADE Profiles.

In any ADE for a NAS profile, due to the broad thematic coverage in the NAS, many features will typically be subtypes of _CityObject. A question that may be debated is, should these be part of a CityGML ADE or to what extent is this still proper CityGML data? Is this more useful than keeping the data in the NAS GML encoding? This discussion is, in particular, relevant for objects that are not features in the NAS and which do not include a geometry property (for example, almost all of Human Geography). Are CityGML implementations able to process / make use of such objects? To answer such questions it would be important to analyze the benefits or problems by using NAS data that has been converted to a NAS-based CityGML ADE in real scenarios.

Finally, it should be pointed out that the question of which information from the NAS maps to which element in the CityGML schemas is to some extent uncertain as the CityGML feature types have vague semantics. The model does not include any definitions for the types or their properties. That is, any mapping relies on an interpretation based exclusively on the names of the model elements. This is a known open issue that was also identified during a similar exercise in OGC Testbed-6 (see Change Request 09-039, item 1, Lack of definitions).

1.3. What does this ER mean for the Working Group and OGC in general

This ER is mainly informational and is not a proposal for a new OGC standard, but about applying standards - and learning more about how well they fit together. Due to the strong link to NGA’s NSG application schema (NAS), the work is expected to be of interest to the Defense & Intelligence DWG.

In addition, it should be of interest to the CityGML SWG and the CDB SWG as this ER discusses how to use profiles of the NAS and data captured for such profiles in applications based on the CDB and CityGML standards.

This ER may also be of interest for others following or considering a model-driven-approach using ISO 19109 application schemas in UML and who are interested in the topics of profiling, CityGML or CDB.

1.4. Document contributor contact points

All questions regarding this document should be directed to the editors:

Table 2. Contacts
Name Organization

Johannes Echterhoff (editor)

interactive instruments GmbH

Clemens Portele (editor)

interactive instruments GmbH

The editors thank Paul Birkel, Dave Wesloh, Arne Schilling, Terry Idol, and Carl Reed for their reviews and constructive comments.

1.5. Future Work

1.5.1. Use NAS data in CDB and CityGML implementations

General remarks

The NAS profiling work in Testbed-13 was mainly a desk study. Testing rich NAS data, including data that makes use of objects that are not features, in implementations of the CDB and CityGML standards would be helpful to validate - or invalidate - the findings and recommendations in this report and provide firmer recommendations to NGA, the CDB SWG and the CityGML SWG.

In order to provide recommendations to NGA and others with similar application schemas like the NAS, the scope of such future work should include analyzing the practical benefits and obstacles as well as implementation efforts for all parts of the workflow of preparing and using a specific NAS dataset in CDB or CityGML implementations.

A ShapeChange-related aspect in such future work would be to identify and specify clearly the parameters/options that one wants to vary when deriving an ADE or GML-SF0 profile for a specific NAS profile for a specific use case. This could then be used to design and implement mechanisms that make it simple to select/switch these options when configuring ShapeChange configurations for such workflows.

This report includes sections that describe how the ShapeChange configurations created in this testbed may be adapted to other NAS profiles or use cases: for GML Simple Feature Level 0 Profiles, CDB dictionaries and CityGML ADEs. In particular the process to adapt the configuration for deriving a GML Simple Feature Level 0 Profile currently requires a good understanding of the standards, the NAS and ShapeChange.

CDB

The work documented in the report analyzed how CDB might be improved to support data according to the NSG application schema (NAS), its profiles or - in fact - any other application schema according to ISO 19109. The findings and recommendations should be considered by a future testbed that uses NAS data in CDB implementations and/or CDB SWG.

If the CDB SWG or a future testbed would consider alternative encodings for feature data, then it needs to be agreed how to specify the implementation schema for an application schema like a NAS profile. For example, for GeoPackage a database template with the schema information but no features could be specified. For JSON, a JSON Schema could be specified.

In order to support model-driven workflows, ShapeChange could then be enabled to derive such application schemas - either building on an existing capability (like the targets for JSON Schema or Esri Geodatabases) or developing a new target (e.g., for GeoPackage) to support the technical exploration in the testbed.

CityGML

As documented in the findings related to CityGML generating ADEs for NAS profiles seems to be adequate mainly for standardized profiles. Exploring the use of NAS data in CityGML would allow us to take a closer look at this conclusion as well as at the design decisions taken in this testbed to derive CityGML ADEs for NAS profiles using a repeatable approach.

1.5.2. Evaluation of OCL constraints that restrict place representations

The NAS uses Object Constraint Language (OCL) constraints to restrict how the position(s) of a feature can be represented: by points, curves, surfaces, physical addresses, and location by identifier.

Note
 OCL is a formal language for defining rules that apply to UML models.

One goal of the derivation of a GML-SF0 NAS profile schema in Testbed-13 was that the schema only contained feature types with a single geometry property. To generate such feature types, restrictions on place representations were extracted from OCL constraints.

Since the implementation of an OCL evaluator to identify such restrictions was not a goal for Testbed-13, an expedient approach was chosen. It relies on specific patterns in the naming and structure of relevant OCL constraints. If the OCL expressions that restrict place representations did not follow a specific pattern, this approach would not be viable. To support such a scenario, the development of an OCL evaluator to identify place restrictions should be considered.

1.5.3. Analyzing relevance of OCL constraints for GML-SF0 schema

In Testbed-13, only specific information of OCL constraints of the NAS profile is used to generate the GML-SF0 NAS profile schema. The workflow to generate the GML-SF0 schema extracts this information and then transforms all OCL constraints so that they are no longer available for generating Schematron assertions.

It could be useful to perform a detailed analysis of the NAS OCL constraints, to determine which of them would be relevant for the creation of Schematron assertions for the GML-SF0 NAS profile schema. The analysis should also look at how such constraints could be transformed to be valid in the transformed schema.

As an example, consider constraints that limit a codelist-range during inheritance. If transformed appropriately when deriving the GML-SF0 schema, Schematron assertions could be generated to more thoroughly validate GML-SF0 XML instance data.

1.5.4. Extending the feature set for application schema profiling

Chapter 6 documents how application schema profiles can be defined using ShapeChange and the ShapeChange Profile Management Tool (PMT). The functionality was demonstrated in Testbed-13. A number of suggestions for improving the capabilities of the tools were discussed:

  • Handling of association classes by the PMT should be improved. For example, if an association class is removed from the profile, the corresponding association (and roles) should be removed as well. Same for adding an association class.

  • The PMT should implement the design for profiling constraints which has been developed in Testbed 12 (see the Testbed 12 ShapeChange ER, chapter 7). Special cases like generating OCL constraints to specify that a property from a supertype is not allowed for a specific subtype could then be considered as well.

  • The profiling design developed in Testbed 12 contained additional profile parameters, which the PMT should implement, such as setting the abstractness of a class.

  • Additional views could be developed to simplify the process of defining a profile. For example, specific categories of classes could be hidden. A user would then be able to only work with feature types. Another simplification would be to hide the complex UML package structure within an application schema, instead listing all schema classes directly in the application schema package.

1.5.5. CityGML ADE Profiles

Creating a CityGML ADE for a "mission-specific" profile of an application schema, in an ad-hoc fashion, is considered to not be feasible since there is an expectation that support for an ADE will always require development of ADE specific software.

However, if the purpose of such a profile is just validation of content restrictions, two approaches could be feasible:

  • Create and use an ADE schema defining the subset, and reference it similar to how it is done for GML profile schemas. - A GML profile schema restricts the GML options for representing geometry. The GML profile schema is referenced through an annotation within a GML application schema. Software that understands GML profiles read the annotation, and use the GML profile schema to validate the geometries in XML data that conforms to the application schema. Software that does not understand GML profiles simply ignores the annotation and omits the additional validation step. The difference for CityGML ADE profiles would be that the reference of the ADE profile would not be contained in another ADE schema but in actual CityGML data.

  • Create and use a separate Schematron schema to define and check the content restrictions. - This approach would not require the creation of new XML Schemas for "mission-specific" ADE profiles (which would have to have the same target namespace as the full ADE, and can therefore lead to confusion). The approach is similar to how metadata profiles are typically defined.

If CityGML shall support "mission-specific" ADE profiles, these two approaches should be investigated in the future.

1.6. Foreword

Attention is drawn to the possibility that some of the elements of this document may be the subject of patent rights. The Open Geospatial Consortium shall not be held responsible for identifying any or all such patent rights.

Recipients of this document are requested to submit, with their comments, notification of any relevant patent claims or other intellectual property rights of which they may be aware that might be infringed by any implementation of the standard set forth in this document, and to provide supporting documentation.

2. References

  • ISO 19103:2015, Geographic information - Conceptual schema language, December 2015

  • ISO 19107:2003, Geographic information - Spatial schema, May 2003

  • ISO 19109:2015, Geographic information - Rules for application schema, December 2015

  • ISO 19115-1:2014, Geographic information - Metadata - Part 1: Fundamentals, April 2014

  • ISO 19136:2007, Geographic information - Geography Markup Language (GML), September 2007

  • OGC 15-113r3, Volume 1: OGC CDB Core Standard: Model and Physical Data Store Structure, Version 1.0, February 2017

  • OGC 16-007r3, Volume 11: OGC CDB Core Standard Conceptual Model, Version 1.0, February 2017

  • OGC 12-019, OGC City Geography Markup Language (CityGML) Encoding Standard, Version 2.0, April 2012

3. Terms

3.1. Abbreviated terms

API

Application Program Interface

ADE

CityGML Application Domain Extension

CDB

Common Database (OGC standard)

DDL

Data Description Language

DIGEST

Digital Geographic Information Exchange Standard

DWG

(OGC) Domain Working Group

EA

Enterprise Architect (UML modeling tool from Sparx Systems)

GML

Geography Markup Language (OGC/ISO standard)

GML-SF

GML Simple Features Profile (OGC standard)

GML-SF0

GML Simple Features Profile, Level 0

GSIP

GEOINT Structure Implementation Profile

HTML

Hypertext Markup Language (W3C standard)

ISO

International Organization for Standardization

JSON

JavaScript Object Notation (IETF standard)

MDA

Model Driven Architecture

NAS

NSG Application Schema

NEC

NSG Entity Catalog

NGA

(U.S.) National Geospatial-Intelligence Agency

NSG

(U.S.) National System for Geospatial-Intelligence

OCL

Object Constraint Language (OMG standard)

OGC

Open Geospatial Consortium

OMG

Object Management Group

OWL

Web Ontology Language (W3C standard)

PIM

Platform Independent Model

PMT

(ShapeChange) Profile Management Tool

PSM

Platform Specific Model

RDF

Resource Description Framework (W3C standard)

SWG

(OGC) Standards Working Group

SQL

Structured Query Language

S-UTDS

Specialized-Urban Topographic Data Store

TDAS

Topographic Data Application Schema

TDS

Topographic Data Store

UML

Unified Modeling Language (OMG standard)

URI

Uniform Resource Identifier

URL

Uniform Resource Locator

UTDS

Urban Topographic Data Store

W3C

World Wide Web Consortium

XML

Extensible Markup Language (W3C standard)

XSD

XML Schema Definition Language (W3C standard)

4. Overview

NGA utilizes the open source software tool ShapeChange as an integral piece in NAS development. This tool is used to take NAS-based UML models and create XML and RDF based schemas. Testbed-12 began development of capabilities for extracting profiles supporting specific mission functions from the full NAS content. Testbed-13 has further refined the approach to profiling the NAS by looking into a repeatable capability to derive implementation schemas for CDB and CityGML for such profiles.

In Testbed-13, an "Urban Military Profile" of the NAS was used as a starting point. This profile defines the vector content requirements for urban centric profiles. This profile is intended to be capable of being used to define the data model requirements for an Urban Military CDB and simultaneously an Urban Military Application Domain Extension (ADE) for use in CityGML.

The following describes the NAS profiling workflow executed in Testbed-13.

NAS profiling workflow
Figure 1. NAS profiling workflow

  1. In a first step the NAS-based Military Urban Profile was specified as a UML model, i.e. an Enterprise Architect project file. This is described in chapter 5.

  2. In a second step a mission-specific sub-profile can optionally be specified using ShapeChange and the ShapeChange Profile Management Tool. Chapter 6 describes how profiles can be managed and processed using ShapeChange.

  3. In the next step, the model and profile definition are processed to derive a CityGML ADE and output for CDB:

    1. For CDB, CDB feature/attribute configurations of the profile and a GML-SF0 application schema of the profile are generated. Chapter 7 and chapter 8 describe how to derive these results for NAS-based profiles and explain the ShapeChange enhancements implemented in Testbed-13.

    2. For CityGML ADE, the model of the profile is transformed to a CityGML ADE implementation model that is used to generate a GML application schema that is a CityGML ADE. Chapter 9 describes how to derive these results for NAS-based profiles and explains the ShapeChange enhancements implemented in Testbed-13.

The decision to restrict the GML application schema for CDB to the GML Simple Features Level 0 Profile was taken for this testbed for practical reasons: to be compatible with the complexity supported by Shapefiles and, therefore, implementations of OGC CDB 1.0. See 7.1 for more details. Limitations resulting from this approach are documented in 7.4. The CDB SWG and the Testbed-13 CDB NAS Profile ER should consider supporting richer data representations in order to better support complex ISO 19109 application schemas (for example the NAS).

The underlying use case for the work documented in this report is that

  • Organization A has defined a NAS profile for a specific purpose and has then captured data based on this profile;

  • Organization B now wants to use that NAS data (together with other data) either in its CDB application or in its CityGML application, which requires the transformation of the schema and data according to the rules of CDB or CityGML in order to configure the application so that it can handle the data.

5. Definition of the NAS Profile

5.1. Introduction

This chapter describes how the UML model of the NAS profile used in Testbed-13 was created.

A profile for content that is typically used in an urban setting was used in Testbed-13. This was done in order to support CDB and CityGML work that builds on the schemas generated from this profile.

However, from the perspective of the work described in this report, the urban context is mainly used as an example for creating a specific profile of the NAS. The focus is not defining the "best" urban military profile, but on defining a repeatable capability for NAS profiles in general. In other words, the key requirement on the profile is not that it is 100% correct from the point of view of a domain expert, but it should be representative for the NAS and include all of the key modeling elements relevant to an urban setting.

5.2. Identifying the subset of the NAS

At first, the content of the profile had to be identified. The Specialized-Urban Topographic Data Store (S-UTDS) subset of the TDS v6.0 Entity Catalog (topographic-profile of an older version of the NAS) has been used as the starting point for the "Urban" Military Profile of the NAS for the purposes of this testbed. The subset can be identified from the S-UTDS v6.0 Extraction Guide by inspecting column H ("S-UTDS EG") on the "Data_Collection_Organization" tab.

Additional documents related to the Topographic Data Store (TDS) profile of the NAS 6.0:

Note
 A minor derivative of v6.0 is currently in-use in NGA data production. The derivative is known as v6.1 and varies in how it handles metadata. There is no difference in the "feature aspects" from v6.0.

In the next step, the TDS v6.0 subset content has been migrated into a model that is a profile of the NAS v8.0 (published in late 2016).

More information about the NAS v8.0 is available at https://nsgreg.nga.mil/doc/view?i=81111.

5.3. Generating the UML model in EA

Once the content of the NAS profile has been identified, a reference UML model in EA had to be generated for the profile. This was achieved using the tooling that NGA uses to manage the NAS.

overview
Figure 2. Overview of the NAS profile

The package diagram above provides an overview of the contents of the profile. The diagram shows the top-level packages of the NAS included (i.e., the packages with stereotype bundle) as well as the second-level packages that contain the feature types (packages in the bundle packages, with a stereotype leaf).

The list of feature types in each package that are part of the profile used in Testbed-13 are listed in Annex B.

5.4. Adding CityGML and relevant CityGML ADEs

One testbed task was to explore generating a CityGML ADE for the NAS profile. In order to process the NAS profile and CityGML together in the derivation of the CityGML ADE, the CityGML application schema was added to the UML model for the NAS profile.

When generating a new CityGML ADE, good practice is to re-use existing ADEs in that process. To explore this case, the CityGML UtilityNetwork ADE was selected as an example for the following reasons:

  • Utilities are important aspects in an urban setting

  • That ADE includes feature types different than just buildings which are the focus of most CityGML datasets; and

  • Availability of a UML model for the ADE

The CityGML application schema and the CityGML UtilityNetwork ADE are used when processing the profile to generate a CityGML ADE for the "Urban Military Profile" (that extends CityGML and, potentially, existing ADEs).

6. Processing a profile with ShapeChange

This chapter describes the workflow to define and process a profile of a NAS-based application schema using ShapeChange and the ShapeChange Profile Management Tool (PMT).

6.1. Providing the basis

A schema profile is tied to a particular version of a given schema. In order to define such a profile with the PMT, the schema and its dependencies need to be known. This is achieved by loading the model that contains the schema with ShapeChange, and then exporting the model into a ShapeChange-specific XML format (SCXML).

Note
 The model that is loaded may already contain profile definitions. ShapeChange also supports a transformation to load profiles from external files (with SCXML format) into the model. If profiles are available in the model, ShapeChange can create a model profile and export the result. This would ensure that subprofiles (that are defined for the model profile using the PMT) only contain subsets of the model elements defined by the model profile. For example, a NAS Urban Military profile could be created and exported by ShapeChange. This profile could then be used as the basis to define subprofiles, for example focusing on just transportation or building aspects, in an ad-hoc fashion using the PMT.
SC workflow modelexport
Figure 3. ShapeChange workflow to export a model
Note
 The ShapeChange configuration to export the NAS profile to SCXML is contained in Annex A.

6.2. Defining a profile

The ShapeChange Profile Management Tool (PMT) is a web application to edit application schema profiles. The definition of a consistent profile for a large application schema like the NAS is a non-trivial task. The PMT provides a number of features to support the user in this task.

The PMT can load UML models from files in SCXML format. Profiles can be added to the model, edited, copied, and deleted.

A model browser is available to navigate through the model. A text-based search can be used to look up specific model elements.

Packages, classes, and their properties can be added to or removed from a profile. The visual display of a model element changes accordingly. For selected packages and classes, the PMT offers actions for mass processing contained model elements (e.g. adding all properties of a class to the profile).

When adding a model element to the profile, the PMT automatically adds relevant related model elements. For example, when adding a subtype to the profile, its supertypes as well as mandatory properties and their value types are automatically added to the profile. The same applies to automatically added types. Likewise, upon removing a model element from the profile, the PMT would remove related elements. For example, when a supertype is removed, then its subtypes are removed as well. If a property is removed from the profile, then its value type is removed - but only if it is not used as value type by another property.

The consistency of a profile is constantly checked. Consistency issues are reported. An issue report contains a link for the user to jump to the corresponding model element.

In the following screenshot, feature type 'Road' has been selected. The details pane on the right shows available profile actions and profile parameters (e.g. defining the geometry types that are allowed for the feature type). Similar panes are available for packages and properties.

PMT TB13NAS Road Profile
Figure 4. Defining a profile with the Profile Management Tool - feature type 'Road' with profile assignments

For quickly making profile assignments for the properties of a class, a tabular view of the properties is available (see Figure 5).

PMT TB13NAS Road Properties
Figure 5. Defining a profile with the Profile Management Tool - properties of feature type 'Road'

When a package is selected, a similar view is available for the classes contained in that package.

Additional information about the selected model element, like its stereotype, super- and subtypes, descriptors (such as alias, definition, and description), and tagged values can be accessed via the info pane (see Figure 6).