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

[Jordi Gilabert Vall]

Frank,

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
interesting.

Best regards,

Jordi



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