| 27 | | '''ST_AsRaster(geometry, pixelsize) -> raster'''[[BR]] |
| | 27 | '''ST_AsRaster(geometry, pixelsize) -> raster''' |
| | 28 | |
| | 29 | * Rasterize the provided geometry to the specified raster. |
| | 30 | * Implemented as a wrapper around GDAL like DumpAsPolygons does. |
| | 31 | * ST_AsRaster is necessary to implement ST_Intersection(geometry, raster, band) -> raster and ST_ToRaster() where the provided geometry is first rasterized to the same alignment as the other raster involved. |
| | 32 | * Each geometry of a table is rasterized as one raster. To produce a global unique raster including all the geometries of a table (loosing overlaps by the way), a user must use the planned ST_Union aggregate function to merge all the rasters together optionally in a GROUP BY query grouping some rows together. |
| | 33 | |
| | 34 | * The raster is burned with the specified value converted (or truncated with a warning) to the provided pixeltype. The hasnodatavalue flag is set and the nodatavalue is set to the provided value (expect in variant 10 and 12). |
| | 35 | |
| | 36 | * Alignment, width, height and pixelsize are computed:[[BR]] |
| | 37 | -From the extent of the geometry[[BR]] |
| | 38 | -Imposed[[BR]] |
| | 39 | -From another raster |
| | 40 | |
| | 41 | * Alignment can be optionally specified as:[[BR]] |
| | 42 | -A x and a y world coordinates specifying an arbitrary pixel corner. Although it can be, it IS NOT necessarily the coordinates of the upper left corner pixel.[[BR]] |
| | 43 | -A ulx and a uly world coordinates specifying the upperleft corner of the raster. This IS NECESSARILY the upper left corner of the upperleft pixel. In this case a width and a height must also be provided.[[BR]] |
| | 44 | -An existing raster. The x and y are derived from the provided raster and the resulting raster has the same size as the provided raster.[[BR]] |
| | 45 | -Default is the upper left corner of the envelope of the geometry. This might result in table where all rasters are misaligned, but this is useful when reconverting to raster a set of polygons vectorized from rasters (with ST_DumpAsPolygon() or ST_Intersection()). |
| | 46 | |
| | 47 | * Pixelsize can be optionally specified as:[[BR]] |
| | 48 | -One or two floating point numbers. If only one is provided, both x and y pixel sizes are assigned the same value.[[BR]] |
| | 49 | -A width and a height (integers). In this case the x pixelsize is the x extent divided by the provided width and the y pixelsize is the y extent divided by the provided height. This is usefull only when the alignment is specified as the upper left corner of the raster.[[BR]] |
| | 50 | -“FIRST_SEGMENT_LENGTH”. The pixelsize is set to the length of the first line segment encountered in the geometry. This is practical when reconverting to raster polygons vectorized from rasters (with ST_DumpAsPolygon or ST_Intersection). In this case, all segments are of the same length which is the original raster pixel size. This is useful only when alignment is not specified. If the geometry is a point, return an error.[[BR]] |
| | 51 | -Default is the smallest of the width or height of the extent of the source geometry divided by 250. If the smallest of the width or height of the extent of the source geometry is zero then a warning is reported an no NULL is returned. |
| | 52 | |
| | 53 | '''Variants''' |
| | 54 | |
| | 55 | * There are many variant because we are creating a raster from scratch and we want to make it easy (serie one and four) and at the same time be flexible on the control of the raster properties (series two, three) |
| | 56 | * Variant 3, 5 and 13 are the most useful. |
| | 57 | * Variant 6, 7, 8, 9, 10, 11, 12 are also useful. |
| | 58 | * Variant 1, 2, 4 are for useful for table containing only one raster. |
| | 59 | * All variant should be pl/pgsql variant on variant 9 which is the only which need to be implemented as a rt_pg functions.. |
| | 60 | |
| | 61 | * The '''first series of variant''' get their alignment from the extent of the geometry. |
| | 62 | |
| | 63 | 1) ST_AsRaster(geometry, pixeltype, val, nodataval) – 0, alignment is computed from the geometry envelope, pixel size is computed by dividing the extent by 250. This variant is optional and discouraged as it results in many unaligned rasters for a table with many geometries. |
| | 64 | |
| | 65 | 2) ST_AsRaster(geometry, pixeltype, val, nodataval, pixelsize float8) – 1, x and y are computed from upper left corner it the geometry envelope. This variant is optional and discouraged as it results in many unaligned rasters for a table with many geometries. |
| | 66 | |
| | 67 | 3) ST_AsRaster(geometry, pixeltype, val, nodataval, ‘FIRST_SEGMENT_LENGTH’) – 0, ulx and uly are get from the envelope, pixel size from the length of the first segment. This variant is useful only to rasterize geometries produced by ST_DumpAsPolygon or ST_Intersection. Otherwise it discouraged as it would result in many unaligned rasters for a table with many geometries. |
| | 68 | |
| | 69 | * The '''second series of variant''' have their alignment specified by an arbitrary pixel corner of the desired raster. |
| | 70 | |
| | 71 | 4) ST_AsRaster(geometry, pixeltype, val, nodataval, x float8, y float8) – 2, pixel size is computed by dividing the extent by 250. This variant is optional and discouraged as it results in many unaligned rasters for a table with many geometries. |
| | 72 | |
| | 73 | 5) ST_AsRaster(geometry, pixeltype, val, nodataval, x float8, y float8, pixelsize) – 3, this is one of the preferred variant when the geometry is not the result of ST_DumpAsPolygon or ST_Intersection. |
| | 74 | |
| | 75 | 6) ST_AsRaster(geometry, pixeltype, val, nodataval, x float8, y float8, pixelsizex, pixelsizey) - 4, this is one of the preferred variant when the geometry is not the result of ST_DumpAsPolygon or ST_Intersection. |
| | 76 | |
| | 77 | 7) ST_AsRaster(geometry, pixeltype, val, nodataval, x float8, y float8, pixelsizex, pixelsizey, skewx, skewy) – 6, this is one of the preferred variant when the geometry is not the result of ST_DumpAsPolygon or ST_Intersection. |
| | 78 | |
| | 79 | * The '''third series of variant''' have their alignment specified by the upper left corner of the upper left pixel of the desired raster. |
| | 80 | |
| | 81 | 8) ST_AsRaster(geometry, pixeltype, val, nodataval, ulx, uly, width, height, pixelsize) – 2,2,1, this is useful to rasterize geometries to a common raster extent. Some geometries might be outside the extent of the desired raster extent resulting in a nodata value raster. |
| | 82 | |
| | 83 | 9) ST_AsRaster(geometry, pixeltype, val, nodataval, ulx, uly, width, height, pixelsizex, pixelsizey, skewx, skewy) – 2,2,4, this is useful to rasterize geometries to a common raster extent. Some geometries might be outside the extent of the desired raster extent resulting in a nodata value raster. This is the only variant which must be implemented in the tr_pg layer. All other variant must be implemented in pl/PgSQL and derive the argument to call this variant. |
| | 84 | |
| | 85 | * The '''fourth series of variant''' get their alignment (and size for variant 10 and 12) from an existing raster. Variant 10 and 11 keep the same extent as the provided raster and variant 12 and 13 have their extent cropped to the extent of the geometry. |
| | 86 | |
| | 87 | 10) ST_AsRaster(geometry, val, raster) – 0, the target raster metadata (including pixeltype, hasnodatavalue and nodatavalue) are copied from the provided raster |
| | 88 | |
| | 89 | 11) ST_AsRaster(geometry, pixeltype, val, nodataval, raster) – 0, the target raster metadata are copied from the provided raster. |
| | 90 | |
| | 91 | 12) ST_AsRaster(geometry, val, raster, “CROP”) – 0, the target raster alignment and pixel size are copied from the provided raster (including pixeltype, hasnodatavalue and nodatavalue) but the extent is reduced to the geometry extent. We should not create a (too big) raster and crop at the end. The final extent should be computed BEFORE burning. |
| | 92 | |
| | 93 | 13) ST_AsRaster(geometry, pixeltype, val, nodataval, raster, “CROP”) – 0, the target raster alignment and pixel size are copied from the provided raster but the extent is reduced to the geometry extent. We should not create a (too big) raster and crop at the end. The final extent should be computed BEFORE burning. |
| | 94 | |
| | 95 | '''Questions''' |
| | 96 | |
| | 97 | -How does GDAL/ArcGIS choose the pixel size and the ul of the final raster? |
| | 98 | |
| | 99 | -How does GDAL/ArcGIS allow selecting the value column -What if it is a text column? |
| | 100 | |
| | 101 | -How does GDAL/ArcGIS allow giving a thickness to points and lines -No thickness is given. All pixels intersecting the geometry are burned following a selected method. |
| | 102 | |
| | 103 | -How does GDAL/ArcGIS select which value to assign to the pixel when two or more features intersect with the pixel? |
| | 104 | |
| | 105 | |
