®

Sponsored by

GGeoeoSSciciMLML: v4: v4

ModularizationModularizationOGC TC Crystal City

March 24, 2014

OGC®

Goals for v4Goals for v4

• Make interchange of simple information simple• Modularization focused on use scenarios• Clean separation of conceptual model and implementations• XML implementation• JSON implementation?

OGC®

Requirements workRequirements work

• Review v3.2 model and develop requirements statements and dependencies

• Next step is to define scenarios for conformance classes

• Then map requirements to conformance classes

OGC®

Top Level of model– What are the requirements implied?

OGC®

Requirements generationRequirements generation

A MappedFeature: •is a kind of GML feature and SHALL inherit the attributes and requirements of abstract GML feature.•SHALL have one to many observationMethod property values each specified by a Category value. •SHALL have a positionalAccuracy property specified by a Quantity value. (is voidable)•SHALL have a resolutionScale property that specifies resolution of the geospatial location of a mapped feature. (is voidable)

OGC®

Simple dependenciesSimple dependencies

Conceptual requirements class from GML

Conceptual requirements based on SWE

Conceptual requirements based on SWE

OGC®

Dependency treeDependency tree

• Term• Category• CodeList• Enumeration• Controlled

concept

OGC®

Concept requirements…Concept requirements…

CategoryRequirements •A Category SHALL have a scalar component that is a simple token identifying a term in a code space. Informative: Used to represent a categorical value. Typical implementation is to import from SWE Common v2.0

 

TermProperties •A Term SHALL have a maximum of one preferredName •A Term SHALL have an identifier •A Term SHALL have associated metadata

GeologicFeatureClassifier•A geologic feature SHALL have one or more classifier property values specified by controlled concepts that categorize the feature.

OGC®

Proposed Conformance classesProposed Conformance classes

1. Portrayal for geologic units, faults, and contacts. Support web map services with basic lithology and age query and symbolization capabilities via OGC Styled Layer Descriptors

2. Structure observation portrayal. Support point sampling features with measured orientation of fabric

3. Geologic unit description. Multiple rock types, geologic history, geologic unit parts

4. Borehole: basic characteristics, intervals with description

5. Borehole details (additional borehole properties)

(review DIGGS, American inst. Civil engineering; german borehole ML; Tim Duffy report on ResQML in Tucson

4. Earth material details

5. Laboratory analysis (Review sensor ML v2 to meet requirements) (Ollie R.)

6. Time Scale?

OGC®

Core Schema with extensionsCore Schema with extensions

• Requires implementation approach to decoupling packages.

• Patterns: – 1. Mandatory property in base class with additional

attributes and relations in extensions class Implementation patterns

Extended class is in different package (namespace). serves as pattern for extensions to add other properties

BaseClass

+ essentialNonvoidableProperty :any

BaseClassAbstractDescription

+ essentialProperty :any

BaseClassDescription

+ context1Property1 :any+ context1Property2 :any

BaseClassExtendedDescription

+ context2Property1 :any+ context2Property2 :any

properties in base description class apply in any application

Base class description properties are typical,but not essential in all applications

Namespace 2

Namespace 1 -- base package

+description«voidable»

1..*

OGC®

Pattern 2Pattern 2

class Implementation patterns

«FeatureType»MappedFeatureTest

+ shape :GM_Object

«abstract»MappedFeatureDescriptionTest

MappedFeatureExtendedTest

+ positionAccuracy :Quantity+ observationMethod :Category

Namespace 1

Details namespace

+optionalProperties

0..*

Copyright © 2014 Open Geospatial Consortium

Optional property in base class, implemented in extension

OGC®

Pattern 3Pattern 3

• Different namespaces for different conformance classes

Copyright © 2014 Open Geospatial Consortium

class example

Namespace2::GeologicUnit2

+ property3 :int+ property4 :int

Namespace1::GeologicUnit

+ property1 :int+ property2 :int