Hi raster people, I'm starting a 2-3 year project to develop a web-based application to automate certain GIS tasks commonly needed in ecological research. The tool will support queries over VERY large extent based on a Canada-wide assemblages of raster and vector data layers. The queries will typically involve intersecting those layers with buffers defined around points or transects.
We would like to implement this system with PostGIS, but it currently does not to support raster data. We could convert all our data to a single format (raster or vector) and use other tools, however PostGIS seems to us the best and most powerful vector analysis tool available and we would prefer to use it. We would like to develop a unified toolkit so that the application mostly need not worry about whether base layers are in vector or raster format. We are then strong proponents of having raster functionality in PostGIS. I have reviewed every thread on this list on the subject. I have analysed them and I have compiled them in the wiki (http://postgis.refractions.net/support/wiki/index.php?RasterNotes). The argument goes like this: The geodatabase paradigm has been a major recent enhancement in GIS technology, I feel that the seamless integration of raster and vector analysis should be one of the next. Spatial analysis is emerging, beside the making and publishing of maps, as one of the main desktop and web-GIS applications. Rastor/vector seamless integration is already done for display (in most GIS and with MapServer or ArcIMS on the web) but definitely not for analysis. Desktop analysts must still learn to use two distinct toolsets within most (all?) GIS packages: one toolset for raster and another for vector data. Would not it be easier to build and use applications if we had a unique data query and analysis toolset independent of the data model? I don't know any tool having this approach right now. A PostGIS foundation that addressed this problem would offer better directions to application developers than the dichotomic one proposed by ESRI since their beginning. It would provide the necessary abstraction to develop GIS with ONE set of analysis tools. I feel this is one good reason to integrate raster in PostGIS. There is "GIS" in the word "PostGIS". PostGIS should then provide a COMPLETE GIS data foundation (read "base"!) for geoapplication developers. I think Steve Marshall's design is a good step in this direction (http://postgis.refractions.net/pipermail/postgis-users/2006-December/01 4059.html). At the same time, we would have a chance to reconsider the raster model as a coverage instead of a series of images. Spatial databases got rid of map sheets by allowing complete vector coverages to be stored as single table (e.g. the entire United States) This approach should works for raster data as well. Isn't this the approach taken by ArcSDE? In summary, I think we must stop thinking about PostGIS as a mere vector data repository to support mapping applications. This is the way most objectors to raster integration seem to view it. We must think about PostGIS as a powerfull indexed data analysis tool. Seamless raster/vector analysis in the database could lead to a major simplification of geoapplications. I prepared a PowerPoint presentation with a complete specification of raster in PostGIS and an analysis of what should be the result of overlay operation between raster and vector layers. You can download this PPT at: http://www.cef-cfr.ca/uploads/Membres/WKTRasterPostGIS.ppt Please have a look at it, feel free to answer questions I ask and comment. Here are the main propositions of this design: -Like a vector feature, rasters are stored as a subtype of "geometry"(a new WKB/WKT geometry type called RASTER instead of POINT or POLYGON) -There is no distinction between a raster and a tile. A tile is a raster and a table of rasters can be seen as a tile coverage. Hence, contrary to Oracle GeoRaster, only one table is needed to store a coverage and there is only one type. -It support raster in the database AND raster out of the database. This mailing list has shown that both approaches have their pros and cons. Let's not impose one approach over the other. -It supports: multi-band, pyramids and variable nodata value, raster size, pixel size and pixel type for each row. -It supports import/export from/to Tiff and JPEG. But moreover seamless raster/vector integration is materialized by theses propositions: -A lot of existing vector-only functions are adapted to work with raster also. -Most new raster functions are also implemented to work with vector. Only basic raster derivation functions are proposed. -Most vector/vector existing functions are adapted to work seamlessly with raster/vector or raster/raster I also want to ask: -What is the status of PGRaster? Is any development now underway? We have some resources to devote to this project over the next few years and are very interested in forming collaborations to move this work forward. Pierre Racine GIS/Programmer Analyst University Laval http://www.cef-cfr.ca/index.php?n=Membres.PierreRacine _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
