[postgis-users] PostGIS WKT Raster

Mon Jul 14 13:08:58 PDT 2008

On Mon, Jul 14, 2008 at 12:43 PM, Pierre Racine
<Pierre.Racine at sbf.ulaval.ca> wrote:
> Paul Ramsey hasn't yet said my design was:
>
> -a "meme" (http://blog.cleverelephant.ca/2008/06/x-my-l.html),
> -a "waste of time" (http://postgis.refractions.net/pipermail/postgis-devel/2007-July/002653.html)
> -"useless" (http://postgis.refractions.net/pipermail/postgis-users/2007-May/015578.html)
> -that it was "pointless" (http://postgis.refractions.net/pipermail/postgis-users/2007-October/017250.html)
> -or that I was a "fool" (http://postgis.refractions.net/pipermail/postgis-users/2007-October/017239.html)
>
> So I conclude it's a good design!!! :-)
>
> He asked for a good design some time ago for raster in the database (http://postgis.refractions.net/pipermail/postgis-users/2006-October/013628.html)
>
> Where is the clever elephant?
>
> Pierre

Not sure where Paul is lurking these days, but I wanted to throw out
the name of an application that can already do half of what Pierre is
looking for: StarSpan.

http://starspan.casil.ucdavis.edu/doku/doku.php

This is the tool I use when ever I need to fuse raster with vector
data. Since it can use GDAL/OGR datatypes, it is possible to run
against PostGIS data directly. I commonly use it to cross postgis data
with rasters stored in GRASS.

Cheers,

Dylan

>
>>-----Message d'origine-----
>>De : postgis-users-bounces at postgis.refractions.net
>>[mailto:postgis-users-bounces at postgis.refractions.net] De la
>>part de Pierre Racine
>>Envoyé : 7 juillet 2008 11:30
>>À : postgis-users at postgis.refractions.net
>>Cc : warmerdam at pobox.com; nicolas.gignac at msp.gouv.qc.ca;
>>smarshall at wsi.com
>>Objet : [postgis-users] PostGIS WKT Raster
>>
>>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-De
>>cember/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
>>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
>