"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"

Mapped Features


Related pages


For many features the archival source of their description is a map available at a specified scale. Furthermore, the "same" feature - i.e. a feature sharing the same name and believed to represent the same conceptual object - may be depicted on several maps often at different scales. Finally, the shape of many 3-D geology features is typically interpreted from its intersection with one or more approximately planar surfaces, such as maps and sections, which may themselves be natural or interpreted.

The Mapped Feature Types described in this schema support one or more descriptions of the primary shape, and zero or more shapes of a lower dimension, describing the intersection of the geometry with a specified surface.

Schema documents

A set of feature types to describe features found on maps are defined in the document:

Example Instances

Model and Document Structure

Mapped Position Feature




The content model of xmml:MappedPositionFeature extends xmml:PositionFeatureType (see GeometryBasedFeatures) with
  • additional position properties: these support recording the position at a variety of scales or precisions. Note that the map scale for each gml:Point, or other details of the data source, may be recorded in the gml:metaDataProperty for the Point.

Mapped Curve Feature




The content model of xmml:MappedCurveFeature extends xmml:CurveFeatureType (see GeometryBasedFeatures) with
  • additional shape properties: these support recording the position at a variety of scales or precisions. Note that the map scale for each gml:_Curve may be recorded in the gml:metaDataProperty for the Point
  • a set of piercingPoint properties, each containing a xmml:PointsInSurface object, which contains a MultiPoint representing the points of intersection of the curve and a containingSurface.

Mapped Surface Feature




The content model of xmml:MappedSurfaceFeature extends xmml:SurfaceFeatureType (see GeometryBasedFeatures) with
  • additional shape properties: these support recording the position at a variety of scales or precisions. Note that the map scale for each gml:_Surface may be recorded in the gml:metaDataProperty for the Point
  • a set of trace properties, each containing a xmml:CurvesInSurface object, which contains a MultiCurve representing the curves of intersection of the surface and a containingSurface.

Mapped Solid Feature




The content model of xmml:MappedSolidFeature extends xmml:SolidFeatureType (see GeometryBasedFeatures) with
  • additional shape properties: these support recording the position at a variety of scales or precisions. Note that the map scale for each gml:_Solid may be recorded in the gml:metaDataProperty for the Point
  • a set of trace properties, each containing a xmml:SurfacesInSurface object, which contains a CompositeSurface representing patches where the solid intersects a containingSurface.


Do the #Objects_intersecting_surfaces models cope with cases such as the following? A curve may intersect a surface at a number of points but may also lie completely with in a surface for some or all of its length. A surface might be coincident with another surface in part as well as just intersecting along some curve. -- MarcusSen - 05 Apr 2004

I guess the segment where the curve lies within the surface will be captured within the shape property of a MappedCurveFeature, while the piercing points are described separately. The proposition in this model is that it is valid and useful to distinguish between the actual shape of a feature with its correct dimensionality, and its sampled shape with a reduced dimensionality. -- SimonCox - 06 Apr 2004

First I think we need to distinguish between objects intersecting and going through surfaces, and objects being bounded by surfaces. Geological maps tend to show, for example, where particular units are bounded by the ground surface. Cross-sections or seismic sections show where units cross the section surface. A pit wall or similar shows part of the boundary of a unit on the local scale, although on a more regional scale we might want to ignore the fact that the unit has actually been cut into and just regard the pit as showing us a sample of the inside of the unit.

Next we need to be clear what information we are trying to convey by noting the intersection or bounding of some object by some surface.

Consider a solid geological unit body. Various observations like exposed rock or certain landform features may be used by a mapping geologist to help them to draw a polygon on a map where they think that body coincides with the ground surface or bedrock surface. Although some of the observations that went into constructing the polygon may have been located in 3D, generally the polygon will just be located in 2D horizontal coordinates. This map information could be used later in the construction of a more complete geometry of the solid geological body. If the 3D geometry of the ground surface is obtained from another source, then the 2D mapped polygon can be projected onto this surface and used to "cookie-cut" a piece of the surface which forms a piece of the bounding surface of the solid body. The information conveyed by the mapped polygon is the shape of the polygon in 2D horizontal coordinates. The xmml:MappedSolidFeature above has trace properties which are the surfaces of intersection of the solid with a given surface. Geometrically these are surfaces but the ups and downs of the inside parts of these surfaces are not part of the information that is being conveyed by the conventional coloured polygon on a map so I don't think this is an appropriate model for geological map polygons. If we go on to the next stage where we have cut out the bits of ground surface which form part of the solid body's boundary then we have pieces of the geometry of the body which could be represented in the traces property in this model. In that case a reference to the ground surface or whatever that was used to construct these pieces of the solid body's bounding surface might be useful but I doubt that we would also want to store its geometry in the containingSurface property.

