Changes between Version 2 and Version 3 of IndexCrss

Timestamp:

Feb 27, 2014, 10:29:53 AM (11 years ago)

Author:

Piero Campalani

Comment:

definition sec.

IndexCrss

@@ -7 +7 @@
 == Definition
 
-TBD
+As 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.
+
+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.
+
+[[Image(indexCRS.png, center, 70%)]]
+
+Using 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.
+
+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]).
+
+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''.
+
+The following picture clarifies what is the space of coordinates covered by a standard 2D (linear) cartesian CS, and an indexed one:
 
 [[Image(IndexVsCartesianCRS.png, center, 90%)]]
 
+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. 
 
+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.
+
+== Grid origin and offset vectors
+
+TBD
+
+[[Image(IndexAndGrids.png, center, 90%)]]
+
+== Change label of the axes
+
+TBD
+Parametrized