Context Navigation

Changes between Version 3 and Version 4 of PetascopeSubsets

Timestamp:: Feb 28, 2014, 11:10:24 AM (10 years ago)
Author:: Piero Campalani
Comment:: second section

Legend:

: Unmodified
: Added
: Removed
: Modified

PetascopeSubsets

-              v3
+              v4
 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].
  ''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).
 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`''.
 To 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'' [http://www.schemacentral.com/sc/niem20/e-gml_sequenceRule-1.html this] page for other available rules:
+ ''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).
+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`"''.
+To 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):
 [[Image(sequenceRules.png, center, 50%)]]
 In the imag, 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.
+In 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.
 Sticking 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.
 …
+== input and output subsetting
+..open/closed intervals (we have closed now: reply to [https://groups.google.com/d/msg/rasdaman-users/3Zaz6snbtgU/KSsEj2oIqAIJ this] post in our mailing list to discuss this topic), output subsets (expressed via gml:Envelope) fit to mimimum bounding box: reduced area until is greater than a unit = pixel size.
+In general, pixel validity is meant as half open `[min,max)`, whereas the subsets are meant as closed intervals `[a,b]`.
+Subsets with extent smaller than a pixel resolution return the pixel(s) that include(s) it.
+== Input and output subsettings
+This section will cover two different facets of the interpretation and usage of subsets: how they are formalized by ''Petascope'' and how they are adjusted.
+Trimming subsets `'lo,hi'` are mainly covered here: slices do not pose many interpretative discussions.
+A first point is whether an interval (a trim operation) should be (half) ''open'' or ''closed''. Formally speaking, this determines whether the extremes of the subset should or shouldn't be considered part of it: `(lo,hi)` is an open interval, `[lo.hi)` is a (right) open interval, and `[lo,hi]` is a closed interval.
+''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'''.
+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 los that "half-pixel" that would inevitably get lost if footprints were to be ignored.
+We also consider here ''"closed sample spaces"'', so the borders of the footprints are all part of the footprint itself: jointly with the "closed interval" WCS requirement, this means for instance that two adjacent footprints ''share'' the border and a slice of trim bound right on that border will pick both grid points.
+Clarified this, the last point is how coverage bounds are set before shipping, with respect to the input subsets. That means whether our service should return the ''request bounding box'' or the ''minimal bounding box''.
+Following the (strong) encouragement in the WCS standard itself (`NOTE` paragraph to requirement 38), ''Petascope'' will fit the input subsets to the extents of sample spaces (e.g. to the pixel areas). This means that the input bbox will usually be extended to the next footprint border. This is also a consequence of our decision to apply subsets on footprints: a value which ''lies'' inside a pixel will always select the associated grid point, even if the position of the grid point is actually outside of the subset interval.
+Please note that before version 9.0 of `rasdaman` the ''request bounding box'' is returned instead by ''Petascope''.
+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.
 == Examples