>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.
>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 Pierre, Since you asked me off list if your proposition would work for me. I felt compelled to resend this on list. I would also like to add that if you look at Dane's posed problem in previous postgis post, it is a common scenario where I have really wanted RASTER in the database and where your proposed ST_Intersection(RASTER, VECTOR), ST_Interects(RASTER,VECTOR) would have worked nicely (e.g. steps from his problem) 3) perform an elevation lookup to raster data to calculate the gradient of each 500 ft segment and.. 4) combine all adjacent linestrings which fall into similar gradient classes. It may be also interesting to look at what Manifold.net handles RASTERs since they have an SQL implementation that considers RASTERs. Granted they are not closed source. I haven't used Manifold enough to comment on it, but I was never the less amused when I saw an SQL statement using RASTER data. Might be worth a look for some thoughts. http://www.manifold.net/doc/raster_extensions.htm http://www.manifold.net/doc/manifold.htm I think when most people think of RASTER they think aerials (well that's what I think of) mostly because all the people I know using ArcSDE and Oracle RASTER use it for just that and pretty much nothing else. Granted you can do analytically useful stuff with it such as extrude building footprints from the aerial, but people seem content to do that kind of stuff with non-db tools or just assume its some magic offered by mystical gods working up there. But my eyes have been opened by PostGIS users who really seem to have an analytical need for that kind of stuff and particularly related with their vector data. My eyes were also opened when I looked at an SQL puzzle where instead of passing thousands of arguments to a stored proc like everyone else, one person solved the problem quite elegantly by passing one bitmap. When you think about RASTER as really just a bitmap and as just a well-suited storage mechanism for storing data for solving grid-cell formulated problems (from DEM/vector correlation, all sorts of matrix problems to cellular automata), I think the benefits of storing RASTER in the db become clear - at least for me. Granted the speed will be slower at least initially - just as when people laughed at the thought that there would be any benefit to put GIS vector data in PostgreSQL (and it was slower at least initially than querying shape files). I'm also somewhat reminded of PostgreSQL's use of bitmap index scans to do (and/or composite index searches) and a thought if any of that is at all useful to this topic. Although that is more a word connection to me than anything else since I don't know if they take into consideration run length encoding etc. that would seem to be useful for RASTER processing and storage. Thanks, Regina ---MY ORIGINAL NOTE sent offlist -- Pierre, I did take a quick glance at it and sorry I didn't comment. I was meaning too, but didn't think I had enough worthy thoughts formulated at the moment. The functions you propose look pretty cool actually and my vision of the benefits of storing raster in the database are covered in it. I like the fact that you proposed what the functions would be and how they would work. It feels almost like they are there. I'm just not sure the effort involved to achieve that. At the very least it seems that you should be able to slice RASTER data with vectors e.g. using Intersections, and I think that would be the most valuable of the functions you proposed for my particular needs at the moment. Also exporting data using SQL statements would be very useful as you stated and if we have AsTIff, AsJPEG like function in the db, there doesn't seem to be a reason I can think of why we wouldn't have the same for the vectors as well since that format is useful for those as well. Although the issues of slicing jpeg etc. storing in files slicing etc. and the performance hit of those I am unclear off. It does seem a shame that PostGIS is missing that when others have it. Thanks, Regina ----------------------------------------- The substance of this message, including any attachments, may be confidential, legally privileged and/or exempt from disclosure pursuant to Massachusetts law. It is intended solely for the addressee. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ postgis-users mailing list [email protected] http://postgis.refractions.net/mailman/listinfo/postgis-users
