Changes between Version 24 and Version 25 of PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools

Timestamp:

06/17/12 15:37:55 (13 years ago)

Author:

qliu

Comment:

--

PostGIS_Raster_SoC_Idea_2012/Distance_Analysis_Tools

@@ -108 +108 @@
 <b>Comment from Mentor:</b>
 <p>
-I really think we want to avoid having to produce an intermediate raster of sources. PostGIS is strong on raster/vector interaction and I really don't see why someone would prefer to provide sources as raster. The sources should come from a table of point. Now this raise a certain number of issues:
-
- -What if the table contains more than one point?
- -What if some of those points are outside the raster extent?
- -Another issue is: What if the raster I want to produce does not fit into the PostgreSQL maximum field size?
-
-These are the kind or difficulties one encounters when working in a database.
-
+I really think we want to avoid having to produce an intermediate raster of sources. PostGIS is strong on raster/vector interaction and I really don't see why someone would prefer to provide sources as raster. The sources should come from a table of point. Now this raise a certain number of issues:</br>
+</br>
+ -What if the table contains more than one point?</br>
+ -What if some of those points are outside the raster extent?</br>
+ -Another issue is: What if the raster I want to produce does not fit into the PostgreSQL maximum field size?</br>
+</br>
+These are the kind or difficulties one encounters when working in a database.</br>
+</br>
 Think about large tiled coverage, Delaunay triangulation,  aggregate functions and all the combinatory of "small/very large number of point" and "small/very large raster coverage". Ideally we want to provide a solution working for every limit cases.
 </p>