| 41 | | This architecture does not require a full implementation of the entire hierarchy. Only two data types are required: <code>CV_GeometryValuePair</code> and <code>CV_GridPointValuePair</code>. The names of the implementing data types are unimportant, they must simply occupy the roles in the above diagram. Rigid adherence to the UML diagram would require that a <code>CV_DomainObject</code> be explicitly represented. This architecture specification allows the direct substitution of a geometry object for the cases where a temporal component is not part of the domain. If the domain is to include temporal information, however, a domain object with both a spatial and temporal component must be defined. |
| 42 | | |
| 43 | | The "value" field of the <code>CV_GeometryValuePair</code> must be constrained to be a list of numeric types (each member of the list may have different types). Alternatively, a data structure type, such as "<code>struct</code>" in C, may be used, provided that all the fields are numeric. When applied to a raster, the "value" field represents the information in all the raster's bands (or a subset thereof), in order. |
| | 41 | This architecture does not require a full implementation of the entire hierarchy. Only two data types are required: `CV_GeometryValuePair` and `CV_GridPointValuePair`. The names of the implementing data types are unimportant, they must simply occupy the roles in the above diagram. Rigid adherence to the UML diagram would require that a `CV_DomainObject` be explicitly represented. This architecture specification allows the direct substitution of a geometry object for the cases where a temporal component is not part of the domain. If the domain is to include temporal information, however, a domain object with both a spatial and temporal component must be defined. |
| | 42 | |
| | 43 | The "value" field of the `CV_GeometryValuePair` must be constrained to be a list of numeric types (each member of the list may have different types). Alternatively, a data structure type, such as "`struct`" in C, may be used, provided that all the fields are numeric. When applied to a raster, the "value" field represents the information in all the raster's bands (or a subset thereof), in order. |
| 51 | | A <code>CV_Grid</code> by itself consists only of the metadata necessary to define a regular grid: number of dimensions, extent along each axis, and names for the axes. This constitutes basic header metadata only. There is no geospatial information at all. The data are also absent. All instances of <code>CV_Grid</code> may be related to certain other basic structures, as shown in the figure. However, the meaning of these structures and the extent to which they are populated with information, may vary depending on the information available. |
| 52 | | |
| 53 | | Children of <code>CV_Grid</code> add functionality. Children in the "Positioning" box add georeferencing information and capabilities. Children in the "Valuation" box add the raster data itself, as well as the ability to access it. Each child in the "Positioning" box represents a ''type'' of geolocation, adding the ability to translate back and forth between grid indices and location on the ground. This is equivilent to loading a header with geotags which specify the projection type as well as supplying all the parameters necessary to calculate position. An instance of a child in the "Valuation" box understands how to access the data, whether in memory or in a file. For the purposes of this architecture specification, a '''raster''' is the union of a member in the Positioning box with a member of the Valuation box: representing a fully georeferenced grid type with full access to the gridded data (whether that data is on disk or in memory). |
| 54 | | |
| 55 | | The <code>CV_GridPoint</code>, articulated in the above figure, differs from a <code>CV_DomainObject</code> only in the ability to store the grid coordinates ''as well as the geolocation''. This is not considered critical. The associations with other pieces of information (such as <code>CV_Footprint</code> or <code>CV_GridCell</code>) need not be explicitly maintained so long as they can be calculated. This architecture specification does not require the explicit implementation of a separate <code>CV_GridPoint</code> type. In fact, a loose interpretation of ISO 19123 is encouraged in this case, particularly due to the fact that raster cells may be interpreted as points or as cell areas. It is explicitly considered permissible to construct an association between the polygon forming the outline of the grid cell and the cell's values (as a <code>CV_GeometryValuePair</code>), instead of using the prescribed <code>CV_GridPointValuePair</code>. If it is necessary to represent the gridded data using these individual associations, the spatial object should accurately reflect the point or area to which the values apply. |
| 56 | | |
| 57 | | It is rarely necessary or desirable to represent a raster as a collection of <code>CV_GeometryValuePairs</code>, however it is useful to explicitly articulate the fact that the raster is composed of these individual associations. It is also useful to explicitly acknowledge that each grid point has a footprint, and each grid cell is bounded by four grid points (again, loosely interpreting this to mean that grid points may constitute the ''center'' of four grid cells instead of the four corners of a single cell.) Calculating the footprint of an individual cell may be a useful utility to include in a software package. Internally representing the gridded data in this structure is generally not necessary because the spatial location is generally trivial to compute on the fly. |
| | 51 | A `CV_Grid` by itself consists only of the metadata necessary to define a regular grid: number of dimensions, extent along each axis, and names for the axes. This constitutes basic header metadata only. There is no geospatial information at all. The data are also absent. All instances of `CV_Grid` may be related to certain other basic structures, as shown in the figure. However, the meaning of these structures and the extent to which they are populated with information, may vary depending on the information available. |
| | 52 | |
| | 53 | Children of `CV_Grid` add functionality. Children in the "Positioning" box add georeferencing information and capabilities. Children in the "Valuation" box add the raster data itself, as well as the ability to access it. Each child in the "Positioning" box represents a ''type'' of geolocation, adding the ability to translate back and forth between grid indices and location on the ground. This is equivilent to loading a header with geotags which specify the projection type as well as supplying all the parameters necessary to calculate position. An instance of a child in the "Valuation" box understands how to access the data, whether in memory or in a file. For the purposes of this architecture specification, a '''raster''' is the union of a member in the Positioning box with a member of the Valuation box: representing a fully georeferenced grid type with full access to the gridded data (whether that data is on disk or in memory). |
| | 54 | |
| | 55 | The `CV_GridPoint`, articulated in the above figure, differs from a `CV_DomainObject` only in the ability to store the grid coordinates ''as well as the geolocation''. This is not considered critical. The associations with other pieces of information (such as `CV_Footprint` or `CV_GridCell`) need not be explicitly maintained so long as they can be calculated. This architecture specification does not require the explicit implementation of a separate `CV_GridPoint` type. In fact, a loose interpretation of ISO 19123 is encouraged in this case, particularly due to the fact that raster cells may be interpreted as points or as cell areas. It is explicitly considered permissible to construct an association between the polygon forming the outline of the grid cell and the cell's values (as a `CV_GeometryValuePair`), instead of using the prescribed `CV_GridPointValuePair`. If it is necessary to represent the gridded data using these individual associations, the spatial object should accurately reflect the point or area to which the values apply. |
| | 56 | |
| | 57 | It is rarely necessary or desirable to represent a raster as a collection of `CV_GeometryValuePairs`, however it is useful to explicitly articulate the fact that the raster is composed of these individual associations. It is also useful to explicitly acknowledge that each grid point has a footprint, and each grid cell is bounded by four grid points (again, loosely interpreting this to mean that grid points may constitute the ''center'' of four grid cells instead of the four corners of a single cell.) Calculating the footprint of an individual cell may be a useful utility to include in a software package. Internally representing the gridded data in this structure is generally not necessary because the spatial location is generally trivial to compute on the fly. |
| 65 | | Coverages add value over a simple collection of geometry-value pairs. They ensure that the collection of geometry-value pairs has a consistent value (e.g., values in the coverage have the same "type" everywhere). Three methods (<code>find</code>, <code>select</code>, and <code>list</code>) are shown on the Coverage type itself. Another method, an important method, is not shown on this diagram: <code>evaluate</code>. |
| | 65 | Coverages add value over a simple collection of geometry-value pairs. They ensure that the collection of geometry-value pairs has a consistent value (e.g., values in the coverage have the same "type" everywhere). Three methods (`find`, `select`, and `list`) are shown on the Coverage type itself. Another method, an important method, is not shown on this diagram: `evaluate`. |
| 105 | | Vectors represent combined spatial and value information with a structure, record, datatype, or class which has a geometry part and a value part. In [http://docs.codehaus.org/download/attachments/31212/ISO19123 Primer.pdf ISO 19123] this is represented as the type <code>CV_GeometryValuePair</code>. In the postgis raster extension, there is a <code>geomval</code> type. Any data structure which enforces a one-to-one relationship between a particular geometry and a particular list of values will accomplish this end. Using such a structure, there is a clear separation: the geometry conveys the spatial information and the value conveys the value information. |
| | 105 | Vectors represent combined spatial and value information with a structure, record, datatype, or class which has a geometry part and a value part. In [http://docs.codehaus.org/download/attachments/31212/ISO19123 Primer.pdf ISO 19123] this is represented as the type `CV_GeometryValuePair`. In the postgis raster extension, there is a `geomval` type. Any data structure which enforces a one-to-one relationship between a particular geometry and a particular list of values will accomplish this end. Using such a structure, there is a clear separation: the geometry conveys the spatial information and the value conveys the value information. |
| 180 | | | <code>CV_Grid</code> (mask) |
| 181 | | | <code>CV_Grid</code> (values) |
| 182 | | |} |
| 183 | | |
| 184 | | Note that the same data type (an implementation of <code>CV_Grid</code> from ISO 19123) is capable of communicating both Pure Spatial and Spatial Value information for "Raster" data. The difference is in the values of the grid cells, not in the type of the data. This reduces the number of required data types from four to three. <code>CV_Grid</code> will be referred to as raster, <code>GM_Object</code> will be referred to as "geometry", and <code>CV_GeometryValuePair</code> will be referred to as "geomval". |
| | 180 | | `CV_Grid` (mask) |
| | 181 | | `CV_Grid` (values) |
| | 182 | |} |
| | 183 | |
| | 184 | Note that the same data type (an implementation of `CV_Grid` from ISO 19123) is capable of communicating both Pure Spatial and Spatial Value information for "Raster" data. The difference is in the values of the grid cells, not in the type of the data. This reduces the number of required data types from four to three. `CV_Grid` will be referred to as raster, `GM_Object` will be referred to as "geometry", and `CV_GeometryValuePair` will be referred to as "geomval". |
