The document you are reading is a technical reference for how GPlates uses and stores data according to its information model. It is a direct transliteration of the XML file that GPlates uses internally to describe that information model. It is intended to be an aid for those editing the GPGIM XML file and anyone creating software that produces or consumes GPML or other GPlates-compatible data.
Table of Contents:-A list of all the types of property value that GPlates understands, including Enumerations (a set of string values defining categorical values), and Native Properties (types of complex or "structural" values that are built in to GPlates).
Currently interiors holes are not yet supported in GPlates.
Consists of two variables, "begin" and "end", which are the points in time (in millions of years ago or Ma) in which the feature came in and out of existence respectively.
"Begin" and "end" can also be set to "Distant Past" and "Distant Future" respectively.
You can draw the line through them, but it is more accurate to store the individual points and their positions in space and time.
In the Rotation hierarchy, will depend on a Platelike AbsoluteReferenceFrame.
This is no longer editable within the GPlates UI to prevent data getting out of sync.
The identifier used for magnetic picks evolved to be a combination of letters and numbers, of the form (C|M)[number][combination of letters].
The first letter indicates Cenozoic or Mesozoic era, followed by a number indicating the chron's position in the sequence. However, the early measurements of isochrons were not very high resolution, and many smaller polarity reversals were missed, only to be discovered later as techniques improved. Rather than renumbering everything as new isochrons were discovered, letters from a-z were added after the number, so M14a refers to the first sub-chron located inside the 14th major chron, and if a polarity reversal were located inside that, it would be named M14aa, and so on.
This would result in names such as C34ad, which translates to a Cenozoic isochron, major region 34, sub region a, sub region d.
They must be unique for each revision, generated at revision creation time.
The final revisionId string should be restricted to the characters that are acceptable for XML Ids: http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/#Id
The definition of every possible property that can be included by features - what the property name is, how often it can appear in a single feature, and what type of value is supported.
This is currently used for small circle radii.
Note that the name is based on GML's gml:centerLineOf, and as such is using the American spelling of "center".
Note that the name is using Australian / Canadian / NZ / UK English spelling of "centre". This is inconsistent with what we've done above with g(p)ml:centerLineOf. Great. I don't know how to fix this, it's a pretty terrible situation. --jclark 20150113
Due to Isochrons getting split into pieces in PLATES data, it must support more than one conjugate on the other side of the MOR.
The plate Id is a general-purpose plate Id or specific plate Id for motion of a cluster of Features.
This property is a qucik way to capture user data for depth or time series data. For example, measured values (such as water density) at various depths for a single sample site: 'depth1=value1, depth2=value2, depth3=value3'.
A 'hidden but useful' property inherited from GML.
The complete orientation of the plane is the strike (stored in the centerLineOf geometry property), the dip angle (stored in this property), and the dip direction (stored in the dipSide property).
This property is optional. If not present, it indicates that there is no information about the dip available. The property is unspecified or indeterminate.
The complete orientation of the plane is the strike (stored in the centerLineOf geometry property), the dip angle (stored in the dipAngle property), and the dip direction (stored in this property).
This is currently only used for rasters.
Note that we can use LineStrings or Polygons or a combination of both.
As a convenience, you may also include references to other gpml:Features here, as the 'evidence' of the HotSpotTrail. These can be the physical features that indicate the path the HotSpot took- Volcanoes, Seamounts, maybe even AseismicRidges - we have to be pretty forgiving with what features the user wants to associate with the HotSpotTrail.
In the case of MidOceanRidge and ContinentalRift, isActive should be "True" if the ridge is actively spreading, and "False" otherwise.
In the case of IslandArc, isActive is "True" if the IslandArc is in the process of being created via subduction, and "False" otherwise.
Not to be used for reconstruction purposes, as these properties would be an imprecise representation of the crust on each side in many cases. Primarily of interest to the MidOceanRidge feature, where it is used for the purpose of a richer description.
Not a time-dependent property because, for MidOceanRidge at any rate, that's insanity. A MidOceanRidge -generates- crust. For other boundary features, like SubductionZone, this property is only really used as annotation, (i.e. "this SZ is mostly consuming plate 541") and doesn't need to be over-complex.
This property doesn't support multiple plateIds per side for similar reasons to the ones above; in the case of MidOceanRidge, the usefuless of this property hinges on the potential to e.g. interpolate between both sides of the MOR and determine velocity. If more than one plateId per side were supported, topology would have to be taken into consideration, and pieces would have to move at different rates - and so the MOR would have to be broken up into segments, PLATES style. Perhaps when we get segmented MORs in the next release GPGIM, we can consider these extra possibilities. Until then, there's really no point in making this more complex than it needs to be.
Assuming there is a suitable centerLineOf supplied, and understanding that the order of points in the line matters, we can establish a "Left" and "Right" side of the centerLine.
Particular implementations of AbstractRockUnit can include BasicRockUnit for simple free-text descriptions plus an extent, or more complex rock unit definitions.
More than one gml:name can be assigned, the distinction between two names being handled by the 'codeSpace=' attribute of gml:name.
This is a Computational Geometry Algorithms Library (CGAL) parameter.
This is a Computational Geometry Algorithms Library (CGAL) parameter.
Since a Feature in GPML will often correspond to a PLATES polyline (if a PLATES file was the original source of data), we include an optional reference to a Plates-compatible header object. This is used to keep metadata around if we import from a PLATES data file.
A feature reference because these data sometimes exist independently of each other, so they should both be gpml:Features.
Optional because you may get a bunch of picks all in close proximity and things stop being clear, odd datasets, etc.
This identifier indicates which Polarity Chron this pick is linked to: other picks on different ship-tracks will share this Id if they belong to the same Chron. e.g. "C34b".
Note that we want this to be unique for each Chron, so the tradition of packing extra info like the 'young/old' value onto the end of the Id ("C34o0.2") is discouraged; polarityChronOffset can be used to store the young/old offset, and any miscellaneous extra information can go in metadata, gml:name, gml:description, or gpml:subcategory as appropriate.
It is called "polarity chron" because it is the 'chron' of all positions sharing the same polarity.
A number from 0.0 to 1.0, indicating the proportion from 'young' to 'old'; 0.0 = young, 1.0 = old; This property stores the offset of this pick's chron position compared to the synthetic chron.
This is currently used in MotionPath features as the plate that the motion is relative to.
Not to be used for reconstruction purposes, as these properties would be an imprecise representation of the crust on each side in many cases. Primarily of interest to the MidOceanRidge feature, where it is used for the purpose of a richer description.
Not a time-dependent property because, for MidOceanRidge at any rate, that's insanity. A MidOceanRidge -generates- crust. For other boundary features, like SubductionZone, this property is only really used as annotation, (i.e. "this SZ is mostly consuming plate 541") and doesn't need to be over-complex.
This property doesn't support multiple plateIds per side for similar reasons to the ones above; in the case of MidOceanRidge, the usefuless of this property hinges on the potential to e.g. interpolate between both sides of the MOR and determine velocity. If more than one plateId per side were supported, topology would have to be taken into consideration, and pieces would have to move at different rates - and so the MOR would have to be broken up into segments, PLATES style. Perhaps when we get segmented MORs in the next release GPGIM, we can consider these extra possibilities. Until then, there's really no point in making this more complex than it needs to be.
Assuming there is a suitable centerLineOf supplied, and understanding that the order of points in the line matters, we can establish a "Left" and "Right" side of the centerLine.
Particular implementations of AbstractRockUnit can include BasicRockUnit for simple free-text descriptions plus an extent, or more complex rock unit definitions.
As a large amount of data may be imported from Shapefiles, and there is not always an obvious way to map from (arbitrary) shapefile attributes to GPML property names, the user may need to set up a mapping that defines which shapefile attributes should be mapped, and the GPML property they are mapped to.
For example, the user may have a data set with "PLATEID" and "NAME" shapefile properties - these need to be mapped to the Feature's gpml:reconstructionPlateId and gml:name properties. Storing the mapping is important so that data can be returned to the original shapefile attributes later.
Every gpml:Feature can optionally have one or more subcategories assigned to it. These are free-form text strings, and behave very similarly to the gml:name property; they also possess a 'codeSpace=' attribute to indicate what convention was used when assigning this subcategory to this Feature.
Use of the .subcategory property is entirely optional, however it is useful in several situations. There are many possible subcategories of real-world:Features, and these are highly subjective, depending on scientist, dataset, and area of research. Permitting arbitrary subcategorisation in the GPGIM has two benefits. One, GPlates can to continue to treat those real-world:Features as the appropriate gpml:Feature since any subcategory must have the same properties as the parent gpml:Feature. Two, it allows the scientist to have a finer grain of control over the categorisation of those real-world:Features without messing around with XML trying to extend the GPGIM.
An example: Seamount s and Guyot s. A Guyot is a special case of Seamount with a flat top. Functionally, they are identical. A problem arises; do we create a GPGIM feature for both of them, or just use Seamount for both cases? Some scientists and datasets may not care about the distinction, and wish to treat everything as a gpml:Seamount without being forced to go over the data and classify everything. On the other hand, a "Guyot Expert" would be very interested in the distinction between the two. The .subcategory property allows you to do this, without forcing you to.
This is a more accurate way of keeping track of the past, older revisions of a feature.
It will be purged on occasion to ensure files do not get bloated from many small changes. Newly superseded revisionId s get unshifted onto the front/head of the list, older ones are at the end/tail of the list.
A simple linear 'version number' would fail if a feature collection was concurrently modified by multiple users and then merged.
Typically used to store the time instants at which Flowline and MotionPath features output points along the time-path.
HotSpots can be associated with zero, one, or more HotSpotTrails. Zero because there might not be any data about the movement of the HotSpot; One will be the most common case; and Two or more for disjoint HotSpotTrails. It is a reference to a HotSpotTrail, because HotSpotTrails may be rotated independently, and should be gpml:Features in their own right.
While GPlates will treat each individual gpml:Feature separately, it is intended as a reminder that this Feature is part of a larger whole.
A common problem in PLATES datasets is the lack of any deformable geometry. This is often hacked around by creating multiple 'features' for the same real-world thing, for example, an Isochron getting subducted might have have been 'cut up' into multiple PLATES 'IS' features, to simulate the Isochron slowly disappearing. One day, this property will be used by a magical algorithm to undo all the 'cutting up' of features done in data sets for the purpose of hacking deformable geometry into PLATES.
The definition of every possible class of Feature that can be used by GPlates - what the name of the feature is, and what properties it supports. To avoid redundancy in definitions, Features are able to 'inherit' properties from a parent Feature type, and some of the feature definitions are purely abstract features for the purpose of grouping commonly-used properties together.
Don't get too hung up on names of things. Remember that this is a technical document describing to GPlates how the data is structured. If feature type X and feature type Y have the exact same properties, and should be treated the exact same way by the code, then there's no real reason to duplicate their definitions.
We derive from TotalReconstructionSequence because that's what an AbsoluteReferenceFrame is - a set of FiniteRotations plus associated gml:TimeInstants. The difference is that an AbsoluteReferenceFrame has a name associated with it (gml:name) and a type, like the "WesselMuller2006 HotSpot reference frame".
There is no feature called 'RelativeReferenceFrame': relative reference frames are implicit.
The description of how this absolute reference frame was created/derived will be in meta data. meta data will be very complex and we'll get into it later.
Assorted contour-like data and (in future releases) gridded data share AbstractField as a parent class.
Types of contour (and later, gridded) data include: Bathymetry, Topography, Gravimetry, Magnetics, GlobalElevation, OceanicAge, CrustalThickness, DynamicTopography, MantleDensity, HeatFlow, SedimentThickness, Roughness, SpreadingRate, SpreadingAsymmetry, Stress.
This is because all contoured data is picked from a gridded source, and similarly with most stand-alone outline data. In addition, there are many, many types of gridded data that we may wish to use in the future. With most of these types, it still makes sense to be able to pick outlines and contours from the grid - they are useful in many cases.
An AbstractGeologicalContact is simply the surface along which two different rock types are juxtaposed.
An AbstractGeologicalPlane by itself will not be instantiated; You want a subcategory of GeologicalPlane(BeddingPlane, CleavagePlane), or perhaps a FoldPlane, or one of the various specialisations of GeologicalContact.
Use BasicRockUnit for free-form text descriptions or simple extents of the geological rock units on each side of a GeologicalContact (such as Fault, Unconformity).
Specifying an abstract base allows for possible extension later on, e.g. GeoSciML interoperability.
In contrast to TangibleFeature, this deals with geometry that has been arbitrarily created, or possibly derived from a TangibleFeature. For example, InferredPaleoBoundary is a plate boundary that is assumed to have existed, even though it has long since been subducted under the surface. OldPlatesGridMark is a sequence of lines defined in PLATES data files for annotation.
The term "Aseismic Ridge" is a very general term used by geoscientists that can apply to almost any nonspecific ridge, with the only defining quality being the inactivity of the feature.
For example, sections of a HotSpotTrail might be a chain of Seamounts which are contiguous enough to form a ridge. As well as being Seamounts, the structure can also be termed an "Asesimic Ridge". However, the term can also be easily applied to an Extinct Ridge, or now-inactive remnant spreading ridge (see MidOceanRidge).
As far as the GPGIM is concerned, this might make AseismicRidge into an abstract parent of some sort- however, that would imply that all features inheriting from AseismicRidge would be inactive, throughout their entire lifespan. This is unacceptable, especially considering planned improvements to MidOceanRidge to allow for partial segments of a MOR to become inactive, and also considering that a HotSpot's trail is formed of Volcanoes as well as Seamounts that may be active for some time and later become inactive.
However, there still exist some situations where the term "AseismicRidge" may be the only term applicable, where a ridge is not known to be any other specific type of ridge. AseismicRidge exists in the GPGIM for this purpose.
This is the simplest way to define a basic rock unit type while allowing for future extension.
BasicRockUnit allows you to describe one side of a GeologicalContact using the standard free-form text properties, plus a polygon extent.
gml:name and gml:description can be used for this specific rock unit.
gpml:subcategory can be used to specify which general categories this BasicRockUnit belongs to, for example, a "Basalt" BasicRockUnit, or "Ophiolite" can be used to define an ophiolite belt, and so on.
Basins can be categorised into many types, and some of these types overlap or are subjective. Rather than attempting to define a fixed subset of these types, it is recommended to use the .subcategory property defined in AbstractFeature.
Suggested subcategories are "Extensional", "Convergent", "IntraCratonic", "Compressional", "Sag", "Thermal", "Erosional", "Unknown".
Usually measured in m (depth).
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
Similar (but not identical) to ClosedPlateBoundary, but for crust type differences (oceanic-continental). It can be rotated via the usual reconstruction mechanisms, and the geometry of this boundary is represented in present-day-coordinates.
A simple geometric view of a PlateSlab's closed boundary, possibly derived from a TopologicalClosedPlateBoundary. It is reconstructable, and so the polygon is encoded using present-day coordinates. This type of plate boundary might be most useful as a "Grid Mask" for gridded data relating to the plate.
Some standard properties are very useful for a ClosedPlateBoundary. The .reconstructionPlateId property inherited from ReconstructableFeature will allow us to associate one (or more, potentially) gpml:plateId s with the plate boundary, gml:name can be used to name the plate, and validTime indicates the lifetime of this plate polygon.
Present day coastline, but can still be reconstructed with the rest of them as a visual aid.
Functionally, this behaves similarly to MidOceanRidge, but a ContinentalRift is defined for continental crust only.
See Dictionary of Earth Science p132. Includes Shield regions.
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
Seismic Tomography (MantleDensity) is used as a source of data to create DynamicTopography.
For instance, near a Continental-Oceanic boundary, there will be a region of TransitionalCrust which is not clearly defined as either oceanic or continental, but there will also be some continental crust which has been pulled apart by the extension, not enough to define new oceanic crust but enough to break the continental crust.
Map-view of Faults. Fault now inherits from AbstractGeologicalContact, so we gain the ability to specify what geological rock units lie on either side of the Fault.
Note in the description that a Fault has "observable relative displacement": A Fault is defined by displacement. This is what distinguishes a Fault from an Unconformity. A Detachment is a subcategory of Fault; generally a Detatchment implies massive displacement involved.
We already inherit a centerLineOf via AbstractGeologicalContact and AbstractGeologicalPlane. This line is the 'Strike' of the Fault. This should ideally be a directed line where the order of points matters because we need to define what lies on either side.
We also inherit the description of the 'Dip' of this Fault via AbstractGeologicalContact and AbstractGeologicalPlane. There are two properties, .dipSide and .dipAngle.
There are many different ways to classify a Fault, and they are highly subjective, so remember that we have the 'subcategory' property available.
Suggested subcategories are (1) "Thrust" : A Thrust fault is a term often given to a special case of reverse or compression fault where the hanging wall has thrusted completely over the foot wall. Additional information about e.g. Folding (which might warrant additional subcategories), or perhaps describing specific patterns of the Thrust e.g. "Snake Head", make this an ideal candidate for the .subcategory property, (2) "Detachment" : Often used to describe massive movements of rock created from e.g. detachment of rock from a subducting plate which has moved onto the overriding plate.
Here's what Dictionary of Earth Sciences p201 has to say: Approximately plane surface of fracture in a rock body, caused by brittle failure, and along which observable relative displacement has occurred between adjacent blocks. Most faults may be broadly classified according to the direction of slip of adjacent blocks into dip-slip, strike-slip, and oblique-slip varieties. The term 'dip-slip fault' comprises both normal and reverse slip faults, and the special cases of low-angle lag and thrust faults. Strike-slip faults {wrench, transform, transcurrent} result from horizontal displacement {dextral or sinistral movements} and on a regional scale may involve transpression and transtension.
Unlike GeologicalPlane(BeddingPlane) and GeologicalPlane(CleavagePlane), which are direct field observations, a FoldPlane is inferred based on many different observations. However, it still shares the same basic properties of a surface indicator, a strike, dip side, and dip angle.
In PLATES, small fracture-zone lines are used in a segmented fashion- each segment of the line has an appropriate time of appearance and time of disappearance, to simulate the growth of the fracture zone.
For GPlates and GPML, a more ideal solution would treat the entire FractureZone as one complete gml:Feature, with its geometry being time-dependent (possibly using locus geometry). For the present, it is better to follow the older PLATES method, since that is how much of the data is structured and it would require a human to reconstitute the segments.
gpml:FractureZone has an advantage over the old PLATES format; all gpml:ReconstructableFeatures have an optional property called .truncatedSection, which allows for one or more FractureZone pieces to be semantically linked.
Interestingly, a FractureZone's geometry is a SmallCircleArc, roughly indicating the rotation pole when the Transform that created it was active.
The 'pick' can be taken from a magnetic anomaly reading and a ship track - or it can be taken from some other gridded data source, or chosen without any justification at all.
These picks are useful to create Isochrons and align them.
As a FractureZoneIdentification can be picked from a wide variety of sources, it is recommended to use the standard gpml:subcategory property if you want to indicate where this pick comes from.
Suggested subcategories are: (1) "Bathymetry" : chosen based on a Bathymetry grid, (2) "Topography" : chosen based on a Topography grid, (3) "Gravity" : chosen based on a Gravity grid, (4) "Magnetic" : chosen based on a Magnetic grid.
While there are a few common clear-cut types of GeologicalPlane, such as a "BeddingPlane" or "CleavagePlane", field geologists may desire many other subcategories of GeologicalPlane, or subcategories of CleavagePlane etc, and this can get very subjective. Therefore, spplication of the .subcategory property (present in all gpml:Features) is advised.
Suggested subcategories are: (1) "BeddingPlane" : Surface plane indicator based on the stratum from the same rock unit, (2) "CleavagePlane" : Surface plane indicator based on the cleavage within the rock unit.
Though it is probably a good idea to keep Bathymetry and Topography seperate due to their differences, there are plenty of instances of merged data sets combining ocean depth with land height fields. This Feature supports those cases.
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
Usually measured in mGal.
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
Heat flow is typically measured by placing devices on the ocean floor to measure temperature. For example, heat will emanate from a MidOceanRidge.
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
In the Rotation hierachy, these features will depend on a Hotspot AbsoluteReferenceFrame.
HotSpots are a little unique as they don't move with the plates, but under them (if they move at all).
HotSpotTrails are used to track the paleo-movement of HotSpots. They are gpml:Features in their own right, because for the case of a HotSpot with multiple HotSpotTrail s (one disjoint trail), they can be rotated independently of each other.
Being reconstructable and also describing an inferred sequence of paleo-positions looks like it will get confusing. But presumably, geoscientists are OK with that.
For example, the InferredPaleoBoundary between India and Asia that has since been subducted under the Himalaya.
For the GPGIM1.5, we just want a simple, rigid Isochron replacement for the PLATES model. It includes Paleo-Ridge and Paleo-Transform sections.
A common property associated with an Isochron is its "age". It defines the point in time that this Isochron is believed to originate at, in Ma. However, we already have a .validTime property inherited from TimeVariantFeature, so to work out the 'age' of the Isochron, one can look at .validTime(a TimePeriod).begin(a TimeInstant).
The 'pick' is taken from the magnetic anomaly reading and the ship path.
The identifier used for magnetic picks evolved to be a combination of letters and numbers, of the form (C|M)[number][combination of letters].
For magnetic picks, an indication of precisely where on the anomaly the reading was taken is often appended, in the form (o|y)[floating-point number].
The identifier used for magnetic picks evolved to be a combination of letters and numbers, of the form (C|M)[number][combination of letters].
The first letter indicates Cenozoic or Mesozoic era, followed by a number indicating the chron's position in the sequence. However, the early measurements of isochrons were not very high resolution, and many smaller polarity reversals were missed, only to be discovered later as techniques improved. Rather than renumbering everything as new isochrons were discovered, letters from a-z were added after the number, so M14a refers to the first sub-chron located inside the 14th major chron, and if a polarity reversal were located inside that, it would be named M14aa, and so on.
This would result in names such as C34ado0.5, which translates to a Cenozoic isochron, major region 34, sub region a, sub region d, and in the case of this pick the measurement was taken half-way between the "old" and "young" edges.
For now, this allows us to define the map-view path taken by a particular ship for magnetic anomaly data. You can give it a 'ship track Id' if you want, via gml:name. The MagneticAnomalyIdentification s or 'picks' have a reference to this Feature to indicate the particular ship track that the pick originated from.
In the distant future, this Feature could also be used to record or reference the magnetic "wiggle" recorded along the ship track.
Usually measured in mT.
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
MantleDensity data can be applied to the creation of DynamicTopography grids.
The MidOceanRidge class needs to be pretty flexible. In the PLATES methodology, MOR lines are typically used to represent both the 'spreading' and 'transform' sections of the ridge - and so a lot of older data sets will have rigid MidOceanRidges once they are imported. Ideally, they would use an explicit Transform to join up MidOceanRidge and SubductionZone pieces.
The other area that MidOceanRidge needs to encompass is those ridges that have become an "Extinct Ridge" through a process of ridge propagation. This is handled via the .isActive time-dependent property below.
It is possible that later releases of the GPGIM will support a single MidOceanRidge Feature with heterogenous 'segments'.
A single Ocean Drilling Site, with single point geometry, and various measured properties at the site.
While oceanic age is most frequently represented with grids, it is still useful to pick out contours of specific ages.
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
The standard model of an orogenic belt is a linear tectonic region in a mountainous region where two plates have collided. Similar to a subduction zone, one plate has often overridden the other, so we use a similar model to that of gpml:SubductionZone. As with MidOceanRidge, the leftPlate and rightPlate properties are set to advise approximately which plate is overriding which.
While certainly OrogenicBelt can be treated similarly to SubductionZone, as there was presumably a SubductionZone that pulled the OrogenicBelt into existence (eg India and Asia), there exists potential for there to be no clearly defined overriding and overridden plate. Similar to SubductionZone, we have a .subductingSlab property which is optional.
A quite simple, linelike boundary indicating the change between continental and oceanic crust. Since this change is broad and hard to pin down, we expect two main types of continental boundary, an "Inner" ContinentalBoundary and "Outer" ContinentalBoundary. Naturally, which of these labels gets used to describe a gpml:PassiveContinentalBoundary depends largely on the source of the data, who digitized the line, and whether that aspect of the data was recorded in the original source.
Does not have to be closed, can be a simple line segment. For closed polygons, you want InstantaneousClosedContinentalBoundary and ClosedContinentalBoundary.
Due to ridge jump / propagation, and various plate-tec forces in the region, a midoceanridge-transformfault-midoceanridge area may start ignoring the extra midoceanridge and transform, and instead start 'propagating' one ridge to take over the job of the other.
The PsuedoFault is the result of the MidOceanRidge that is 'propagating' into the area previously handled by the Extinct Ridge. The contrast between the newly generated young crust and the old crust made by the Extinct Ridge causes a fault-like appearance- although it is not a true Fault.
A ReconstructableFeature may be rotated relative to another ReconstructableFeature by the action of Finite Rotations (Inside a TotalReconstructionSequence).
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
This feature is an example of one which would use gridded data almost exclusively, with little need for Contours and outlines. However, in any case of gridded data, there is the possibility that such contours may be desirable, and should be available as an option.
Includes all variations of Seamounts, such as Guyots; set the .subcategory property (defined in AbstractFeature) to "Guyot" if you're interested in the distinction.
Suggested subcategories are: "Guyot" : A special sub-category of Seamount with a flat top.
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
For example, http://www.usawaterquality.org/conferences/2005/Posters/Negrini.pdf
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
StrainMarker features are usually shown with a cross symobol, where the magnitude of each axis shows the value for a principle strain.
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
The standard model of a subduction zone is a linear tectonic region which consumes plate material on one side, while being largely 'attached' to a plate on the other side. Similarly to MidOceanRidge, the leftPlate and rightPlate properties are often set to advise approximately which plate is being consumed. The SubductionZone is always 'attached' to the overriding plate, as far as the gpml:plateIds are concerned.
Not necessarily a 'Zone', could be a linelike feature or have an additional polygon geometry. The gml property .centerLineOf is used to indicate where the subducting plate meets the overriding plate.
Plate-tectonic features that can form boundaries between plates fall under this class.
A Terrane Boundary is a regional scale miscellaneous contact between two rock units.
The rock units do not have to be clearly identified - it could simply be the boundary between a known rock unit and an unknown region, or merely the contact itself.
A Terrane Boundary is a regional scale miscellaneous contact between two rock units.
The rock units do not have to be clearly identified - it could simply be the boundary between a known rock unit and an unknown region, or merely the contact itself.
TimeVariantFeature is one of the parents to the majority of commonly used gpml:Features.
Most, but not all, features will ultimately inherit from our gpml:TimeVariantFeature in order to have the .validTime property. In contrast, features deriving from InstantaneousFeature require a TimeInstant rather than a TimePeriod, and they obtain this via the .reconstructedTime property.
Usually measured in m (height).
Currently, this feature provides for contour and outline data. This feature is intended to support gridded data in a future release.
In comparison with ReconstructableFeature and InstantaneousFeature: (1) does not have geometry of its own, (2) should be able to exist for more than an instant, so it is not really an "instantaneous" feature.
JB: A topological plate boundary doesn't need any of the reconstruction timeline stuff, since the whole key to its existence is that it borrows its geometry from other features, which will be reconstructable, and thus will have their own reconstruction timelines.
This feature represents a sequence of total reconstruction poles for the same (fixed plate Id, moving plate Id) pair which are temporally adjacent -- and thus, which may be interpolated.
Quoting JB: "How can a snapshot be captured of a feature which is an ephemoral result of an interpolation? Should this snapshot instead refer to the two features between which the interpolation occurred? What if a new feature is added "between" these two features, meaning that the two features are no longer temporally adjacent and hence no longer valid for interpolation? Does this then imply we need to capture a snapshot of the *whole feature collection*, which itself will change whenever any another unrelated feature is added or removed?"
Used to link MidOceanRidge s and SubductionZone s together to form a closed plate boundary.
This may not see as much use as MidOceanRidge; the current methodology employed in PLATES data files typically ignores Transforms altogether, and uses 'MOR' lines for both the spreading ridge and the transform 'kink's. In addition, the parts of simple PLATES-style Isochron lines that are perpendicular to the ridge can also be considered 'transforms' or 'fracture zones', because they indicate the paleo-offset between two ridge sections.
As the transition between continental crust and oceanic crust is such a large-scale transition, there will always be a "grey area" where crust cannot be clearly identified as either oceanic or continental.
An Unconformity is a type of AbstractGeologicalContact. As such, it inherits GeologicalContact's properties '.leftUnit' and '.rightUnit', which allow you to specify what AbstractRockUnits are separated by this Unconformity.
An Unconformity is not the same as a Fault. In addition, Unconformities typically have their most interesting detail in cross-section views, such as different layers of sediment - it is never a regional scale contact.
Any gml:LineStrings associated with this Unconformity will have to be restricted to a map-view for the time being.
Unlike Unconformity and Fault, which deal with fine-grained map views, UnknownContact is for regional scale map views which don't necessarily correspond to physical Faults and Unconformities. It can be used where the reason for the contact is unknown or not specified.
Single Active Volcano with point geometry. Might be referenced from other igneous Features, e.g. HotSpotTrail or IslandArc.
metadata for feature collection