27 | | '''ST_AsRaster(geometry, pixeltype, val, nodataval, ulx, uly, width, height, pixelsizex, pixelsizey, skewx, skewy) -> raster''' |
28 | | |
29 | | * Rasterize the provided geometry to a raster created using the specified parameters. |
30 | | * Implemented as a wrapper around GDAL like ST_DumpAsPolygons() does. |
31 | | * ST_AsRaster is necessary to implement ST_Intersection(geometry, raster, band) -> raster and an eventual ST_BurnToRaster(raster, geometry) -> raster 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 of the resulting raster must be set and the nodata value is set to the provided value (expect in variant 10 and 12). |
35 | | |
36 | | * Alignment, width, height and pixelsize are optionally computed:[[BR]] |
37 | | -From the vector extent of the geometry,[[BR]] |
38 | | -Imposed with parameters,[[BR]] |
39 | | -From another provided 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 ulx, uly, width and height as the provided raster. A 'CROP' option allows cropping the resulting raster to the minimal extent of the geometry keeping the x and y alignment of the provided raster.[[BR]] |
45 | | -Default alignment 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 pixelsizes 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 useful 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 useful 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 | | * It would be interesting to have a 'ADD_WEIGHTING_INFO' option to create a second band with the length of the line or the area of polygon (or the distance to the center of points) intersecting each pixel. This band could then be used in a ST_Union(rast, 'MAX_LENGTH') or a ST_Union(rast, 'MAX_AREA') function burning the value of the line having the longest intersection with the pixel or the value of the polygon having the biggest intersecting area. For this to be useful ST_Union should work with a ST_MapAlgebra(rast1, rast2) able to refer to pixel value in any band (e.g. rast1.2 referring to the pixel value in the second band). The ST_Union(rast, 'MAX_LENGTH') aggregate could then be implemented with the following state expression: 'CASE WHEN rast1.2 > rast2.2 THEN rast1.1 ELSE rast2.1 ENDIF'. Otherwise we would have to imbricate four Mapalgebra functions. ST_Union(rast, 'MAX_COMBINED_LENGTH') could use a ST_MapAlgebra(rast1, rast2) able to take a custom user function. The state function would accumulate, in a temporary table, the total intersecting length or area for a same value over every overlapping pixels and the final function would determine which of the values from the temporary table would be the right one to burn in the final raster pixel. Variations of ST_Union which could then be easily implemented could be: ST_Union(rast, 'WEIGHTED') to weight the value with the length, the area or the count, ST_Union(rast, 'MOST_FREQUENT') to burn the value for the most frequent points values. |
54 | | |
55 | | '''Variants''' |
56 | | |
57 | | * There are many variants because we are creating a raster from scratch. We want to make it easy (serie one and four) to convert geometries to raster and at the same time we want to have flexibility to control the resulting raster properties (series two and three). |
58 | | * Variant 3, 5 and 13 are the most useful. |
59 | | * Variant 6, 7, 8, 9, 10, 11, 12 are also useful. |
60 | | * Variant 1, 2, 4 are useful for quick conversion. |
61 | | * All variant should be pl/pgsql variant of variant 9 which is the only one needing to be implemented as a rt_pg functions. |
62 | | |
63 | | * The '''first series of variant''' get their alignment from the extent of the geometry. |
64 | | |
65 | | 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. |
66 | | |
67 | | 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. |
68 | | |
69 | | 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. |
70 | | |
71 | | * The '''second series of variant''' have their alignment specified by an arbitrary pixel corner of the desired raster. |
72 | | |
73 | | 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. |
74 | | |
75 | | 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. |
76 | | |
77 | | 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. |
78 | | |
79 | | 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. |
80 | | |
81 | | * The '''third series of variant''' have their alignment specified by the upper left corner of the upper left pixel of the desired raster. |
82 | | |
83 | | 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. |
84 | | |
85 | | 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. |
86 | | |
87 | | * 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. |
88 | | |
89 | | 10) ST_AsRaster(geometry, val, raster) – 0, the target raster metadata (including pixeltype, hasnodatavalue and nodatavalue) are copied from the provided raster |
90 | | |
91 | | 11) ST_AsRaster(geometry, pixeltype, val, nodataval, raster) – 0, the target raster metadata are copied from the provided raster. |
92 | | |
93 | | 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. |
94 | | |
95 | | 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. |
96 | | |
97 | | '''Questions''' |
98 | | |
99 | | -How does GDAL/ArcGIS choose the pixel size and the ul of the final raster? |
100 | | |
101 | | -How does GDAL/ArcGIS allow selecting the value column -What if it is a text column? |
102 | | |
103 | | -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. |
104 | | |
105 | | -How does GDAL/ArcGIS select which value to assign to the pixel when two or more features intersect with the pixel? |
106 | | |
| 27 | '''ST_AsRaster(geometry, pixeltype, val, nodataval, ulx, uly, width, height, pixelsizex, pixelsizey, skewx, skewy) -> raster - done see below''' |
| 1182 | |
| 1183 | == '''Objective FV.02 - Being able to intersect vector and raster to produce raster.''' == |
| 1184 | |
| 1185 | '''ST_AsRaster(geometry, pixeltype, val, nodataval, ulx, uly, width, height, pixelsizex, pixelsizey, skewx, skewy) -> raster''' |
| 1186 | |
| 1187 | ST_AsRaster provides the ability convert a geometry into a raster. To create the raster, the X and Y scale or the width and height of the raster must be provided. |
| 1188 | |
| 1189 | The output raster will be in the same coordinate system as the source geometry. The only exception is for ST_AsRaster variations with a raster input parameter. |
| 1190 | |
| 1191 | 1. ST_AsRaster([[BR]] |
| 1192 | geom geometry,[[BR]] |
| 1193 | scalex double precision, scaley double precision,[[BR]] |
| 1194 | gridx double precision DEFAULT NULL, gridy double precision DEFAULT NULL,[[BR]] |
| 1195 | pixeltype text[] DEFAULT ARRAY['8BUI']::text[],[[BR]] |
| 1196 | value double precision[] DEFAULT ARRAY[1]::double precision[],[[BR]] |
| 1197 | nodataval double precision[] DEFAULT ARRAY[0]::double precision[],[[BR]] |
| 1198 | skewx double precision DEFAULT 0, skewy double precision DEFAULT 0 |
| 1199 | ) -> raster |
| 1200 | |
| 1201 | geom: the geometry to convert to a raster. Can be any valid PostGIS geometry. |
| 1202 | |
| 1203 | scalex: the scale/pixel size in the X axis of the output raster. If scalex and scaley are zero (0), the output raster's scale will be autocomputed. |
| 1204 | |
| 1205 | scaley: the scale/pixel size in the Y axis of the output raster. If scalex and scaley are zero (0), the output raster's scale will be autocomputed. |
| 1206 | |
| 1207 | pixeltype: array of pixel types for each band. Each array element is a band. |
| 1208 | |
| 1209 | value: array of values to burn into the raster for the geometry. Each array element is a band. |
| 1210 | |
| 1211 | nodataval: array of nodata values to burn into the raster. Each array element is a band. If an array element is null, that band will not have a nodata value. |
| 1212 | |
| 1213 | upperleftx: the X value of the upper-left corner of the output raster |
| 1214 | |
| 1215 | upperlefty: the Y value of the upper-left corner of the output raster |
| 1216 | |
| 1217 | gridx: the X coordinate of a point on the grid to which the raster will be aligned. Value is in the raster's world coordinates. |
| 1218 | |
| 1219 | gridy: the Y coordinate of a point on the grid to which the raster will be aligned. Value is in the raster's world coordinates. |
| 1220 | |
| 1221 | skewx: the skew along the X axis of the raster. by default, the skew along the X axis is zero. |
| 1222 | |
| 1223 | skewy: the skew along the Y axis of the raster. by default, the skew along the X axis is zero. |
| 1224 | |
| 1225 | ''If the number of elements for pixeltype, value and nodataval do not match, the minimum number of elements will be used.'' |
| 1226 | |
| 1227 | 2. ST_AsRaster( |
| 1228 | geom geometry,[[BR]] |
| 1229 | scalex double precision, scaley double precision,[[BR]] |
| 1230 | pixeltype text[],[[BR]] |
| 1231 | value double precision[] DEFAULT ARRAY[1]::double precision[],[[BR]] |
| 1232 | nodataval double precision[] DEFAULT ARRAY[0]::double precision[],[[BR]] |
| 1233 | upperleftx double precision DEFAULT NULL, upperlefty double precision DEFAULT NULL,[[BR]] |
| 1234 | skewx double precision DEFAULT 0, skewy double precision DEFAULT 0 |
| 1235 | ) -> raster |
| 1236 | |
| 1237 | 3. ST_AsRaster( |
| 1238 | geom geometry,[[BR]] |
| 1239 | width integer, height integer,[[BR]] |
| 1240 | gridx double precision DEFAULT NULL, gridy double precision DEFAULT NULL,[[BR]] |
| 1241 | pixeltype text[] DEFAULT ARRAY['8BUI']::text[],[[BR]] |
| 1242 | value double precision[] DEFAULT ARRAY[1]::double precision[],[[BR]] |
| 1243 | nodataval double precision[] DEFAULT ARRAY[0]::double precision[],[[BR]] |
| 1244 | skewx double precision DEFAULT 0, skewy double precision DEFAULT 0 |
| 1245 | ) -> raster |
| 1246 | |
| 1247 | 4. ST_AsRaster( |
| 1248 | geom geometry,[[BR]] |
| 1249 | width integer, height integer,[[BR]] |
| 1250 | pixeltype text[],[[BR]] |
| 1251 | value double precision[] DEFAULT ARRAY[1]::double precision[],[[BR]] |
| 1252 | nodataval double precision[] DEFAULT ARRAY[0]::double precision[],[[BR]] |
| 1253 | upperleftx double precision DEFAULT NULL, upperlefty double precision DEFAULT NULL,[[BR]] |
| 1254 | skewx double precision DEFAULT 0, skewy double precision DEFAULT 0 |
| 1255 | ) -> raster |
| 1256 | |
| 1257 | 5. ST_AsRaster( |
| 1258 | geom geometry,[[BR]] |
| 1259 | scalex double precision, scaley double precision,[[BR]] |
| 1260 | gridx double precision, gridy double precision,[[BR]] |
| 1261 | pixeltype text,[[BR]] |
| 1262 | value double precision DEFAULT 1,[[BR]] |
| 1263 | nodataval double precision DEFAULT 0,[[BR]] |
| 1264 | skewx double precision DEFAULT 0, skewy double precision DEFAULT 0[[BR]] |
| 1265 | ) -> raster |
| 1266 | |
| 1267 | 6. ST_AsRaster( |
| 1268 | geom geometry,[[BR]] |
| 1269 | scalex double precision, scaley double precision,[[BR]] |
| 1270 | pixeltype text,[[BR]] |
| 1271 | value double precision DEFAULT 1,[[BR]] |
| 1272 | nodataval double precision DEFAULT 0,[[BR]] |
| 1273 | upperleftx double precision DEFAULT NULL, upperlefty double precision DEFAULT NULL,[[BR]] |
| 1274 | skewx double precision DEFAULT 0, skewy double precision DEFAULT 0 |
| 1275 | ) -> raster |
| 1276 | |
| 1277 | 7. ST_AsRaster( |
| 1278 | geom geometry,[[BR]] |
| 1279 | width integer, height integer,[[BR]] |
| 1280 | gridx double precision, gridy double precision,[[BR]] |
| 1281 | pixeltype text,[[BR]] |
| 1282 | value double precision DEFAULT 1,[[BR]] |
| 1283 | nodataval double precision DEFAULT 0,[[BR]] |
| 1284 | skewx double precision DEFAULT 0, skewy double precision DEFAULT 0 |
| 1285 | ) -> raster |
| 1286 | |
| 1287 | 8. ST_AsRaster( |
| 1288 | geom geometry,[[BR]] |
| 1289 | width integer, height integer,[[BR]] |
| 1290 | pixeltype text,[[BR]] |
| 1291 | value double precision DEFAULT 1,[[BR]] |
| 1292 | nodataval double precision DEFAULT 0,[[BR]] |
| 1293 | upperleftx double precision DEFAULT NULL, upperlefty double precision DEFAULT NULL,[[BR]] |
| 1294 | skewx double precision DEFAULT 0, skewy double precision DEFAULT 0 |
| 1295 | ) -> raster |
| 1296 | |
| 1297 | 9. ST_AsRaster( |
| 1298 | geom geometry,[[BR]] |
| 1299 | ref raster,[[BR]] |
| 1300 | pixeltype text[] DEFAULT ARRAY['8BUI']::text[],[[BR]] |
| 1301 | value double precision[] DEFAULT ARRAY[1]::double precision[],[[BR]] |
| 1302 | nodataval double precision[] DEFAULT ARRAY[0]::double precision[] |
| 1303 | ) -> raster |
| 1304 | |
| 1305 | 10. ST_AsRaster( |
| 1306 | geom geometry,[[BR]] |
| 1307 | ref raster,[[BR]] |
| 1308 | pixeltype text,[[BR]] |
| 1309 | value double precision DEFAULT 1,[[BR]] |
| 1310 | nodataval double precision DEFAULT 0 |
| 1311 | ) -> raster |
| 1312 | |
| 1313 | |
| 1314 | ~~ * Rasterize the provided geometry to a raster created using the specified parameters.~~ |
| 1315 | ~~ * Implemented as a wrapper around GDAL like ST_DumpAsPolygons() does.~~ |
| 1316 | ~~ * ST_AsRaster is necessary to implement ST_Intersection(geometry, raster, band) -> raster and an eventual ST_BurnToRaster(raster, geometry) -> raster where the provided geometry is first rasterized to the same alignment as the other raster involved.~~ |
| 1317 | ~~ * 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.~~ |
| 1318 | |
| 1319 | ~~ * The raster is burned with the specified value converted (or truncated) with a warning to the provided pixeltype. The hasnodatavalue flag of the resulting raster must be set and the nodata value is set to the provided value (expect in variant 10 and 12).~~ |
| 1320 | |
| 1321 | ~~ * Alignment, width, height and pixelsize are optionally computed:~~[[BR]] |
| 1322 | ~~ -From the vector extent of the geometry,~~[[BR]] |
| 1323 | ~~ -Imposed with parameters,~~[[BR]] |
| 1324 | ~~ -From another provided raster.~~ |
| 1325 | |
| 1326 | ~~ * Alignment can be optionally specified as:~~[[BR]] |
| 1327 | ~~ -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]] |
| 1328 | ~~ -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]] |
| 1329 | ~~ -An existing raster. The x and y are derived from the provided raster and the resulting raster has the same ulx, uly, width and height as the provided raster. A 'CROP' option allows cropping the resulting raster to the minimal extent of the geometry keeping the x and y alignment of the provided raster.~~[[BR]] |
| 1330 | ~~ -Default alignment 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()).~~ |
| 1331 | |
| 1332 | ~~ * Pixelsize can be optionally specified as:~~[[BR]] |
| 1333 | ~~ -One or two floating point numbers. If only one is provided, both x and y pixelsizes are assigned the same value.~~[[BR]] |
| 1334 | ~~ -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 useful only when the alignment is specified as the upper left corner of the raster.~~[[BR]] |
| 1335 | ~~ -“FIRST_SEGMENT_LENGTH”. The pixelsize is set to the length of the first line segment encountered in the geometry. This is useful 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]] |
| 1336 | ~~ -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.~~ |
| 1337 | |
| 1338 | ~~ * It would be interesting to have a 'ADD_WEIGHTING_INFO' option to create a second band with the length of the line or the area of polygon (or the distance to the center of points) intersecting each pixel. This band could then be used in a ST_Union(rast, 'MAX_LENGTH') or a ST_Union(rast, 'MAX_AREA') function burning the value of the line having the longest intersection with the pixel or the value of the polygon having the biggest intersecting area. For this to be useful ST_Union should work with a ST_MapAlgebra(rast1, rast2) able to refer to pixel value in any band (e.g. rast1.2 referring to the pixel value in the second band). The ST_Union(rast, 'MAX_LENGTH') aggregate could then be implemented with the following state expression: 'CASE WHEN rast1.2 > rast2.2 THEN rast1.1 ELSE rast2.1 ENDIF'. Otherwise we would have to imbricate four Mapalgebra functions. ST_Union(rast, 'MAX_COMBINED_LENGTH') could use a ST_MapAlgebra(rast1, rast2) able to take a custom user function. The state function would accumulate, in a temporary table, the total intersecting length or area for a same value over every overlapping pixels and the final function would determine which of the values from the temporary table would be the right one to burn in the final raster pixel. Variations of ST_Union which could then be easily implemented could be: ST_Union(rast, 'WEIGHTED') to weight the value with the length, the area or the count, ST_Union(rast, 'MOST_FREQUENT') to burn the value for the most frequent points values.~~ |
| 1339 | |
| 1340 | ~~ '''Variants'''~~ |
| 1341 | |
| 1342 | ~~ * There are many variants because we are creating a raster from scratch. We want to make it easy (serie one and four) to convert geometries to raster and at the same time we want to have flexibility to control the resulting raster properties (series two and three).~~ |
| 1343 | ~~ * Variant 3, 5 and 13 are the most useful.~~ |
| 1344 | ~~ * Variant 6, 7, 8, 9, 10, 11, 12 are also useful.~~ |
| 1345 | ~~ * Variant 1, 2, 4 are useful for quick conversion.~~ |
| 1346 | ~~ * All variant should be pl/pgsql variant of variant 9 which is the only one needing to be implemented as a rt_pg functions.~~ |
| 1347 | |
| 1348 | ~~ * The '''first series of variant''' get their alignment from the extent of the geometry.~~ |
| 1349 | |
| 1350 | ~~ 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.~~ |
| 1351 | |
| 1352 | ~~ 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.~~ |
| 1353 | |
| 1354 | ~~ 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.~~ |
| 1355 | |
| 1356 | ~~ * The '''second series of variant''' have their alignment specified by an arbitrary pixel corner of the desired raster.~~ |
| 1357 | |
| 1358 | ~~ 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.~~ |
| 1359 | |
| 1360 | ~~ 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.~~ |
| 1361 | |
| 1362 | ~~ 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.~~ |
| 1363 | |
| 1364 | ~~ 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.~~ |
| 1365 | |
| 1366 | ~~ * The '''third series of variant''' have their alignment specified by the upper left corner of the upper left pixel of the desired raster.~~ |
| 1367 | |
| 1368 | ~~ 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.~~ |
| 1369 | |
| 1370 | ~~ 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.~~ |
| 1371 | |
| 1372 | ~~ * 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.~~ |
| 1373 | |
| 1374 | ~~ 10) ST_AsRaster(geometry, val, raster) – 0, the target raster metadata (including pixeltype, hasnodatavalue and nodatavalue) are copied from the provided raster~~ |
| 1375 | |
| 1376 | ~~ 11) ST_AsRaster(geometry, pixeltype, val, nodataval, raster) – 0, the target raster metadata are copied from the provided raster.~~ |
| 1377 | |
| 1378 | ~~ 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.~~ |
| 1379 | |
| 1380 | ~~ 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.~~ |
| 1381 | |
| 1382 | ~~ '''Questions'''~~ |
| 1383 | |
| 1384 | ~~ -How does GDAL/ArcGIS choose the pixel size and the ul of the final raster?~~ |
| 1385 | |
| 1386 | ~~ -How does GDAL/ArcGIS allow selecting the value column -What if it is a text column?~~ |
| 1387 | |
| 1388 | ~~ -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.~~ |
| 1389 | |
| 1390 | ~~ -How does GDAL/ArcGIS select which value to assign to the pixel when two or more features intersect with the pixel?~~ |
| 1391 | |
| 1392 | ---- |