[postgis-users] RE: PostGIS WKT Raster

[Obe, Regina]

>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.