I wrote the original CHIP code. It was designed to be
ultra-simple, and I'm assuming that no one's changed it in a while
(looking at the code base indicates this is true). Here's a few
notes on it:<br>
<br>
1. Right now you cannot directly index a CHIP. It has a bounding
box and an SRID, so you should be able to use the "normal" postgis
indexing code & only change a few lines. ie. look for where
the indexing code extracts a box3d (or box2d) from the GEOMETRY object
and change that one line.<br>
<br>
2. it hasnt been tested well<br>
<br>
3. its incredibly simple - just a simple header and the data<br>
<br>
4. consider saving a compressed version (I think you can get postgresql
to do this for you in the create type command). Accessing large
objects in expensive, so the decompressing overhead is probably small
compared to the cost of pulling extra pages off the disk.<br>
<br>
5. Also, consider having the header information & the actual data
in different columns. Yes, I know this is the opposite of what I
said in #1. Whenever you run a command on a TOASTed column, postgresql
will de-serialize the ENTIRE object which is very disk intensive if all
you want to know is what the image size is or what the SRID is.<br>
<br>
<br>
The entire CHIP code (lwgeom_chip.c in 1.0.x) is only a few hundred lines of code.<br>
<br>
dave<br><br><div><span class="gmail_quote">On 8/31/05, <b class="gmail_sendername">Benjamin Simon</b> <<a href="mailto:noumayoss@gmail.com">noumayoss@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Roger,<br><br>If you mean "Why use a database engine to store rasters?" then the answer is :<br><br>- Use spatial queries among tables of rasters images (i.e extracting<br>the right image when given an address or any geocoded object)
<br>- Benefit from the database storage assets ( -> security, fast access<br>with spatial indexes, backup, ...)<br>- Merge your spatial raster data with any other data you may have in<br>your database<br><br>I think one can find many good reasons for using databases, it is just
<br>a very powerfull tool for managing your data, whatever its type or<br>whatever the volume you have. You just need to have the good<br>structures inside your RDBMS to manipulate it. And that's what the<br>CHIP structure aims at.
<br><br>On the other hand, if you just mean "Why use the Postgis CHIP C<br>structure instead of redesigning a more approriate new one ?" , then<br>the answer is :<br><br>- The Postgis CHIP type is quite well optimized, there could just be
<br>minor improvments to it<br>and that's what i'm working on at the moment. If Postgis development<br>team doesn't want to modify the structure, then we might consider to<br>design a new type in PostgreSQL to store raster data or just cope with
<br>it.<br><br>I hope you've found your answer in these words.<br><br>Regards,<br>Benjamin.<br><br><br>2005/8/31, Roger <<a href="mailto:roger@sylvanascent.com">roger@sylvanascent.com</a>>:<br>> Ben,<br>> What are the advantages of using this chip scheme?
<br>><br>> Roger<br>><br>> -----Original Message-----<br>> From: <a href="mailto:gdal-dev-bounces@lists.maptools.org">gdal-dev-bounces@lists.maptools.org</a><br>> [mailto:<a href="mailto:gdal-dev-bounces@lists.maptools.org">
gdal-dev-bounces@lists.maptools.org</a>] On Behalf Of Benjamin Simon<br>> Sent: Tuesday, August 30, 2005 5:58 AM<br>> To: <a href="mailto:gdal-dev@lists.maptools.org">gdal-dev@lists.maptools.org</a><br>> Subject: [Gdal-dev] GDAL Postgis Raster Driver
<br>><br>><br>> Hi all,<br>><br>> I've been playing a bit with GDAL driver implementation and as I am quite<br>> interested in database development, I 've decided to write a Postgis wrapper<br>> for GDAL. I've used the Postgis CHIP datatype to store rasters in
<br>> PostgreSQL.<br>><br>> Basically, the driver can read files with a pixel definition of 8 or 16<br>> bits. It can deal with 1 or 4 bands (GREY_SCALE, PALETTE and RGBA). I've<br>> only tested to import PNG, BMP, JPEG and TIF files and I think the driver is
<br>> not stable yet with any other formats. The driver is supposed to be capable<br>> of dealing with projections if Postgis was built with the proj4 library.<br>><br>> I do think it could be good to move some of the functions from the GDAL
<br>> Driver source code to Postgis source. However, this would require I contact<br>> Postgis development team and I prefer to finalize the driver before, as it<br>> is really easier to test and develop.<br>>
<br>> I have contacted Frank so that this new experimental driver can soon be part<br>> of the global GDAL source tree.<br>><br>> If you can't wait unil then or if you're interested in testing, you can<br>> download the source code from this address:
<br>> <a href="http://simon.benjamin.free.fr/pgchip/">http://simon.benjamin.free.fr/pgchip/</a> and follow the installation<br>> instructions.<br>><br>> Any suggestions, comments, questions or help are welcome.
<br>><br>> Regards,<br>> Benjamin.<br>><br>> _______________________________________________<br>> Gdal-dev mailing list<br>> <a href="mailto:Gdal-dev@lists.maptools.org">Gdal-dev@lists.maptools.org</a>
<br>> <a href="http://lists.maptools.org/mailman/listinfo/gdal-dev">http://lists.maptools.org/mailman/listinfo/gdal-dev</a><br>><br>><br><br>_______________________________________________<br>Gdal-dev mailing list
<br><a href="mailto:Gdal-dev@lists.maptools.org">Gdal-dev@lists.maptools.org</a><br><a href="http://lists.maptools.org/mailman/listinfo/gdal-dev">http://lists.maptools.org/mailman/listinfo/gdal-dev</a><br></blockquote></div>
<br>