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

Jordi Gilabert Vall jordi at geoquadtree.org
Wed Nov 15 12:57:10 EST 2006


Sorry for the mistake, the Well Known Text format I write on the CRS
definition file comes from the OSRExportToWkt function, in OGR, not in
PROJ.4. I agree that WKT is the best option, as it is not software specific.

I will read about tile caching proposals, as you suggest, it sounds

Best regards,


2006/11/15, Frank Warmerdam <warmerdam at pobox.com>:
> Jordi wrote:
> > Frank,
> >
> > I agree that the GeoQuadTree GDAL driver should be under the MIT/X
> > license used in the rest of the project.
> Jordi,
> Ah, cool.  Then inclusion should be no problem.  Lets make sure it
> makes it in before 1.4.0 release.
> > 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 ?
> Ah.  I just read the FAQ entry on the format, which I don't think
> mentions the CRS file.  A seperate .prj file with the wkt coordinate
> system
> should be fine.
> You say "in Well Known Text format, as returned from PROJ.4 library".
> The well known text format is not used or produced by the PROJ.4 library
> so either you are really using PROJ.4 definitions (not WKT) or you really
> mean as returned by OGRSpatialReference.
> WKT usually starts with PROJCS or GEOGCS while PROJ.4 strings include
> something like +proj=.
> I think we should be using WKT as it is not so software specific.
> > 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.
> cool
> > 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.
> This isn't a GDAL thing at all.  Various web obsessed folks from projects
> like OpenLayers, ka-map, and others have been trying to hash out a
> standard
> approach to web accessable tile caches such as those used by Google maps,
> and WorldWind.  So that web tile caches could be shared more effectively
> by different software packages.  I think the following urls capture some
> of that planning/discussion/thinking though I haven't been following it
> closely myself.
>    http://wiki.osgeo.org/index.php/WMS_Tile_Caching
>    http://wiki.osgeo.org/index.php/Distributed_Tile_Caching
>    http://wiki.osgeo.org/index.php/Tile_Map_Service_Specification
> My thinking is that if they hammer this out it would be nice if the
> geoquadtree cache format sitting on a web server would adhere to their
> specification making it directly usable.  I don't know enough about this
> to be sure if this is reasonable or not.
> 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<http://pobox.com/%7Ewarmerdam>
> 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/81da01ba/attachment.html

More information about the Gdal-dev mailing list