Changes between Version 7 and Version 8 of IndexCrss


Ignore:
Timestamp:
Feb 27, 2014, 3:06:36 PM (10 years ago)
Author:
Piero Campalani
Comment:

proof-read

Legend:

Unmodified
Added
Removed
Modified

  • IndexCrss

    v7 v8  
    33= Index CRSs
    44
    5 This page describes how to use and interpret Index Coordinate Reference Systems (CRSs), and how they differs from other linear coordinate systems and especially how it differs from the ''internal'' grid CRS, known as `CRS:1`.
     5This page describes how to use and interpret Index Coordinate Reference Systems (CRSs): how they differ from other linear coordinate systems and especially how they differ from the ''internal'' grid CRS, known as `CRS:1`.
    66
    77GML definitions for [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index1D Index1D], [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index2D Index2D] and [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index3D Index3D] are already embedded in our [SecoreDevGuide SECORE] resolver and their official acknowledgment is on OGC table.
    … …  
    1111As you can verify by looking at the "extra" (non-EPSG) CRS definitions [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/ provided] by SECORE, among others there are three new Index CRSs, namely [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index1D 1D], [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index2D 2D] and [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index3D 3D] reference systems.
    1212
    13 The ''index'' prefix refers to the fact that ''integral'' coordinates shall be used in the geometric (cartesian) space. The n-dimensional Coordinate System (CS) is supposed to be bound to an multidimensional array (marray) of cells: the origin of the CS is placed in the centre of the 0-cell. This represents the datum and completes the picture to define the CRS.
     13The ''index'' prefix refers to the fact that ''integral'' coordinates shall be used in the coordinates. The n-dimensional (cartesian) Coordinate System (CS) is supposed to be bound to a multidimensional array (marray) of cells: the origin of the CS is placed in the centre of the 0-cell. This represents the ''datum'', and completes the picture to define the CRS.
    1414
    1515[[Image(indexCrs.png, center, 70%)]]
    … …  
    1717Using index CRSs can be useful especially when using `rasdaman` for applications not related to the geo-referenced world of satellite products, or more generally to remote-sensing imagery. For instance, `rasdaman` could be used to process [http://link.springer.com/article/10.1134/S105466181304007X large bio-medical images], which do not need a geo-reference.
    1818
    19 The previous case is out of scope in the OGC services, and it is probably better handled via direct `rasql` requests (also via [PetascopeUserGuide Petascope] `rasql` web interface). However, more interestingly, index CRSs could also be used to access "pixel" coordinates from an image, or to access layers of height/time via their ordinal position in the stack (this requires CRS extensions [Features available]).
     19The previous case is out of scope in the OGC services, and it is probably better handled via direct `rasql` requests (also via [PetascopeUserGuide Petascope] `rasql` web interface). However, more interestingly, index CRSs could also be used to access "pixel" coordinates from a geoimage, or to access layers of height/time via their ordinal position in the stack (this requires CRS extensions [wiki:Features available]).
    2020
    21 Index CRSs exploit indexed cartesian CSs by defining the Unit of Measure (Uom) of each of its axes to be an integral. The specific terminology that is used is [http://www.opengis.net/def/uom/OGC/1.0/GridSpacing GridSpacing], defined by OGC in the context of the [http://www.opengeospatial.org/standards/deprecated deprecated] (2D) Image CRS. Indeed index CRSs are considered the n-dimensional extension/generalization of the previously defined [http://schemas.opengis.net/ImageCRSs/ Image CRSs]: this means replacing the typically-2D terminology of ''pixels'', ''rows'' and ''columns'' with the more general ''cells'' and ''axis''.
     21Index CRSs exploit indexed cartesian CSs by defining the Unit of Measure (Uom) of each of its axes to be an integral. The specific terminology that is used is [http://www.opengis.net/def/uom/OGC/1.0/GridSpacing GridSpacing], defined by OGC in the context of the [http://www.opengeospatial.org/standards/deprecated deprecated] (2D) Image CRS. Indeed index CRSs are considered the n-dimensional extension/generalization of the previously defined [http://schemas.opengis.net/ImageCRSs/ Image CRSs]: this means replacing the typically-2D terminology of ''pixels'', ''rows'' and ''columns'' with the more general ''cells'' and ''axis'' terms.
    2222
    2323The following picture clarifies what is the space of coordinates covered by a standard 2D (linear) cartesian CS, and an indexed one:
    … …  
    2525[[Image(IndexVsCartesianCRS.png, center, 90%)]]
    2626
    27 The 2D space is fully covered on a geometric space with no additional constraints, whereas limiting the coordinates to integrals confines the address space to a grid of 0D points. While this is easily understandable, it has some important consequences: '''sample sizes''' (footprints) of coverages' points are confined to be 0D on an index CRSs since the areas between CRS points is not reachable and hence loses its meaning.
     27The 2D space is fully covered on a geometric space with no additional constraints, whereas limiting the coordinates to integrals confines the address space to a grid of 0D points. While this can be easily understandable, it has some important consequences: '''sample sizes''' (footprints) of a coverage's points are confined to be 0D on an index CRSs since the areas between CRS points are not reachable by the indexed coordinates.
    2828
    29 In the regular 2D case, usually a pixel represents its extent/area (though [http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint not always] of course), while a coverage point is always a 0D point: on an index CRS the point is on integral coordinates, and the footprint would be half-pixel away from it, over unreachable spaces `0.5 GridSpacing` away from it. Truncating this footprint to the legal index space, the footprints/pixels reduce to the point itself.
     29In the regular 2D case a pixel usually represents its extent/area (though [http://trac.osgeo.org/gdal/wiki/rfc33_gtiff_pixelispoint not always] of course), while a (GML) coverage point is always a 0D point: on an index CRS the point is on integral coordinates, and the footprint would be half-pixel away from it, over unreachable spaces at `'0.5 GridSpacing'` distance. Truncating this footprint to the legal index space, the footprints/pixels reduce to the point itself.
    3030
    3131== Grid origin and offset vectors
    … …  
    4343}}}
    4444
    45 The ''internal'' `CRS:1` space needs not be confused with Index CRSs (although there are ways to make them coincide): an important premise is that `rasdaman`, along with many other [http://www.remotesensing.org/geotiff/faq.html?What%20is%20the%20purpose%20of%20GeoTIFF%20format%20for%20satellite%20data#AxisOrder common GIS policies], puts origin in the '''upper-left''' corner of an image. This means in practice that picking the first row of an image (slice `0` on the northings axis) will return the top row, and increasing ''internal'' coordinates will yield negative steps in the geo-CRS.
     45The ''internal'' `CRS:1` space needs not be confused with Index CRSs (although there are ways to make them coincide): an important premise is that `rasdaman`, in line with [http://www.remotesensing.org/geotiff/faq.html?What%20is%20the%20purpose%20of%20GeoTIFF%20format%20for%20satellite%20data#AxisOrder common GIS practice], puts the origin of a grid coverage in the '''upper-left''' corner of an image. This means in practice that picking the first row of an image (slice `0` on the northings axis) will return the top row, and increasing ''internal'' coordinates will yield negative steps in the geo-CRS.
    4646
    4747The internal representation of a grid is represented by an origin (usually in  `[0:__:0:__:0]`) and unit integral spacing. When using index CRSs, in order to correctly visualize an image, you must take care to properly set the offset vectors.
    … …  
    5151Lookig at the picture above, you can see correct and faulty ways of defining the ''external'' index representation of a grid (2D case):
    5252
    53    * '''`I quadrant (+/+)`''': origin is upperleft corner, `i`-vector is the positive `i`-versor `[1,0]` while the `j`-vector points down (`[0,-1]`) so that inverse proportionality on the second grid axis between internal and external representation is correctly maintained.
    54    * '''`II quadrant (-/+)`''': `j`-vector is set as `[0,1]` and as a consequence the origin becomes the lower-left corner of the image: as a result we will see the image upside-down.
     53   * '''`I quadrant (+/+)`''': origin is upperleft corner, `i`-vector is the positive `i`-versor `[1,0]` while the `j`-vector points down (`[0,-1]`) so that inverse proportionality between the second grid axis and the external `j` axis is correctly maintained.
     54   * '''`II quadrant (-/+)`''': `j`-vector is set as `[0,1]` and as a consequence the origin becomes the lower-left corner of the image: as a result we will see the image upside-down (WC*S viewpoint)
    5555   * '''`III quadrant (-/-)`''': origin is correctly set in the upper-left corner, but offset vectors have norm greater than one: while this is a technically viable solution, it also means that we lose the pixel-index correspondence: one internal index step equals a jump of 2 indexes in the external representation.
    5656   * '''`IV quadrant (+/-)`''': similarly, it does not make much sense to define vectors with norm less than one: moreover this solution would even prevent from slicing those point which do not lie over a legal area of the index CRS (at fractional positions).
    5757
     58Additionally, you could observe how ''oblique'' vectors (i.e. vectors with both components != 0) are not even taken into account here (I am not declaring there are no unforeseen applications that might need such a configuration though).
     59
    5860This example is aimed at underlining the difference between the `CRS:1` internal grid representation and the set of index CRSs. Albeit they are different concepts, they can also coincide in case ''i)'' the `i`/`j` coordinates of the origin equal the internal indexes of the grid (which is usually but not necessarily in `[0:0:__:0]`), ''ii)'' the offset vectors are the versors of the nD cartesian CS.
    5961
    60 For some hands-on `RasQL`/WC*S query, our [browser:systemtest/util/petascope.sh test datasets] are actively using index CRSs: `mr` and `rgb` are 2D images, whereas `irr_cube_1` is a fictitious toy 3D cube (with irregular spacing on the third `k` dimension) which purposely synchronizes its internal and external representation. See [RasdamanTestSuites this] page for more information.
     62For some hands-on `RasQL`/WC*S query, our [browser:systemtest/util/petascope.sh test datasets] are actively using index CRSs: `mr` and `rgb` are 2D un-georeferenced images, whereas `irr_cube_1` is a fictitious toy 3D cube (with irregular spacing on the third `k` dimension) which purposely synchronizes its internal and external representation. See [RasdamanTestSuites this] page for more information.
    6163
    6264
    6365== Changing axis labels
    6466
    65 A final section is dedicated to the customization of axis label when using an Index CRS. This can be useful when migrating existing application to 9.x releases. Prior versions of `rasdaman` do not support index CRSs.
     67A final section is dedicated to the customization of axis labels when using an Index CRS. This can be useful when migrating existing application to 9.x releases: prior versions of `rasdaman` do not support index CRSs and client applications usually require at least a change in the subsettings labels when migrating to 9.x.
    6668
    6769The management of CRSs metadata was usually done ''in house'', with default axis labels to `x`, `y`, `z`, `t`, and so on, independently of the native CRS assigned to a coverage. The outsourcing of CRS metadata handling to the [SecoreUserGuide SECORE] resolver (official [http://external.opengeospatial.org/twiki_public/CRSdefinitionResolver/WebHome OGC resolver] for CRS related resources) imposes less freedom on the choice of axis labels on one hand (you have to use the official abbreviations), while developing a more transparent and more ruled framework.
    6870
    69 While geodetic reference systems from [http://www.epsg-registry.org/ EPSG] are not customizable (let's say they are read-only CRSs), our index CRSs (and as well [PetascopeTimeHandling time] ones) are constructed by splitting each concept into a ''template'' and a ''parametrization'' of the template.
     71While geodetic reference systems from [http://www.epsg-registry.org/ EPSG] are not customizable (let's say they are read-only CRSs), our index CRSs (and as well [PetascopeTimeHandling time] ones) are constructed by splitting each "concept" of CRS into a '''template''' and a '''parametrization''' of the template.
    7072
    71 Indeed you can see in our resolver that every `OGC:Index`''n''`D` CRS is associated with its template `OGC:.Index`''n''`D-template`, the latter being the template and the former being its parametrization. You can notice the period `.` prefix in the templates CRS code, which (like in unix file systems) denotes an hidden resource: indeed users shall not reference the templates when setting the native CRS (URI) to a coverage, but rather always use the parametrizations. A Parametrized CRS (P-CRS) is like piggy-backed on a template: it provides one or more parameters to the enduser for customizing the content of the template ''target'' CRS definition. Parameters are set by the user by means of key-value pairs in the query of a URI.
     73Indeed you can see in our resolver that every `OGC:Index`''n''`D` CRS is associated with its template `OGC:.Index`''n''`D-template`, the latter being the template and the former being its parametrization. You can notice the period `.` prefix in the templates CRS code, which (like in unix file systems) denotes an hidden resource: indeed users shall not reference the templates when setting the native CRS (URI) to a coverage, but rather always use the parametrizations. A Parametrized CRS (P-CRS) is like piggy-backed on a template, and at the same time it hides it from external interfaces: it provides one or more parameters to the enduser for customizing the content of the template ''target'' CRS definition. Parameters are set by the user by means of key-value pairs in the query of a URI.
    7274
    73 When default values for all the parameters offered by a P-CRS, then querying the P-CRS URI without any query part (`?key=value[&key=value[&...]]`) is doable: the template resource is returned (that is, the template resource where parameters values have been set to their defaults defined in the P-CRS), and the user can blissfully ignore the (relative) complexities of parametrization.
     75When '''default''' values for all the parameters offered by a P-CRS, then querying the P-CRS URI without any query part (`?key=value[&key=value[&...]]`) is legal: the template resource is returned (that is, the template resource where parameters values have been set to their defaults defined in the P-CRS), and the user can blissfully ignore the (relative) complexities of parametrization.
    7476
    7577Our index CRSs indeed are P-CRSs with parameters to customize the labels of the axes, which by default are `i`, `j` and `k` (4+ dimensinal index CRSs are yet to be defined).
    76 This was also due to the necessity to avoid label clashes when 2+ index CRSs of the same kind are used within the same coverage.
     78This was also due to the necessity to avoid label clashes when 2+ index CRSs of the same kind have to be used within the same coverage.
    7779
    78 If a P-CRS is requested with no subelement expansion (see #364), then the behind-the-scenes definition of a P-CRS can be visualized.
    79 For instance, our `OGC:Index1D` CRS is:
     80If a P-CRS is requested with no subelement expansion (`expand=none`, but see #364), then the behind-the-scenes definition of a P-CRS can be visualized.
     81For instance, our `OGC:Index2D` CRS is:
    8082
    8183{{{
    … …  
    102104}}}
    103105
    104 The content is sufficiently intuitive to understand that it provides two parameters -- `'first-axis-label'` and `'second-axis-label'` -- with defaults to `'i'` and `'j'`, respectively.
    105 Thus if we want to use index CRSs but with the ''good old'' `x`/`y` labels, we need to set this URI as native reference system: [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index2D?first-axis-label=%22x%22&second-axis-label=%22y%22 http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index2D?first-axis-label="x"&second-axis-label="y"].
     106The content is sufficiently intuitive to understand that it provides two parameters -- `'first-axis-label'` and `'second-axis-label'` with defaults to `'i'` and `'j'`, respectively -- to change `gml:axisAbbrev` abbreviation of the first and second CRS axis.
     107Thus if we want to use index CRSs but with the ''good old'' `x`/`y` labels, we need to set the following URI as native reference system: [http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index2D?first-axis-label=%22x%22&second-axis-label=%22y%22 http://kahlua.eecs.jacobs-university.de:8080/def/crs/OGC/0/Index2D?first-axis-label="x"&second-axis-label="y"].