In the case of the body intersecting a seismic section or such the fact that the inside of the surface of intersection is somewhere inside the solid body is minimally informative, the main information is that the bounding curve lies within the bounding surface of the solid body.

There are many more combinations of different dimensioned objects intersecting other objects that need enumerating here. Do the GML topology components cover these comprehensively or do we need to enumerate them explicitly here? SloppyTopology is apparently something different.

-- MarcusSen (following some email discussion with BruceSimons) - 29 Apr 2004

One thing about MappedFeatures discussion that perked my interest is the "construction of a more complete geometry of the solid geological body" via the 2D map representations being linked directly to 3D surface intersections. I would not expect this to be the case since a map geometry is usually a projection of some sort, sometimes simply that of a geologist sketching on a 2D page, and is a representation (or one view) of the underlying reality. As such I would not expect the map representation to actually line up exactly with the 3D surface intersections. This is similar to drawing a dot to represent a city rather than drawing all the houses and streets. Whilst there is a psuedo-topological relationship it probably isn't strong enough to allow the "cookie cutter" approach.

I don't believe it is the intent of MappedFeatures to do this exact intersection representation. It is intended to relate different representations of the same feature - _"a feature sharing the same name and believed to represent the same conceptual object - may be depicted on several maps often at different scales_".

If you are looking at "construction of a more complete geometry of the solid geological body" then that should be handled by a different mechanism. The GML topology components are insufficient since they are to fine grained for the "cookie cutting" approach suggested (what I refer to as micro-topology, the relationship between the underlying geometric compenents that make up the feature). What is required is more of a macro-topology between features which is the approach used in SloppyTopology. In this case you can specify that the bounds of some rock structure (a feature) are butted up against a pit wall (another feature) and then as the pit wall changes over time the bounds of the rock unit would change (more correctly could be changed with some computational geometry kicking in). This case is a parameterised geometry that requires computational geometry and a bunch of rules (eg. the pit is "newer" than the rock so when intersecting "take away the rock") to create the final geometry.

The schema and ideas associated with SloppyTopology might be tweaked into something useful for this situation though at this stage I don't know of any applications that could utilise the information, especially in 3D (though I would love to build one!).

-- RobertWoodcock - 30 Apr 2004

I'm not sure what is meant by exact but the 2D polygons drawn on our geological maps are created by the mapping geologist so that, if projected vertically from their 2D plane onto the relevant "surface of crop" they will work in the "cookie-cutting" way I have described above. There are various issues governing the accuracy of this and exactly what surface of crop they are being mapped onto (e.g. top 1-2m of soil are commonly ignored) but, to the accuracy of the mapping, they should be usable as a starting point for construction of part of the 3D shape of a unit in the way I described. The 3D shape so constructed would, of course, have limitations in accuracy resulting from the accuracy of the geologist's map polygons, but that doesn't affect the principle. That is the kind of feature being represented by the BGS GeologyExtent described in StructuralGeology. The mapped features created by SimonCox on this page are slightly different in that the intersections are recorded in 3D coordinates (with the projection and cookie-cutting already done). I'm not sure when data in this format would be exchanged but that is a separate question.

This would all have to be part of a semi-manual process of 3D model construction where a geologist using some kind of 3D geological CAD system would use this information as part of the input for construction of a of a unit's 3D geometry. I wonder if we are talking at cross-purposes because Robert is thinking of what would be necessary for an automated system to construct a complete 3D model?

I don't understand what the "micro-topology" and "macro-topology" terms mean?

-- MarcusSen - 04 May 2004

The surface-patch within a surface that is mapped-extent of a "solid" can be thought of in two ways, depending on whether the surface on which you are mapping is to be considered as "geologically significant" or not.
  1. The sampling surface is not significant in the case of "manufactured" cross-sections. But for some purposes even the nominally horizontal surface corresponding to a conventional map may not be of interest with respect to a solid-feature of interest, where we are interested in the shape independent of the current erosional surface. In this case, the surface-in-surface is merely a 2-D sampling of the solid, to be used as input to reconstructing the solid.
  2. If the surface on which the surface-patch is observed is actually part of the bounding surface of the solid of interest, then it is merely a component of the complete solid boundary.

-- SimonCox - 01 May 2004

Should it not be possible in the encoding to specify which case is intented? I understand that people with different end-purposes might wish to treat the same geometric data (e.g. the intersection with an erosion surface) differently, but, within a context where people are exchanging information intended to be used for the same purposes (e.g. constructing the current 3D geometry of some units) there will be the need to distinguish between data which provides bits of the bounding surface of the unit and that (e.g. a seismic section) which cuts through the middle of a unit.

-- MarcusSen - 04 May 2004

