Re: [gdal-dev] GSoC GDAL2Tiles: Opacity for Google Maps Overlay, Embedded Google Earth, Tile generation

[Lucena, Ivan]

Hi Klokan,

Would you mind if I extend your message tread a little bit?

The GDAL2Tiles is a great tool and it just getting better, congratulation.

But I have some end-user complain that they don't like to see the pixel blended when you get very close to then. Those folks really want to see the big square blocks of their images classification on top of Google Earth images. That is not your fault of course. That is a nice feature on GE, a anti-aliasing rendering technique that probably attend the general public. I have spoken with Google about that but it didn't resonate. 

As far as I can remember (from OpenGL project that I worked in the past) this problem could be easily solved with just a parameter change on the texture-surface-rendering definition. I may be wrong.

My question is, do you know if there is any way to change that behavior on GE? 

Doesn't look like you can change that option through the API as a plugin, does it? Or maybe there is something you can do on the KML.

By the way, does any one have ever received that request from users?

Best regards,

Ivan


>  -------Original Message-------
>  From: Klokan Petr Přidal <klokan at klokan.cz>
>  Subject: [gdal-dev] GSoC GDAL2Tiles: Opacity for Google Maps Overlay,	Embedded Google Earth, Tile generation
>  Sent: Aug 10 '08 09:36
>  
>  Hi folks,
>  
>  1. What did I do recently:
>  
>  - Update of the Google Maps based viewer. I designed my own Opacity
>  Control for Google Maps - so overlay has a changeable opacity on the
>  web. The HYBRID transparent labels are over the custom overlay (a lot
>  of work :-().
>  - Update of the Google Earth Plugin viewer (embedded in webbrowser),
>  so it is loading the KML SuperOverlay for tiles.
>  
>  look at: http://www.klokan.cz/projects/gdal2tiles/overlay/googlemaps.html
>  
>  - OpenLayers based viewer implementing the same functionality (the
>  opacity control is not finished yet) but the overlay is displayed on
>  top of all possible maps (and can be combined with custom WMS source).
>  OpenLayers supports now all Google Maps, Microsoft Virtual Earth Maps,
>  Yahoo Maps, OpenStreetMap and OpenAerialMap.
>  
>  look at: http://www.klokan.cz/projects/gdal2tiles/overlay/openlayers.html
>  
>  - A set of python scripts for testing of the quality of the tile
>  generation for new version of GDAL2Tiles. To choose best quality/speed
>  combination without dependency on external libraries. In the end I am
>  using gdal.AutoCreateWarpedVRT() for reprojecting the supplied raster
>  to Spherical Mercator, then requesting a window by ReadRaster(). This
>  window is stored in memory (MEM driver) and has bigger size then the
>  needed tile. The tile itself is created by scaling down this bigger
>  memory dataset to the final size by gdal.RegenerateOverview()
>  ('average' algorithm) and then by calling CreateCopy to final PNG
>  file.
>  
>  *** I hope this is the best way how to generate high-quality
>  reprojected tiles from a supplied raster. If you have some ideas
>  regarding this, please let me know...
>  
>  This approach is used only for maximal resulution tiles. The higher
>  level of the tile pyramid (overviews) are going to be done the same
>  way like gdal_retile.py do, e.g. by reading existing 4 tiles and
>  scaling down to the one with the same geographical extent. I plan to
>  use again gdal.RegenerateOverview(), but I there is a way how to do
>  that with gdal.ReprojectImage() - even for the non-georeferenced
>  rasters. When calling ReprojectImage you can choose scaling algo
>  ('bilinear','cubic','lanczos',..), but I prefer to use Overview's
>  'average' algorithm.
>  This seems to be fastest way and it guarantee the best results even on
>  the top of pyramid which are not achievable by other technique.
>  It is fastest also because the source raster can be Warped VRT.
>  
>  - I was playing with the new GDAL 1.6 (trunk) functionality for  which
>  is replacing pct2rgb.py (gdal_translate -expand rgb|rgba). When used
>  in combination with VRT driver it perfectly serves the raster files
>  which has palette inside (typically NOAA BSB, USGS, some other TIFFs).
>  
>  The code is published in my GDAL SVN sandbox.
>  
>  2. What do I plan to do next week:
>  
>  - Merge the developed functionality with gdal2tiles.py from gdal-trunk svn.
>  I plan to add parameters:
>  -s_srs 'source projection'   - for specifying a spatial reference
>  system for file which does not have it embeded
>  -zoom number|from-|-to|from-to -for selecting zoom levels (of Google
>  Maps/SphericalMercator pyramid) which will be generated from raster
>  -format 'mercator'|'geodetic'|'simple' - for selecting the tms profile of tiles
>  -forcekml will have extended functionality, as it will generate kml
>  for tiles in any projection (including Spherical Mercator) - it is not
>  cartographically correct, as you are using for example mercator raster
>  on top of Platte Carre, but it is a requested feature as then you need
>  only one set of tiles for both web viewer overlay (Google Maps like)
>  and 3D overlay (Google Earth). The cartographic shift is disapearing
>  as you are zooming closer. I think I will include some kind of
>  warning.
>  
>  - Finish the templates for gdal2tiles and use them in code of the utility.
>  
>  I guess the documentation and submitting of the new opacity controls
>  to OpenLayers trac / Google Maps API Examples will wait after
>  pencil-down deadline.
>  I plan to create a nice website about Spherical Mercator projection -
>  to explain how the tiling in Google Maps and similar services runs. It
>  will use the diagrams and graphic from my poster:
>  http://www.klokan.cz/projects/gdal2tiles/gdal2tiles-poster.pdf
>  
>  3. I blocked on:
>  
>  - OpenLayers synchronous AJAX loading of XML. Right now the generated
>  web viewers has the bounding box of raster encoded inside the
>  JavaScipt.
>  I am afraid I will not implement the loading of Metadata
>  (tilemapresource.xml) dynamically as it is hard to do (overlay will
>  appear later) and there are issues with XSS (you can't load XML from
>  another server then the html viewer is without setting up of a cgi
>  proxy)
>  
>  Klokan
>  _______________________________________________
>  gdal-dev mailing list
>  gdal-dev at lists.osgeo.org
>  http://lists.osgeo.org/mailman/listinfo/gdal-dev
>