[postgis-users] Raster Support...

[Josh@oklieb]

Hi,

Interesting discussion and there are, I think, some valuable use  
cases for PostRaster, just not every use case. My impression from  
this discussion and some experience is that:

1)  if you want to store and retrieve large raster imagery for  
display, use a pyramid (-ish) scheme in the filesystem (e.g. JPEG2000).

2) If you want to analyze attributes of raster tiles, such as  
provenance or lineage, use a PostGIS index to filesystem tiles.

3) If you want to analyze raster cells, then it starts to be  
interesting to store them directly in the database.

A challenge with that storage is that the vector algorithms work with  
points, but point collections are a hugely inefficient way of storing  
a raster. On the other hand, the converse of Paul's observation below  
is that spatial indexes are already rasters stored in a database.  
Just point them at "features" with no explicit geometry, only cell  
attributes. This may not, of course, be very efficient for particular  
tasks at the cell-size of most raster imagery. One way to look at  
efficient storage of rasters might then be to treat them as nested  
spatial indexes, which is probably not far off of many commercial  
grid processing systems, especially the ones which avoid loading  
multiple entire rasters into memory for every processing task.

Cheers,

Josh

On Aug 25, 2006, at 5:26 PM, Paul Ramsey wrote:

> Rasters are already indexed, they are perfectly regular grids.  Any  
> binary on-disk format will allow you to dereference a value or set  
> of values from the raster without any searching or scanning or  
> loading into memory required.
>
> Now, raster-in-the-database would allow SQL access to the contents  
> of a raster, which some developers may find handy, since it  
> abstracts away the development details necessary to, for example,  
> use the Python/GDAL scripting interface to read values directly out  
> of rasters.  Again, as an integration environment, there are some  
> positive aspects available: learn one language (SQL), get a whole  
> pile of analytical and data access tools in exchange.
>
> P.
>
> On 25-Aug-06, at 1:28 PM, Alan wrote:
>
>>
>> Hi all,
>> New guy, first post - not much PostGIS experience but a lot of  
>> interest and
>> a lot of Arc(insertModuleNameHere) experience.
>>
>> Raster is not just a format - it is, in effect, a GEOMETRY TYPE  
>> that models
>> "chunks" of a surface very effectively and efficiently.
>>
>> What's "data-basey" about it? In a word: "indexing". Why should I  
>> have to
>> load a 3GB file into my GDI just to query a couple of hundred pixels
>> surrounding a particular vector? (If my base heights com from a  
>> DEM or TIN
>> or, (insert name of significant deity) forbid, a point cloud, and  
>> I have
>> building footprints with roof elevations I don't want to load the  
>> whole
>> raster to get a Building Height-Above-Ground.
>>
>> What if all I wanted was just to access a "value" at one particular
>> location? What if I didn't want to "see" the raster, just use its  
>> "data"?
>>
>> Also, I work in the Emergency Services / Homeland Security area  
>> and pictures
>> (as well as all kinds of other rasters) are a BIG TIME requirement so
>> management and relationships to other features becomes critical.
>>
>> The other thing I've realised over the years that every vector  
>> becomes a
>> raster before we can see it (either on the screen or on paper).  
>> Since GIS
>> has (at least) two parts - Analysis & Visualisation - getting  
>> control of the
>> raster can only be a good thing.
>>
>> Cheers
>> AlanK
>>
>>
>> -----Original Message-----
>> From: postgis-users-bounces at postgis.refractions.net
>> [mailto:postgis-users-bounces at postgis.refractions.net] On Behalf  
>> Of Paul
>> Ramsey
>> Sent: Saturday, 26 August 2006 6:06 AM
>> To: PostGIS Users Discussion
>> Subject: Re: [postgis-users] Raster Support...
>>
>>
>> Indeed, that was exactly my intent.  To get some answers!  I
>> personally have had one use-case recently, which is similar to
>> Stephen Marshall's point (1), moving some vector information into
>> raster space, doing some analysis which is best done in raster space,
>> then pulling results back into vector space.
>>
>> There is nothing particularly "database"y about the use case (we
>> utilize the features of the database itself hardly at all), but
>> having the rasters in the database avoids an unpleasant bunch of
>> scripting to dump data out to GRASS, run the analysis, stuff the
>> results back in.  The database becomes an analysis integration
>> environment.  There are lots of good arguments around that using a
>> scripting environment like Python would be a better integration
>> architecture though.
>>
>> I still haven't found any raster use cases that actually leverage the
>> unique aspects of the database environment (high speed random access
>> to tuples, transactional integrity, complex data models).
>>
>> Paul
>>
>> On 25-Aug-06, at 12:58 PM, Stephen Woodbridge wrote:
>>
>>> Jeff Hoffmann wrote:
>>>> Paul Ramsey wrote:
>>>>> To repeat:  once you get your rasters in the database, what are
>>>>> you  going to do with them?
>>>
>>> Jeff,
>>>
>>> I think there are two ways to look at this statement. One is it
>>> might be a dismissal, but I think the one that Paul is asking for
>>> is What are your use cases, so he can collect them as you suggest.
>>> It has been REALLY hard to get anyone to come forward with there
>>> specific needs in this area, beside just asking for the feature.
>>>
>>> -Steve
>>>
>>>> I used to have that same question the same time anybody the topic
>>>> got brought up.  I think that, if you try, you can come up with
>>>> some ways raster data might be useful integrated into the database
>>>> (even if it's not the best or only way of doing something).
>>>> Perhaps too many people think of raster data as essentially
>>>> photographic and not as a giant array of geo-referenced data
>>>> points and they just dismiss it out of hand.  If you're just
>>>> storing a bunch of photos in your database, I agree with the
>>>> sentiment that it just makes your life difficult.  If, on the
>>>> other hand, you have a DEM (for example) where the data points are
>>>> elevation, you could query it to find the elevation at a point.
>>>> Or take it a step further and add a Z coordinate to all that 2-D
>>>> vector data in case you ever want to visualize it in 3-D.
>>>> I guess the first thing I'd do if I were that interested in adding
>>>> raster support is collect a bunch of possible use cases and
>>>> categorize them to figure out what sort of functionality people
>>>> would be interested in seeing.  I think it'd be interesting to see
>>>> what people would use it for & maybe would inspire some interest
>>>> in the wider community.
>>>
>>> _______________________________________________
>>> postgis-users mailing list
>>> postgis-users at postgis.refractions.net
>>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>>
>>
>>
>> _______________________________________________
>> postgis-users mailing list
>> postgis-users at postgis.refractions.net
>> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users