The geology polygons drawn on 2D (flat) geological maps represent an intersection between the 3D geological body and a 3D surface, usually topography. On the map, this intersecting surface is represented separately, usually as contours, and it is up to the user to interpret the 3D body shape from the two sets of information, such as dipping bodies 'Veeing' upstream. Ideally we would like to provide the x,y,z values for the polygons (fully describe the Vee), rather than x,y for polygons and x,y,z for the intersecting surface. However, the data probably doesn't allow this given that we usually only have the 2D-polygon information. The question then becomes whether it is worthwhile providing the name of the intersecting surface, eg "Topography". As there are almost limitless numbers of intersecting surfaces that could be used, and no standards for naming them, I wonder whether this is useful information or not. If so, should it be part of the metadata about the polygons, similar to authorship, rather than part of the unit geometry?

-- BruceSimons - 05 May 2004

My apologies for introducing the terms "micro-topology" and "macro-topology" without definition. I'm involved with a fair amount of 3D CAD modelling of geological models, as a developer of tools, not as a geological modeller. It became useful in that work to distinguish between the (macro)-topology connecting geological features (e.g. Rock Unit A abuts Rock Unit B or Fault A bounds Rock Unit C) from the (micro)-topology of the underlying geometric surface (all the triangles that make up the boundary of Rock Unit B). The macro-topological components are important to the geology of the situation and the micro-topology is usually a representational issue (which in the case of one of the projects could change so long as the macro-topology was honoured).

It seems to me that the above discussions on MappedFeatures have multiple use-cases being overloaded and that possibly a separation of concerns is required. The macro-micro topology idea (or something like it) might assist but there is also the need to deal with the "end-purpose". Ignoring the end purpose for a moment it appears that some geometry data is a side effect of representation. For that matter so is some of the (micro)-topology along the important macro-topological features (eg. the intersection of two surfaces is a line but if they are represented as triangulated surfaces you get a polyline and each line segment has an associated piece of the topological puzzle). Should these "side effects of representation" (implementation details) be dealt with separately from what is "really" meant? I believe so. One way I think of it is if (say) a triangulated surface representation was replaced with a curved representation (whichd require fewer surface patches) then what information would need to be preserved? -> the bounding and connective topological relationships, not the internal triangles and points.

The "end-purpose" appears to vary according to how the geometry of the feature relates to reality. In the case of the BGS GeologyExtent described in StructuralGeology the features being mapped are intended to be quite accurate enough for cookie cutting (something I misunderstood in my earlier response). Similarly for the 3D CAD style models I refered to. MappedFeatures on the other hand appears to be a scale dependent representational view that may not reflect the exact situation and is intended for a different purpose. I keep looking at the line: _"a feature sharing the same name and believed to represent the same conceptual object - may be depicted on several maps often at different scales_"; and thinking anything with multiple representations like this probably has symbolic geometry.

Looks to me like there is enough discussion on this page for a thoughful refactor and proposal that brings our collective thoughts to some sort of conclusion. Unfortunately I can't have a go at that now .

-- RobertWoodcock - 12 May 2004

Geometry sampled on surfaces

Quite strictly:

  • the intersection of a solid with various different sampling surfaces corresponds to a set of surfaces
  • the intersection of the exterior of a solid with various different sampling surfaces corresponds to a set of rings
  • if the sampling surfaces are tangential to the boundary of the solid of interest (usual for geological units outcropping at the earth's surface, but not for most constructed cross-sections), then the rings define the exteriors of surface patches that comprise parts of the exterior surface of the solid.

This is more or less standard Euclid. Similar intersection relationships apply at lower dimensionality if the object of interest is a surface or a curve.

The terminology I use here (ring, exterior, surface patch, surface, solid) follows ISO 19107 - see GeometryComponents. Probably need to clean up XMML terminology to match this.

Geometry observed at different scales

Observations of geometry may be made at various scales. It may be useful to record details for several of these geometry objects, even if they are expected to represent the "same" geometry. These may even be objects of different dimensionality - e.g. a Point for use at broad scale, Surface (polygon) at finer scales, Solid at finer scales still.

The "mappers" here need to figure out how many options it is desirable to support, then we can optimise the model and schemas.

-- SimonCox - 14 May 2004

Issues and change requests

Readers are invited to add issues to this table - select [Edit Table] below. It is not mandatory to enter a solution, but change requests are more likely to be implemented if a concrete solution is proposed.

%EDITTABLE{ header="| # | By | Timestamp | Component(s) | Description of issue | Proposed solution | Resolution |" format="| row, -1 | text, 25, Unknown | label, 0, 12 Dec 2019 06:10 | textarea, 3x25, Component(s) | textarea, 3x25, Description | textarea, 3x25, Proposal | select, 1, Unaddressed, Progressing, Resolved |" changerows="on" }%
# By Timestamp Component(s) Description of issue Proposed solution Resolution
1 My org 14 May 2004 collar location A big whinge a proposed solution Unaddressed
Topic revision: r15 - 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).