| 306 | | |
| 307 | | ---- |
| 308 | | * [https://docs.google.com/document/d/1orjY4PnkFX4Kv2m8bpEpCUyf-fW_-fb0_2V37FhqBO8/edit Generate Euclidean Distance Surface in PostGIS (Proposal) (first working on a single raster row)] |
| | 306 | * Oracle GeoRaster |
| | 307 | * Stored as two related types in different tables |
| | 308 | * SDO_GEORASTER table: Images |
| | 309 | * SDO_RASTER table: Tiles |
| | 310 | * Raster stored in two database tables:[[BR]] |
| | 311 | [[Image(https://lh6.googleusercontent.com/-CR2KxwqC4q8/T-AKwg0tzCI/AAAAAAAAA4Q/ObDWA9Y52FI/s532/Compare+Raster+Data+Storage+and+Manipulation+in+PostgreSQL+and+Oracle+GeoRaster%281%29.jpg)]] |
| | 312 | 2. Georeferencing: |
| | 313 | * ostGIS Raster: |
| | 314 | * Embedded in raster header |
| | 315 | * Each raster (tile) is geo-referenced |
| | 316 | * Oracle GeoRaster: |
| | 317 | * Embedded as a metadata component of the GeoRaster object |
| | 318 | * Only SDO_RASTER is geo-referenced |
| | 319 | 3. Spatial Indexing: |
| | 320 | * PostGIS Raster: |
| | 321 | * GiST index on raster column |
| | 322 | * Oracle GeoRaster: |
| | 323 | * R-Tree index on GeoRaster object |
| | 324 | 4. Pyramids: |
| | 325 | * PostGIS Raster: |
| | 326 | * Pyramids generated on loading time |
| | 327 | * Pyramids stored in different table than the raster data |
| | 328 | * Oracle GeoRaster: |
| | 329 | * Reduced resolution versions of raster generated by resampling |
| | 330 | * Pyramids stored in the same raster table for GeoRaster object |
| | 331 | 5. Loading Data: |
| | 332 | * PostGIS Raster: |
| | 333 | * All GDAL accepted formats |
| | 334 | * Easy |
| | 335 | * Oracle GeoRaster: |
| | 336 | * Few formats accepted |
| | 337 | * Hard |
| | 338 | 6. Raster Data Implementaion (take vector-raster intersection for example): |
| | 339 | * PostGIS Raster: |
| | 340 | * Implement seamless vector-raster analyses |
| | 341 | * Do analysis independently of the data presentation |
| | 342 | * Vector-Raster intersection: |
| | 343 | * Really intersect Vector Data with Raster Data |
| | 344 | * Raster data is first polygonized to be intersected with Vector data |
| | 345 | * Oracle GeoRaster: |
| | 346 | * Was primarily designed for raster data storage not for anlysis |
| | 347 | * Vector-Raster intersection: |
| | 348 | * Intersect Vector data with MBR of raster data not with the raster data itself |
| | 349 | * Process is faster though |
| | 350 | ---- |
| | 351 | '''Generate Euclidean Distance Surface in PostGIS (Proposal) (first working on a single raster row)''' |
| | 352 | |
| | 353 | * Concepts: |
| | 354 | * We first think of working on a single raster row (a single tile) containing only one band and then maybe apply it on a tiled raster coverage with multi-bands. We first assume the source point(s) is/are within the raster extent. |
| | 355 | * Generate a raster tile in which the value for each pixel represents the Euclidean distance from the pixel to the nearest source point. |
| | 356 | * Euclidean distance is calculated from the center of the source pixel to the center of each of the surrounding pixels. |
| | 357 | * What should be the input source data? |
| | 358 | * ArcGIS accepts both raster and vector layers as input source data, but will first transform the source layer into raster layer if it is in the vector format; Thus, it produces an intermediate raster of sources. |
| | 359 | * Grass and GDAL proximity tools accept only raster layer as the input source data. |
| | 360 | * We want to avoid having to produce an intermediate raster of sources, since PostGIS implements seamless vector-raster interactions. |
| | 361 | * Thus, we expect input source data to be a vector point layer, which is stored as a table of point with geometries. |
| | 362 | * What should be the output result? |
| | 363 | * Results are stored as pixel values in the raster |
| | 364 | * Algorithms: |
| | 365 | a. Make an empty raster new_rast, using the same extent as the input vector point data source_point, set pixel value to NoData value. |
| | 366 | b. Utilize ST_SetValue(raster rast, geometry pt, double newvalue) function to designate source pixels in the resulting raster where vector source point(s) intersect(s) with the new raster.We want to assign “0” as new pixel value to pixels as source pixel(point) since the Euclidean distance from source to itself is zero. |
| | 367 | c. Calculate Euclidean distance from the center of source pixel(s) to each pixel in the raster:[[BR]] |
| | 368 | d(dx,dy) = sqrt(dx^2 + dy^2)[[BR]] |
| | 369 | Unit is pixel/cell |
| | 370 | d. Set pixel value to the resulted distance[[BR]] |
| | 371 | '''Need to consider scan algorithm in case of more than one point in the source data''' |
| | 372 | e. Utilize ST_MapAlgebraExpr() function to multiply resulting distance raster with pixel size to get the real geographic distance in the unit assigned in the georeferencing info. |
| | 373 | * Issues to be considered: |
| | 374 | * Scanning method in case of source point data containing more than one source point: |
| | 375 | * Shortest distance will be assigned to resulted raster |
| | 376 | * In case there is an equal distance to more than one source, the pixel is assigned to the source that is first encountered in the scanning process |
| | 377 | * Specify maximum distance as the threshold that the accumulative distance values cannot exceed |
| | 378 | * Any pixel that has accumulative Euclidean distance value exceed this value will be assigned NoData for output value. |
| | 379 | * The default threshold is to the edge of the output raster. |
| | 380 | * How to apply to multi-band tiled raster coverage |
| | 381 | * Some of the source points are outside the raster extent |
| | 382 | * Raster storage in PostgreSQL |
| | 383 | * The resulting raster does not fit into the PostgreSQL maximum field size |
