"Seegrid will be due for a migration to confluence on the 1st of August. Any update on or after the 1st of August will NOT be migrated"

GPGIM 1.5 Features

Contents

Feature-centric model

Being the first release of GPML to use GML 3, version 1.5 of the GPlates Information Model deals with data in terms of high level Feature data rather than low level geometric representations.

Plate-tectonic reconstruction

All Features used by GPlates gain properties such as plate ID and geological lifetime. These properties enable GPlates to reconstruct them through geological time around the surface of the Earth.

Export of instantaneous snapshots of Features

For those programs unable to compute plate-tectonic reconstructions themselves, GPML supports "Instantaneous" features, snapshots of geological features that have been pre-reconstructed to a specific time. All geometry is expressed in paleo-coordinates for the convenience of the external application.

Time-dependent properties

Many properties of reconstructable GPML Features support variation of their value across geological time. This can be done as interpolation between a set of fixed samples, a constant value, or as an aggregation of these methods over specific time windows.

Feature revision history

All gpml:Features have a unique feature id and a unique revision id. The feature id is created once when the feature is first created; a new revision id is created when the feature changes. A history of superceded revision ids is used to help manage the features' past revisions.

Supports user sub-categorisation of features

A common problem when moving to a feature-centric model is how to accurately model real-world features without overlap of similar entities and without making a feature model that is too specialised.

Just as gml:name and gml:description allow users to refine specific feature instances with additional information, gpml:subcategory permits users to refine entire classes of gpml:Features, provided that these subcategories are functionally equivalent to the original gpml:Feature definition. Just as with gml:name, a codeSpace attribute can be applied to separate one subcategorisation system from another.

A good example illustrating the need for user-defined subcategories is Seamounts and Guyots. Real-world Seamounts are referred to as "Guyots" when the Seamount has been eroded and has a flat top - a useful indicator for paleo-depth.
  • A Guyot might be seen as a specialisation of Seamount, but this does not warrant an explicit subclass, since they still share identical properties. Furthermore, having the model split into Seamount(any) and Guyot leaves potential ambiguity for any seamount data - there is no way to distinguish Seamount(any) from Seamount(definitely-not-guyot)
  • Splitting the model into Seamount(not-guyot) and Guyot does not work, since there will be many datasets that refer to both cases as simply "Seamount", plus many frustrated geoscientists may want to create some Seamount data without going into what particular kind of Seamount it is.
  • In general, any similar split done at the model level will be inappropriate, because these categorisations are highly subjective. One particular researcher may be interested in a third previously unresearched category of Seamounts, with flat bottoms. The gpml:subcategory property will allow them to tag their data with this new class of Seamount. GPlates will still understand how to manipulate this new type of feature, because it is functionally equivalent to gpml:Seamount. Our researcher's new subcategory won't interfere with others, because it can use a different codeSpace, just as gml:name does.
Topic revision: r4 - 15 Oct 2010, UnknownUser
 

Current license: All material on this collaboration platform is licensed under a Creative Commons Attribution 3.0 Australia Licence (CC BY 3.0).