[postgis-users] PostGIS WKT Raster

[Pierre Racine]

Nice to ear from you Paul. I still wear this PostGIS t-shirt you gave me
in Ottawa...

>- You propose to do this because their is a "great demand for it", but
>the great demand is generally the stupid demand for images-in-database
>"just because". You must either somehow *stop* those people, or ensure
>your solution is capable of meeting their needs.  Since you propose to
>meet the demand, presumably you aim for the latter.  This *will*
>involve a good deal of non-analytical pre-processing infrastructure to
>convert people's multi-resolution, overlapping/underlapping file
>libraries into a uniform resolution coverage.  I suggest you ignore
>these people.

I understand the reticences to just put raster in the database but I
think they could apply to vector in the database also. Why would I store
vectors in the database (fool!). Why not just storing them as
shapefiles?

-Because databases are fast at removing what we don't need (to read, to
query, to edit) and because we don't want to reimplement/reinvent
indexing for every application. This is true for raster also.
-Because we need a common warehouse to store everything we have in a
common paradigm (SQL): attribute, vecter, raster, etc... The database is
still the better paradigm to query/edit data. A raster IS a database.
It's just a stupid database. This is why its fast to do stupid things
like only reading it. Not analysing it... I think a many raster/vector
analysis operations will gain in speed being done in the database
paradigm.

I have no doubts that with a good API people with find great
applications as they did with vector in the DB.

I won't do anything to convert overlaping rasters into a clean mosaic.
You have to clean/assemble your data before getting them into the
database as with vector. The results of your queries are as good as the
data you put in the DB.

>- You are going to carry a certain amount of information into the
>database and process data into bands, potentially for external
>storage.  Why not store external data in a format like TIFF that can
>hold all the bands and pyramids, etc?

You mean when raster are just referenced? There will be two supported
formats: TIFF and JPEG (the latter without support for pyramids).
You mean for raster in the database? I'm still puzzled by the options:
-storing the raster as a new WKT/WKB,
-as GeoTIFF 
-or having just the raster part of WKB as GeoTIFF (this would mean
duplicating lots of info) (or JPEG).

I don't see the advantages of storing as GeoTIFF (other than being able
to reuse the TIFF library) since what most people want as output is
agregated JPEG and storing as a lossy JPEG is not really an option. I'm
scared that people would try to store GeoTIFF with features my code
won't be able to deal with... I prefer a clean, minimalistic new WKT/WKB
format over which I have full control. I could rewrite a source TIFF as
a minimal TIFF in the DB. Hum... Maybe. Give me more advantages for
GeoTIFF in the DB...

>- If you step back a bit and don't even bother splitting up the
>rasters into tiles, you can use an existing raster access library like
>GDAL to work with serialized data.

Users have the choice of splitting their raster or not. Splitting (which
is synonym of indexing in my head) have the advantage of speeding up
raster/vertor operations since most operation do not involve most tiles.

>- I like your external storage idea. What are the implications for
>CREATE TABLE foo AS SELECT...?

You are creating rasters IN the database from rasters OUTSIDE of the DB.
This is the kind of query you don't necessarily want to do, like many.
You would better create a view.

>Summary: your proposal is better than any I have seen, addresses
>solving problems that if solved will provide actual new functionality
>and benefit to users, and clearly you've thought this through over
>some time.
>
>So, I look forward to seeing your initial plan of attack for 
>development :)

See slide  44.

Thanks Paul. Now that I have your blessing, I should start to work on
this next fall :-) If you know some other developers seriously
interested by this, let me know.

Pierre