Changes between Version 6 and Version 7 of PetascopeSubsets


Ignore:
Timestamp:
Feb 28, 2014, 1:23:31 PM (10 years ago)
Author:
Piero Campalani
Comment:

proof read

Legend:

Unmodified
Added
Removed
Modified

  • PetascopeSubsets

    v6 v7  
    11= Subsets in Petascope =
    22
    3 In this page we will describe how subsets (trims and slices) are treated by ''Petascope''. Before this you will have to understand how the topology of a grid coverage is interpreted with regards to its origin, its bounding-box and the assumptions on the sample space. Some practical example will then be proposed.
     3In this page we will describe how subsets (trims and slices) are treated by ''Petascope''. Before this you will have to understand how the topology of a grid coverage is interpreted with regards to its origin, its bounding-box and the assumptions on the sample spaces of the points. Some practical examples will then be proposed.
    44
    55
    66== Geometric interpretation of a coverage
    77
    8 This section will focus on how the topology of a grid coverage is stored in the metadata database and how Petascope interprets it.
     8This section will focus on how the topology of a grid coverage is stored in the metadata database and how ''Petascope'' interprets it.
    99For point-clouds (multipoint coverages, in the GML realm), the subject is straightforward: each point is a 0D element (please not that bbox description of point-clouds are currently not implemented: see #571).
    1010
    11 When it comes to the so-called ''domainSet'' of a coverage (hereby also called domain, topology or geometry), the metadata database (`petascopedb`) follows pretty much the GML model for rectified grids: the grid origin and one offset vector per grid axis are enough to deduce the full ''domainSet'' of such (regular) grids. When it comes to referenceable grids, the ''domainSet'' still is kept in a compact vectorial form by adding weighting coefficients to one or more offset vectors. For more on this please refer to the [PetascopeUserGuide user guide].
    12 
    13  ''What is a grid? :: As by [http://www.opengeospatial.org/standards/gml GML standard] a grid is a ''"network composed of two or more sets of curves in which the members of each set intersect the members of the other sets in an algorithmic way"''. The intersections of the curves are represented by points: a point is 0D and is defined by a single coordinate tuple and implements ISO:19107 `GM_Point` (see D.2.3.3 and ISO 19107:2003, 6.3.11).
    14 
    15 A first question arises on where to put the grid '''origin'''. The [https://portal.opengeospatial.org/files/?artifact_id=48553 GMLCOV standard] says that the mapping from the domain to the range (feature space, payload, values) of a coverage is specified through a function, formally a `gml:coverageFunction`.  We do not currently support the configuration of such function, whereas we stick to the default mapping which is indeed assumed when no coverage function is described. From the GML standard: ''"If the `gml:coverageFunction` property is omitted for a gridded coverage (including rectified gridded coverages) the `gml:startPoint` is assumed to be the value of the `gml:low` property in the `gml:Grid` geometry, and the `gml:sequenceRule` is assumed to be linear and the `gml:axisOrder` property is assumed to be `+1 +2`"''.
     11When it comes to the so-called ''domainSet'' of a coverage (hereby also called domain, topology or geometry), the metadata database (`petascopedb`) follows pretty much the GML model for rectified grids: the grid origin and one offset vector per grid axis are enough to deduce the full ''domainSet'' of such (regular) grids. When it comes to referenceable grids, the ''domainSet'' still is kept in a compact vectorial form by adding weighting coefficients to one or more offset vectors. For more on coefficients refer to the [PetascopeUserGuide user guide].
     12
     13 ''What is a grid? :: As by [http://www.opengeospatial.org/standards/gml GML standard] a grid is a ''"network composed of two or more sets of curves in which the members of each set intersect the members of the other sets in an algorithmic way"''. The intersections of the curves are represented by points: a point is 0D and is defined by a single coordinate tuple (see ISO:19107 `GM_Point`).
     14
     15A first question arises on where to put the grid '''origin'''. The GML and [https://portal.opengeospatial.org/files/?artifact_id=48553 GMLCOV] standards say that the mapping from the domain to the range (feature space, payload, values) of a coverage is specified through a function, formally a `gml:coverageFunction`.  We do not currently support the configuration of such function, whereas we stick to the default mapping which is indeed assumed when no coverage function is described. From the GML standard: ''"If the `gml:coverageFunction` property is omitted for a gridded coverage (including rectified gridded coverages) the `gml:startPoint` is assumed to be the value of the `gml:low` property in the `gml:Grid` geometry, and the `gml:sequenceRule` is assumed to be linear and the `gml:axisOrder` property is assumed to be `+1 +2`"''.
    1616
    1717To better understand this, the following image is showing the difference between a ''linear'' sequence rule (what we adopt) and an other kind of mapping, the so-called ''boustrophedonic'' (check out [http://www.schemacentral.com/sc/niem20/e-gml_sequenceRule-1.html this] page for other available rules):
    … …  
    2020
    2121In the image, it is assumed that the first grid axis (`+1`) is the horizontal axis, while the second (`+2`) is the vertical axis; the grid starting point is the full diamond.
    22 
    2322Sticking to the linear sequence rule was the best choice for `rasdaman` since that is the same rule which `rasdaman` itself uses to print the values of cells in an collection/marray.
     23
    2424Coming back to the origin question on where to put the origin of our grid coverages, we have to make it coincide to what the starting value represents in `rasdaman`, the marray origin.
    25 
    2625As often done in GIS applications, the origin of an image is set to be its upper-left corner: this finally means that the origin of our rectified and referenceable grid coverages shall be there too in order to provide a coherent GML/GMLCOV coverage, where the domain is really mapped to the range of the coverage with the default coverage function. Note that placing the origin in the upper-left corner of an image means that the offset vector along the northing axis will point South, hence will have negative norm (in case the direction of the CRS axis points North!).
    2726
    28 When it comes to further dimensions (a third elevation axis, time, etc.), the position of the origin depends on the way data has been ingested. Taking the example of a time series, if the marray origin (which we can denote as `[0:0:__:0]`, though it is more precisely described as `[dom.lo[0]:dom.lo[1]:__:dom.lo[n]`) is the earliest moment in time, then the grid origin will be the easliest moment in the series, and the offset vector in time will point to the future (positive norm); in the other case, the origin will be the latest time in the series, and its vector will point to the past (negative norm).
     27When it comes to further dimensions (a third elevation axis, time, etc.), the position of the origin depends on the way data has been ingested. Taking the example of a time series, if the marray origin (which we can denote as `[0:0:__:0]`, though it is more precisely described as `[dom.lo[0]:dom.lo[1]:__:dom.lo[n]`) is the earliest moment in time, then the grid origin will be the earliest moment in the series too, and the offset vector in time will point to the future (positive norm); in the other case, the origin will be the latest time in the series, and its vector will point to the past (negative norm).
    2928
    3029To summarize, in ''any'' case '''the grid origin must point to the marray origin'''. This is important in order to properly implement our linear sequence rule.
    … …  
    3433
    3534In spite of this, there is no formal way to describe GML-wise the footprint of the points of a grid.
    36 While the configuration of sample spaces is still just on the wishlist (see #680), our current policy applies distinct choices separately for each grid ''axis'', in the following way:
    37 
    38    * ''regular axis'': when a grid axis as equal spacing between each of its points, then it is assumed that the sample space of the points is equal to this spacing (resolution) and that the grid points are in the middle of this interval;
    39    * ''irregular axis'': when a grid axis as an uneven spacing between its points, then there is no (currently implemented) way to either express or deduce its sample space, hence 0D points are assumed here (no footprint).
    40 
    41 Such policy translated in practice to a ''point-is-pixel-center'' interpretation of regular rectified images. The following art explains it visually:
     35While the configuration of sample spaces is still just on our wishlist (see #680), our current policy applies distinct choices separately for each grid ''axis'', in the following way:
     36
     37   * ''regular axis'': when a grid axis has equal spacing between each of its points, then it is assumed that the sample space of the points is equal to this spacing (resolution) and that the grid points are in the middle of this interval;
     38   * ''irregular axis'': when a grid axis has an uneven spacing between its points, then there is no (currently implemented) way to either express or deduce its sample space, hence 0D points are assumed here (no footprint).
     39
     40Such policy is translated in practice to a ''point-is-pixel-center'' interpretation of regular rectified images. The following art explains it visually:
    4241
    4342{{{
    … …  
    7473The left-side grid is the GML coverage model for a regular grid: it is a network of (rectilinear) curves, whose intersections determine the grid points `'+'`. The description of this model is what `petascopedb` knows about the grid.
    7574
    76 The right-hand grid is instead how ''Petascope'' inteprests the information in `petascopedb`, and hence is the coverage that is seen by the enduser. You can see that, being this a regular grid, sample spaces (pixels) are added in the preception of the coverage, causing an extension of the bbox (`gml:boundedBy`) of half-pixel on all sides. The width of the pixel is assumed to be equal to the (regular) spacing of the grid points, hence each pixel is of size `|v_0| x |v_1|`, being `|*|` the norm operator.
    77 
    78 As a final example, imagine that we take this regular 2D pattern and we build a series of such images on irregular levels of altitude:
     75The right-hand grid is instead how ''Petascope'' inteprets the information in `petascopedb`, and hence is the coverage that is seen by the enduser. You can see that, being this a regular grid, sample spaces (pixels) are added in the perception of the coverage, causing an extension of the bbox (`gml:boundedBy`) of half-pixel on all sides. The width of the pixel is assumed to be equal to the (regular) spacing of the grid points, hence each pixel is of size `|v_0| x |v_1|`, being `|*|` the norm operator.
     76
     77As a final example, imagine that we take this regular 2D pattern and we build a stack of such images on irregular levels of altitude:
    7978
    8079{{{
    … …  
    102101}}}
    103102
    104 In `petascopedb` we will need to add an other axis to the coverage topology, assigning a vector to it, `v_2` (we support `gmlrgrid:ReferenceableGridByVectors` only, hence each axis of any kind of grid will have a vector). Weighting coefficients will then determine the height of each new z-level of the cube: such heights are encoded as distance from the grid origin `'#'` normalized by the offset vector `v_2`. Please note that the vector of northings `v_1` is not visible due to perspective: the image is showing the XZ plane.
     103In `petascopedb` we will need to add an other axis to the coverage topology, assigning a vector `'v_2'` to it (we support `gmlrgrid:ReferenceableGridByVectors` only, hence each axis of any kind of grid will have a vector). Weighting coefficients will then determine the height of each new z-level of the cube: such heights are encoded as distance from the grid origin `'#'` normalized by the offset vector `v_2`. Please note that the vector of northings `v_1` is not visible due to the 2D perspective: the image is showing the XZ plane.
    105104
    106105Regarding the sample spaces, while ''Petascope'' will still assume the points are pixels on the XY plane (eastings/northings), it will instead assume 0D footprint ''along'' Z, that is along height: this means that the extent of the cube along height will exactly fit to the lowest and highest layers, and that input Z slices will have to select the exact value of an existing layer.
    107106
    108 The latter wouls not hold on regular axes: this is because input subsets are targeting the sample spaces, and not just the grid points, but this is covered more deeply in the following section.
     107The latter would not hold on regular axes: this is because input subsets are targeting the sample spaces, and not just the grid points, but this is covered more deeply in the following section.
    109108
    110109
    … …  
    118117''Requirement 38'' of the [http://portal.opengeospatial.org/files/?artifact_id=48428 WCS Core] standard (OGC 09-110r4) specifies that a /subset/ is a '''closed interval'''.
    119118
    120 A subsequent question is whether to apply the subsets on the coverage ''points'' or on their ''footprints''? While the WCS standard does not provide recommendations, we decided consider the sample spaces, being it a much more intuitive behavior for users who might ignore the internal representation of an image and does not want to lose that "half-pixel" that would inevitably get lost if footprints were to be ignored.
     119A subsequent question is whether to apply the subsets on the coverage ''points'' or on their ''footprints''. While the WCS standard does not provide recommendations, we decided to target the sample spaces, being it a much more intuitive behavior for users who might ignore the internal representation of an image and do not want to lose that "half-pixel" that would inevitably get lost if footprints were to be ignored.
    121120
    122121We also consider here ''"right-open sample spaces"'', so the borders of the footprints are not all part of the footprint itself: this means that two adjacent footprints will not ''share'' the border, which will instead belong to the greater point (so typically on the right side in the CRS space). A slice exactly on that border will then pick the right-hand "greater" point only . Border-points instead always include the external borders of the footprint: slices right on the native BBOX of the whole coverage will pick the border points and will not return an exception.
    … …  
    128127Please note that before version 9.0 of `rasdaman` the ''request bounding box'' is returned instead by ''Petascope''.
    129128
    130 Practical examples will now follow. For open discussions on such policies for ''Petascope'' you are suggested to reply to [https://groups.google.com/d/msg/rasdaman-users/3Zaz6snbtgU/KSsEj2oIqAIJ this] post in our mailing list.
     129Practical examples will now follow. For open discussions on the policies we adopted, you are suggested to reply to [https://groups.google.com/d/msg/rasdaman-users/3Zaz6snbtgU/KSsEj2oIqAIJ this] post in our mailing list.
    131130
    132131
    … …  
    135134In this section we will examine the intepretation of subsets by ''Petascope'' by taking different subsets on a single dimension of 2D coverage. To appreciate the effect of sample spaces, we will first assume regular spacing on the axis, and then irregular 0D-footprints.
    136135
    137 Coverage information:
     136Test coverage information:
    138137
    139138{{{
    … …  
    189188}}}
    190189
    191 Applying these subsets to `mean_summer_airtemp` will have produce the following responses:
     190Applying these subsets to `mean_summer_airtemp` will produce the following responses:
    192191
    193192{{{
    … …  
    207206  KEY
    208207       o = grid point
     208
    209209   [=s=] = subset
    210210       [ = subset.lo
    … …  
    231231}}}
    232232
    233 Applying these subsets to `mean_summer_airtemp` will have produce the following responses (please note tickets #<bbox>, and #<slices>):
     233Applying these subsets to `mean_summer_airtemp` will produce the following responses (please note tickets #<bbox>, and #<slices>):
    234234
    235235{{{