[postgis-users] design comments

[Paul Ramsey]

Pivoting a raster coverage into a table of points is an unbelievably
bad idea. Don't do it.  To the extent that the wktraster project
starts to output some raster *processing* tools that lay on top of the
storage abstraction, it will become useful for you.  In the meanwhile,
there is no reason you should have to read several files into memory
to read raster data out, as long as your files are well organized. You
should be able to read directly out of, for example, uncompressed TIFF
files, without loading any extra data into memory. You can even
compress them, if you use an internal tiling schema, to get both fast
access and smaller size.

P.

On Wed, Feb 11, 2009 at 2:17 PM, Theller, Lawrence O.
<theller at purdue.edu> wrote:
> HI from excited new user; the raster discussion really piques my interest.
> Would welcome some design comments.
>
> We now have an online model that reads large collection (1 TB) of raster
> files, queries an oracle DB (tabular not spatial) does some manipulations
> and presents results with Mapserver.  User interface starts and stops with
> Mapserver with display of 5 states worth of GIS files I manage; like to get
> out of that business by going to Google Maps.
>
> I have designed a  grand replacement strategy from reading web pages and I
> now realize perhaps I need some feedback from experienced users. My hope is
> to convert the raster files into xyz point data stored in postgresql –
> stored in large watershed subsets of a state as a table of points indexed by
> small watersheds among other things, with 5 to 10 attributes per point. A
> typical (8 digit watershed) table then would be maybe 52 million points with
> 15 attributes.  A state would have dozens of this size table. We would
> present the user with Google Maps interface, they draw a box which passes to
> us, we do spatial query to find which watershed they are in and read and
> spatial query the appropriate table of points with attributes,  and
> manipulate.
>
> I hope this is faster than current method which is to find appropriate 5
> physical raster files, 50 Megabytes each, say; read them into memory and
> then query out appropriate subarea and manipulate, results now include
> create both ascii raster and xy generate file, and then a shapefile This
> output process I would replace with just KML output (points with changed
> attributes get output)
>
>  So the real question is will the database efficiently handle spatial query
> into 52 million well-indexed points, or should I stick with reading raster
> layer upon layer? BTW these are categorical and not image rasters, for
> example soil type and landcover type with derivatives. Not .tifs either at
> this point, we use a homebrew binary we make from ESRI raster. Query will be
> a (KML/GML) polygon generally.
>
> Any thoughts are welcome.
>
>
>
> Regards,
>
> Larry Theller
>
> Ag and Bio Engineering
>
> Purdue University
>
> LTHIA model: http://cobweb.ecn.purdue.edu/~watergen/owls/htmls/reg5.htm
> select a state
>
> _______________________________________________
> postgis-users mailing list
> postgis-users at postgis.refractions.net
> http://postgis.refractions.net/mailman/listinfo/postgis-users
>
>