From 32cd276a7690b6f96cef7fe9cbc86a464bcfc940 Mon Sep 17 00:00:00 2001 From: Bborie Park Date: Sat, 16 Feb 2013 21:47:18 +0000 Subject: [PATCH] Update raster TODO as it was sorely out of date git-svn-id: http://svn.osgeo.org/postgis/trunk@11096 b70326c6-7e19-0410-871a-916f4a2858ee --- raster/TODO | 31 ------------------------------- 1 file changed, 31 deletions(-) diff --git a/raster/TODO b/raster/TODO index f043f6fc4..00fa40e55 100644 --- a/raster/TODO +++ b/raster/TODO @@ -7,34 +7,3 @@ yet to be ticketed in PostGIS trac and lack specifics. == Simple Projects == == Larger Projects == - --- Spatial Relationships functions -- - -In addition to the existing or ticketed spatial relationship functions, it may -be worth implementing the following functions. - - - ST_Equals (?) - - ST_Relate (?) - - ST_RelateMatch (?) - -Like the ST_Intersects() function and its variants, these functions will need -to support both raster/raster and raster/geometry. It may be easier for these -functions to be done in vector-space where the rasters' bands are converted to -pixels and then spatially tested. This should permit the quick delivery of -useful functions though it may not be the fastest solution. - --- n-raster Iterator -- - -To properly handle aggregate and n-raster mapalgebra operations (mapalgebra, -union, etc), a generic iterator function is needed. This also pushes the -core mapalgebra functionality down to rt_core instead of rt_pg. - --- neighborhood tile support -- - -When processing a tile's pixel in a neighborhood calculation, there needs to -be a way to get the neighboring tiles so as to provide the neighboring pixels -of the pixel being processed. This is a difficult question because rasters -are passed to functions with no information about context. Simply passing -a tablename and raster column is inappropriate as the table and raster column -could be more complex, such as when a table contains daily observations of a -temperature surface. -- 2.40.0