Changes between Version 19 and Version 20 of PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools

Timestamp:

06/11/12 16:10:57 (13 years ago)

Author:

qliu

Comment:

--

PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools

@@ -112 +112 @@
 '''What did you get done this week?'''
  * Wrote a comparison of raster data storage and manipulation in PostgreSQL and Oracle
- * Wrote a proposal on how to adopt the concepts and algorithms of distance calculation in PostGIS.
+ * Wrote a proposal on how to adopt the concepts and algorithms of Euclidean distance calculation in PostGIS.
 
 ''' What do you plan on doing next week?'''
- * TO-DO
+ * Write a proposal on how to adopt the concepts and algorithms of Cost-weighted distance calculation in PostGIS
 
 '''Are you blocked on anything?'''
- * 
+ * Based on the feed back I got from Pierre last week, I agreed that we want to avoid having to produce an intermediate raster of the source point data. Since PostGIS Raster provide the capability of seamless vector-raster interactions, it is preferable that we expect the input source point data to be a vector layer, which is stored in PostgreSQL as a table of points with geomegry. The concepts of the distance calculation in ArcGIS and GRASS were all based on raster source data (ArcGIS will first rasterize the vector layer if necessary). So I was stucked at this point on how to avoid generating this intermediate raster layer if we want the source data to be vector points.
 
 [[BR]]
 === My Analysis Reports ===
  * [https://docs.google.com/document/d/1-5KorOwkdnR8BUZsDBvj_ez3gXmdEh8WHKtiJW3smrQ/edit Compare Raster Data Storage and Manipulation in PostgreSQL and Oracle GeoRaster]
+
+ * [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)]