[Gdal-dev] GeoQuadTree - an open format for storinggeoreferencedimages

Jordi Gilabert Vall jordi at geoquadtree.org
Wed Nov 15 12:00:50 EST 2006


Frank,

I agree that the GeoQuadTree GDAL driver should be under the MIT/X license
used in the rest of the project.

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 ?

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.

You are absolutely right that sacrificing a RGB color for nondata is not a
good idea in JPEG.

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.

I will include some information on the web about who did the work and why,
as you suggest.

Best regards,

Jordi


On 11/15/06, Frank Warmerdam <warmerdam at pobox.com> wrote:
>
> Jordi Gilabert Vall wrote:
> > I only wanted a lossless compression, so I chose PNG format for tiles,
> > but many people also wants a lossless compression, so I'm going to
> > support two types of compression, PNG and maybe JPEG or JPEG2000. I like
> > the PNG format because with 4-bands PNGs (RGBA), the alpha channel
> > allows me to store non-data pixels. With JPEG format, I would
> > "sacrifice" a RGB color to represent non-data values. There is also the
> > need of supporting multi-band images, this could be accomplished with as
> > many PNGs as bands. These are small changes, I will try to make it on
> > the next release.
> >
> > On the other side, I think storage space is not the big problem
> > nowadays. I prefer more efficient algorithms in terms of CPU usage, than
> > efficient in terms of storage space. If someone prefer the reduction of
> > storage space, the wavelet compression approach could be preferred
> > (LizardTech's MrSID, ER Mapper's...). I want the freedom to choose a
> > simpler, efficient an FREE approach.
> >
> > GeoQuadTree handles a pyramid of overviews. When you create a
> > GeoQuadTree image, you specifiy the number of levels in the pyramid.
> > Every time you import a image into a GeoQuadTree, the utility builds the
> > pyramid of overviews (only updates the tiles affected upside in the
> > pyramid).
>
> Jordi,
>
> I would be interested in incorporating your geoquadtree gdal driver into
> the mainline GDAL source tree, but I see that it is licensed under the
> GPL.
> In the interest of simplicity of licensing I prefer to keep all the core
> GDAL source tree to the MIT/X license already used.  So, unless you are
> interested in licensing the driver in a GDAL compatible form, I think it
> will need to stay as a plugin.
>
> I would like to see the XML metadata file for geoquadtree format include
> a coordinate system element with the coordinate system in Well Known Text
> format.  An alternative might be in anything supported for SRS names in
> the
> OGC WxS specifications (such like EPSG:4326 or the OGC URN
> specifications).
>
> I also would like to see some flexibility in the format of the tiles.  At
> the very least png, and jpeg.  JPEG2000, and TIFF might also be desirable.
> TIFF I mention because of the flexibility of pixel data types, and
> multispectral support.  Of course TIFF is a bit heavy for very small
> tiles.
>
> You mentioned above about having to sacrifice an RGB color for a nodata
> marker with jpeg format, but this doesn't really work because jpeg is so
> lossy.  So it is essentially impossible to use nodata values with jpeg.
>
> Overall I would have preferred to see a GeoQuadTree format that was also
> a valid instance of the url view of a "standard tile cache" per all the
> "tile cache standard" work being done by various folks.  That would be
> super-cool, but perhaps not a high priority for you.
>
> PS. A very nice professional job on the geoquadtree.org web site.  But it
> lacks in ... humanity.  Perhaps an FAQ on who did the work and why?
>
> Best regards,
> --
>
> ---------------------------------------+--------------------------------------
> I set the clouds in motion - turn up   | Frank Warmerdam,
> warmerdam at pobox.com
> light and sound - activate the windows | http://pobox.com/~warmerdam
> and watch the world go round - Rush    | President OSGeo, http://osgeo.org
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20061115/b2baa86c/attachment.html


More information about the Gdal-dev mailing list