Frank,<br><br>I agree that the GeoQuadTree GDAL driver should be under the MIT/X license used in the rest of the project.<br><br>At
first I included the CRS definition in the same XML metadata file, but
later I thought it would be more useful as a separate file, with .prj
extension. This CRS file IS the definition in Well Known Text format,
as is returned from PROJ.4 library. Do you think it would be better to
include it in the same XML metadata file ?<br><br>I've
started working on including the choice for JPEG, JPEG2000 or TIFF as
alternatives to PNG for the format of the tiles. I would like also to
support multi-bands with TIFF or with multiple PNGs/JPGs.
<br><br>You are absolutely right that sacrificing a RGB color for nondata is not a good idea in JPEG.<br><br>I
don't know if I understand what you mean about a "standard tile cache".
I'm sorry that I didn't study enough the GDAL core, and I didn't know
about the block cache. I'll try to use it: I implemented my own tile
cache, but only as a consequence of my ignorance in GDAL internals.
<br><br>I will include some information on the web about who did the work and why, as you suggest.<br><br>Best regards,<br><br>Jordi<br><br><br><div><span class="gmail_quote">On 11/15/06, <b class="gmail_sendername">Frank Warmerdam
</b> <<a href="mailto:warmerdam@pobox.com">warmerdam@pobox.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;">Jordi Gilabert Vall wrote:
<br>> I only wanted a lossless compression, so I chose PNG format for tiles,<br>> but many people also wants a lossless compression, so I'm going to<br>> support two types of compression, PNG and maybe JPEG or JPEG2000. I like
<br>> the PNG format because with 4-bands PNGs (RGBA), the alpha channel<br>> allows me to store non-data pixels. With JPEG format, I would<br>> "sacrifice" a RGB color to represent non-data values. There is also the
<br>> need of supporting multi-band images, this could be accomplished with as<br>> many PNGs as bands. These are small changes, I will try to make it on<br>> the next release.<br>><br>> On the other side, I think storage space is not the big problem
<br>> nowadays. I prefer more efficient algorithms in terms of CPU usage, than<br>> efficient in terms of storage space. If someone prefer the reduction of<br>> storage space, the wavelet compression approach could be preferred
<br>> (LizardTech's MrSID, ER Mapper's...). I want the freedom to choose a<br>> simpler, efficient an FREE approach.<br>><br>> GeoQuadTree handles a pyramid of overviews. When you create a<br>> GeoQuadTree image, you specifiy the number of levels in the pyramid.
<br>> Every time you import a image into a GeoQuadTree, the utility builds the<br>> pyramid of overviews (only updates the tiles affected upside in the<br>> pyramid).<br><br>Jordi,<br><br>I would be interested in incorporating your geoquadtree gdal driver into
<br>the mainline GDAL source tree, but I see that it is licensed under the GPL.<br>In the interest of simplicity of licensing I prefer to keep all the core<br>GDAL source tree to the MIT/X license already used. So, unless you are
<br>interested in licensing the driver in a GDAL compatible form, I think it<br>will need to stay as a plugin.<br><br>I would like to see the XML metadata file for geoquadtree format include<br>a coordinate system element with the coordinate system in Well Known Text
<br>format. An alternative might be in anything supported for SRS names in the<br>OGC WxS specifications (such like EPSG:4326 or the OGC URN specifications).<br><br>I also would like to see some flexibility in the format of the tiles. At
<br>the very least png, and jpeg. JPEG2000, and TIFF might also be desirable.<br>TIFF I mention because of the flexibility of pixel data types, and<br>multispectral support. Of course TIFF is a bit heavy for very small tiles.
<br><br>You mentioned above about having to sacrifice an RGB color for a nodata<br>marker with jpeg format, but this doesn't really work because jpeg is so<br>lossy. So it is essentially impossible to use nodata values with jpeg.
<br><br>Overall I would have preferred to see a GeoQuadTree format that was also<br>a valid instance of the url view of a "standard tile cache" per all the<br>"tile cache standard" work being done by various folks. That would be
<br>super-cool, but perhaps not a high priority for you.<br><br>PS. A very nice professional job on the <a href="http://geoquadtree.org">geoquadtree.org</a> web site. But it<br>lacks in ... humanity. Perhaps an FAQ on who did the work and why?
<br><br>Best regards,<br>--<br>---------------------------------------+--------------------------------------<br>I set the clouds in motion - turn up | Frank Warmerdam, <a href="mailto:warmerdam@pobox.com">warmerdam@pobox.com
</a><br>light and sound - activate the windows | <a href="http://pobox.com/~warmerdam">http://pobox.com/~warmerdam</a><br>and watch the world go round - Rush | President OSGeo, <a href="http://osgeo.org">http://osgeo.org
</a><br><br></blockquote></div><br>