[postgis-users] PostGIS WKT Raster

[muhammad imran]

Pierre, your ideas are extremly valuable and is the ultimate requirement from today image mining applications from the world of remote sensing and GIS as if databases really want to provide the raster/vector support. The raster support inside or outside is I think no more discussion topIc in the world of serious implementers from the properietry or open source realm.  They clearly separate the functions or libraries from the storage model and look the evry grided data as raster whether it is seriers of images or single coverage or single tile , whether it is on the file system (external file to database) or inside the database. I think rather going into this fruitless discussion we should really put effort to your proposed raster and vector integration this will lead us to real analyses support from the spatial databases for which these are lagging behind which is beyond the merely raster support.
-- imran


----- Original Message ----
From: Pierre Racine <Pierre.Racine at sbf.ulaval.ca>
To: PostGIS Users Discussion <postgis-users at postgis.refractions.net>
Sent: Tuesday, July 15, 2008 12:00:10 AM
Subject: RE: [postgis-users] PostGIS WKT Raster

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

_______________________________________________
postgis-users mailing list
postgis-users at postgis.refractions.net
http://postgis.refractions.net/mailman/listinfo/postgis-users