[[TOC]] = CRS GML definition candidates for SECORE = === Preface === The opportunity to create arbitrary n-dimensional collections with `rasdaman` raises the need to properly address the referencing of, say, ''unconventional'' situations which can easily go beyond the simple pure spatial 1D to 3D coverages. Whereas the latter ones can still be correctly referenced with existing Coordinate Reference Systems (CRSs) -- usually by means of EPSG registered definitions (if we remain on Earth) -- there are some other cases which call for definitions to be designed: it is for example the case of pure pixel-space indexing of images of whatever the dimensionality (what is usually known as `CRS:1` space by the `rasdaman` community), or else the case of CRS composition (or compounding) which can take place e.g. when a pressure vertical axis gives volume to a 2D image, or when time shapes a group of spatial datasets into a series. In line with the URL-oriented concept of CRS handling, where all the referencing metadata of a collection is moved to a separate web resolver in the form of a GML definition, this page proposes GML definitions and associated URI labeling needed to address this gap. ---- == __Image1D__ == '''`/def/crs/OGC/0.1/Image1D`'''[[BR]] ''E.g. for time dimension until GML issues are solved.'' NOTE: showing optional components as . {{{ #!text/xml urn:ogc:def:crs:OGC:0.1:Image1D CRS for 1D pixel-domain referenced axes. Default CRS for 1D axis that are referenced in the pixel domain. urn:ogc:def:cs:OGC:0.1:Cartesian1D urn:ogc:def:axis:OGC:0.1:i i i positive urn:ogc:def:datum:OGC:0.1:ImageDatumCellLowerBound A 1D image datum with the origin at the lower bound of the first cell in the axis. urn:ogc:def:pixelInCell:OGC:0.1:cellLowerBound }}} ---- == __Image2D__ == '''`/def/crs/OGC/0.1/Image2D`'''[[BR]] ''E.g. for 2D rasters with no geo-reference.'' {{{ #!text/xml urn:ogc:def:crs:OGC:0.1:Image2D CRS for 2D pixel-domain referenced images. Default CRS for 2D images that are referenced in the pixel domain. urn:ogc:def:cs:OGC:0.1:Cartesian2D urn:ogc:def:axis:OGC:0.1:i i i horizontal urn:ogc:def:axis:OGC:0.1:j j j vertical urn:ogc:def:datum:OGC:0.1:ImageDatumGridUpperLeft A 2D image datum with the origin in the upper-left corner pixel of the grid. urn:ogc:def:pixelInCell:OGC:0.1:cellLowerBound }}} ---- == __Image3D__ == '''`/def/crs/OGC/0.1/Image3D`'''[[BR]] ''E.g. for 3D rasters with no geo-reference (CTs?).'' {{{ #!text/xml urn:ogc:def:crs:OGC:0.1:Image3D CRS for 3D pixel-domain referenced images. Default CRS for 3D images that are referenced in the pixel domain. urn:ogc:def:cs:OGC:0.1:Cartesian3D urn:ogc:def:axis:OGC:0.1:i i i base-horizontal urn:ogc:def:axis:OGC:0.1:j j j base-vertical urn:ogc:def:axis:OGC:0.1:k h h vertical urn:ogc:def:datum:OGC:0.1:ImageDatumCubeUpperLeft A 3D image datum with the origin in the upper-left corner pixel of the gridded cube base. urn:ogc:def:pixelInCell:OGC:0.1:cellLowerBound }}} ---- == __Cartesian?D__ == '''`/def/crs/OGC/0.1/Cartesian1D`'''[[BR]] '''`/def/crs/OGC/0.1/Cartesian2D`'''[[BR]] ...[[BR]] ''E.g. when elevation on a 3D dataset is based upon pressure: CCRS = (CRS2D + Cartesian1D). Otherwise when an arbitrary custom reference is needed.'' Ideas: * For single axis CRS: `EngineeringCRS` with `linearCS`, which is defined as "a one-dimensional coordinate system that consists of the points that lie on the single axis described; the associated coordinate is the distance – with or without offset – __from the specified datum__ to the point along the axis". * For 2 or 3 axes CRS: `EngineeringCRS` with `CartesianCS`, which is a 1-, 2-, or 3-dimensional coordinate system (in the 1-dimensional case, it contains a single straight coordinate axis; in the 2- and 3-dimensional cases gives the position of points relative to orthogonal straight axes; in the multi-dimensional case, all axes shall have the same length unit of measure) or `UserDefinedCS`, which is "a two- or three-dimensional coordinate system that consists of any combination of coordinate axes not covered by any other coordinate system type." The datum used must be an `EngineeringDatum`, which simply defines the origin (namely the `gml:anchorDefinition`) of the coordinate reference system. the anchorDefinition is defined as a description, possibly including coordinates, of the definition used to anchor the datum to the Earth. Also known as the "origin", especially for engineering and image datums. The codeSpace attribute may be used to reference a source of more detailed on this point or surface, or on a set of such descriptions. 1. For a geodetic datum, this point is also known as the fundamental point, which is traditionally the point where the relationship between geoid and ellipsoid is defined. In some cases, the "fundamental point" may consist of a number of points. In those cases, the parameters defining the geoid/ellipsoid relationship have been averaged for these points, and the averages adopted as the datum definition. 1. For an engineering datum, the anchor definition may be a physical point, or it may be a point with defined coordinates in another CRS.may 1. For an image datum, the anchor definition is usually either the centre of the image or the corner of the image. 1. For a temporal datum, this attribute is not defined. Instead of the anchor definition, a temporal datum carries a separate time origin of type !DateTime. Example of `EngineeringCRS` : http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:crs:EPSG::5801 which uses the `engineeringDatum`: http://www.epsg-registry.org/export.htm?gml=urn:ogc:def:datum:EPSG::9301 The preferred approach might be to define personal GML definitions with defined custom codes (e.g. `MyCartesian1D` or `PressureWGS84`), instead of defining a single template to be customised via key/value pairs. It is straightforward and less prone to problems and errors. ---- == __TemporalCRSs__ == '''`/def/crs/OGC/0.1/ANSI-Date`'''[[BR]] '''`/def/crs/OGC/0.1/2000-mins`'''[[BR]] ''CRSs for temporal axes mapping. They could be created for standard measurements of time/date (e.g. Julian day, ANSI date), or for custom ad-hoc ones (e.g. the minutes' count from the beginning of 2000).'' === Template === {{{ #!text/xml ogc:def:crs:(AUTH):(VERSION):(CODE) string ... (TimePosition) (TimePosition) string ogc:def:cs:(AUTH):(VERSION):(CODE) ogc:def:axis:(AUTH):(VERSION):(CODE) (abbreviation) (direction) (minValue) (maxValue) ogc:def:datum:(AUTH):(VERSION):(CODE) string (origin timestamp) }}} === Example: ANSI date === {{{ #!text/xml Continuous count of days starting from Jan 1, 1601 (00h00). Equal to floor(JulianDate-2305812.5) urn:ogc:def:crs:OGC:0.1:ANSI-Date ANSI date number (origin of COBOL integers dates) Bottleneck in this case is date/time ranges accepted by current Java library (Date4j) 0001-01-01 9999-12-31 urn:ogc:def:cs:OGC:0.1:days urn:ogc:def:axis:OGC:0.1:days t future urn:ogc:def:datum:OGC:0.1:ANSI-Date 1601-01-01 }}} === Example: Minutes from 2000 === {{{ #!text/xml Continuous count of minutes starting from Jan 1, 2000 (00h00) urn:ogc:def:crs:OGC:0.1:2000-mins Minutes from 2000 Bottleneck in this case is time ranges accepted by current Java library Date4j (+- 0..9999) [need to find new library or manually understand e.g. how many years/days/hours/minutes are NNNNN minutes 1999-12-25T01:21 2000-01-07T22:39 urn:ogc:def:cs:OGC:0.1:minutes urn:ogc:def:axis:OGC:0.1:minutes t future urn:ogc:def:datum:OGC:0.1:2000 2000-01-01T00:00 }}} NOTE: do not set "http://www.opengis.net/gml/3.2" as the XML namespace for GML, since SECORE does won't accept the definition, but silently (#233). ---- == Referenced definitions: == * http://rasdaman.org:8080/def/pixelInCell/OGC/1.0/cellLowerBound would resolve to: {{{ #!text/xml    The origin of the image coordinate system is at the lower bound of a grid cell.        urn:ogc:def:pixelInCell:OGC:0.1:cellLowerBound         }}} * http://rasdaman.org:8080/def/uom/OGC/1.0/GridSpacing would resolve to: {{{ #!text/xml pixels Spacing between adjacent pixels points, or between centers of adjacent pixels urn:ogc:def:uom:OGC:1.0:GridSpacing Pixels }}} * ... ---- == Issues == * does each datum (1D, 2D, 3D) require its own `pixelInCell` definition, or can the `cellLowerBound` be adopted for grids of any dimension? * are the so-called ''association roles'' necessary? For instance `cartesianCS` to include `CartesianCS`: SECORE output directly puts a `CartesianCS`, but is this valid GML? * ... ---- === External links: === * Image CRSs * [http://www.schemacentral.com/sc/niem21/e-gml32_ImageCRS.html gml:ImageCRS] * [http://www.schemacentral.com/sc/niem21/e-gml32_CartesianCS-b.html gml:CartesianCS] * [http://www.schemacentral.com/sc/niem21/e-gml32_CoordinateSystemAxis.html gml:CoordinateSystemAxis] * [http://xml.fmi.fi/namespace/meteorology/conceptual-model/meteorological-objects/2009/09/07/docindex268.html gml:ImageCRS alt] * [http://grepcode.com/file/repo1.maven.org/maven2/org.jvnet.ogc/schemas/1.0.0/gml/3.1.1/profiles/GridCRSs/1.0.0/Examples/templateImageCRS.xml ImageCRS example] * [http://www.opengis.net/def/uom/OGC/1.0/GridSpacing.gml GridSpacing UoM example] * [http://www.schemacentral.com/sc/niem21/e-gml32_ImageDatum-b.html gml:ImageDatum] * [http://www.opengis.net/def/pixelInCell/OGC/1.0/cellCenter.gml gml:pixelInCell example] * Cartesian CRSs * [http://www.schemacentral.com/sc/niem21/e-gml32_userDefinedCS-a.html userDefinedCS] * [http://www.schemacentral.com/sc/niem21/e-gml32_EngineeringCRS.html EngineeringCRS] * [http://www.schemacentral.com/sc/niem21/e-gml32_linearCS-a.html linearCS] * [http://www.schemacentral.com/sc/niem21/e-gml32_EngineeringDatum-b.html engineeringDatum] * Temporal CRSs * [http://www.schemacentral.com/sc/niem21/e-gml32_TemporalCRS.html TemporalCRS] * [http://www.schemacentral.com/sc/niem21/t-gml32_TimePositionType.html TimePositionType] * [http://im.eurocontrol.int/wiki/index.php/ISO_19108,_Geographic_information_%E2%80%94_Temporal_schema ISO:19108] * [http://www.w3.org/TR/2001/REC-xmlschema-2-20010502/#isoformats ISO:8601 Date and Time Formats (XML Schema Part 2)] ----