Just to mention that I did try the gdal driver for PGRaster and it is
working. I can't tell the speed, and like mentionnend Simon it depends of
many things. But I did succeed to render (query and write to disk as an
gdal_translate in the latest release version.
Post by Paragon CorporationSunny,
The first (1) is to just register the raster as out-of db raster. Only the
georeferences of each tile/raster is stored in the database along with the
path to the raster itself in the filesystem (you can add any other attribute
as additional columns). PostGIS raster in this case act like a quick SQL
raster catalog. Actual raster data (pixel values) are not stored in the
database. They are store as JPEG or TIFF in the filesystem. It is up to the
application to fetch them where they are. In this case their should be no
performance lost comparing with any existing raster server solution storing
raster coverage in the filesystem. This options still need
testing/improvement. For example, the loader (raster2pgsql.py) is not able,
right now, to split big raster into multiple JPEG tiles when you use the k
option. It does it only when you store the tiles in-db.
The second (2) option is to store everything in the DB. The raster is then
stored in the PostGIS raster format and need to be converted to JPEG before
being sent to web client (desktop applications do not have to rely on this
conversion as can implement native support for the PostGIS raster WKB format
or rely on GDAL). There are two ways to convert PostGIS raster to JPEG or
whatever: the first one (2.1) is to rely on the PostGIS raster GDAL driver
used by the application (this is how we got almost free support in
MapServer). The second one (2.2) is to ask the database to convert PostGIS
rasters to JPEG or whatever format with SQL functions like ST_AsJPEG(rast)
or ST_AsTIFF(rast) so that the application receive a JPEG or TIFF binary
stream. These function are planned but not yet implemented. This option
should be a bit slower than the first as raster are converted on the fly.
Option (1), storing out-of-db, targets applications needing VERY faster
retrieval not requering raster edit or analysis and not implemented to read
native PostGIS or GDAL raster.
Option (2), in-db storage, targets applications needing raster edit or
analysis and able to read native PostGIS or GDAL raster.
Options 1 and 2.2 assume that raster tiles can be sent to the web
application without having to be blended with other layers. Application
(like MapServer) that has to read and blend rasters with other layers before
sending them should rely on 2.1 (GDAL). I think this last option has the
better future. It is however not very well tested right now and the GDAL
driver just got reimplemented in december. We might have to tweak it at some
point to get the kind of performance expected by web applications.
I suggest you give a try to MapServer (Regina & Leo explain how to
configure it in PostGIS in Action) and, if it is not fast enough, see with
Jorge what we can do.
To answer your other questions: raster loading in PostGIS raster is quite
fast even if it still need improvement like not passing through a large
intermediate SQL file.
Could you elaborate a bit more on the multiband issue? Im not very
familiar with tile caching tech anymore.
Pierre
*Sent:* 29 janvier 2011 21:25
*To:* PostGIS Users Discussion
*Subject:* Re: [postgis-users] PostGIS Raster Performance
Hi Regina,
Thanks for the lead on this.
It opens up the light and the room for discussion. Well, as far as I know,
Oracle Georaster is not good for serving purpose and on top of it, that
takes awful amount of time to load the data into Oracle. I assume that its
not the case with PG Raster.
The other issue is, even if one dont want to do store the multiband (say 8
band) imagery into the PG Raster for the Speed issue, can we target to link
up the Cache into this? If GWC or Tile Cache jpg/png tiles can be kept here
and then publish... it will be nice. Again, the issue will be speed ... or
some may argue the fact the it defeats the purpose of Cache which is suppose
to be non "ram" required serving.
my only wish, that one day we should be able to easily load the images into
PG Raster and publish into a web application and get a performance/speed as
good as any image servers.
btw, it was a news to me that GeoServer dont support PG Raster yet... I
hope they are working on it now...
Thank you;
Sunny
Sunny,
Good question. I suspect it will be worse at least at the moment (just as
PostGIS was worse when it first came out than reading from shapefile). How
much worse I'm not sure. If you try and see speed issues, we can tackle
them, but it hasn't really been our main focus.
I suspect no one has tested it extensively as far as dishing out large
datasets. The primary focus of PostGIS Raster is for analysis and then
secondary is the rendering. That is not to say it will work badly or we
don't care about rendering speed, just that the GDAL drivers etc. needed by
Mapserver probably still have a few wrinkles which would make it suboptimal
for that kind of work. The more people use it and find issues, the faster
issues will be addressed since we would have data points to go by.
As far as GeoServer goes, I recall reading a thread where Chris Holmes said
he would work on a PostGIS Raster support for GeoServer, but not sure where
that is down the pipe, but to my knowledge, GeoServer does not YET support
PostGIS raster.
Hope that helps,
Regina
------------------------------
*Sent:* Saturday, January 29, 2011 3:44 AM
*Subject:* [postgis-users] PostGIS Raster Performance
List,
Can anyone comment on the "Performance" of the PostGIS Rater or WKTRaster ?
If you were to serve this onto a web application, how effective are they?
Well, I'm talking of very large datasets like 10GB each and 100 of them. How
does it compare with serving the images as files directly.. from a GeoTIFF,
ECW, Sid, etc. (obviously using Geoserver/Mapserver or some specialized
image serving solution)
Been searching all over the web for the answers, but no luck.
Hope to get some insights from the users.
Thank you;
Sunny.
_______________________________________________
postgis-users mailing list
http://postgis.refractions.net/mailman/listinfo/postgis-users
_______________________________________________
postgis-users mailing list
http://postgis.refractions.net/mailman/listinfo/postgis-users