[gdal-dev] Re: Gdal2tiles in Gdal18 and creating KMZ files

[brian]

Roland

it is probably worth your time to include another step in in your
proccess

run nearblack -setmask -near 0 -nb 0 -of GTiff infile -o nearblack.tif

nearblack options change if the source is a white background and if the
image format is lossy

gdalwarp -dstalpha -t_srs "EPSG:4326 nearblack.tif warped.tif

gdal_translate -of kmlsuperoverlay warped.tif final.kmz

brian

On Tue, 2011-02-22 at 15:38 -0500, Roland Duhaime wrote:
> I have been working with the png creation option under "gdal_translate
> -of kmlsuperoverlay" to create kmz files that include transparency.  I
> haven't had much luck with controlling specific colors that becomes
> transparent, or even maintaining transparency in the source HFA file.
> The handling of transparency is different from gdal2tiles, where I
> have had good results.  This leads me back to gdal2tiles and
> attempting to create a kmz file from the tile structure.  The key
> difference I see between the .kml files using the two different
> processes is below.   In order to be able to compress the gdal2tiles
> output into one file, I believe that I may need to modify
> gdal2tiles.py to create the gx:LatLonQuad tag from section 1 below as
> opposed to the LatLonBox from section 2 below.  Does anyone know the
> difference between gx:LatLonQuad and LatLonBox before I decide if this
> change is appropriate?:
> 
> (1) KML Superoverlay snippet:
> 
>         <GroundOverlay>
>             <drawOrder>0</drawOrder>
>             <Icon>
>                 <href>0.png</href>
>             </Icon>
>             <gx:LatLonQuad>
>                 <coordinates>
>                     -74.885604, 40.373168, 0
>                     -74.269963, 40.373582, 0
>                     -74.267506, 41.083329, 0
>                     -74.889723, 41.082904, 0
>                 </coordinates>
>             </gx:LatLonQuad>
>         </GroundOverlay>
> 
> (2)GDAL2Tiles Kml snippet:        
>         
>         <GroundOverlay>
>           <drawOrder>16</drawOrder>
>           <Icon>
>             <href>159.png</href>
>           </Icon>
>           <LatLonBox>
>             <north>40.97989806962016</north>
>             <south>39.90973623453719</south>
>             <east>-74.53125000000000</east>
>             <west>-75.93750000000000</west>
>           </LatLonBox>
>         </GroundOverlay>
> 
> Thanks Again,
> Roland
> 
> 
> On Sun, Feb 20, 2011 at 6:12 AM, Vadim Shlyakhov <vadp.devl at gmail.com>
> wrote:
>         brian <rush <at> winkey.org> writes:
>         
>         > the problem is in /12/1211/2558.kml line 26
>         >
>         > <href>2558.png</href>
>         >
>         > this should be a relative path from the root of the zipfile
>         not from
>         > 2558.kml
>         >
>         
>         
>         Hello Brian,
>         
>         I've made another tile cutter
>         (http://code.google.com/p/tilers-tools/). It
>         produces a directory tree in a manner which is very similar to
>         gdal2tiles.py. So
>         I had a look into this problem.
>         
>         I must say it didn't work for me either: GE shows KML just
>         fine, but if I zip a
>         dir tree into KMZ it fails altogether. I've tried relative
>         paths to PNGs, to
>         internal KMLs. All these were to no avail.
>         
>         I think that the problem actually lies in '<NetworkLink>'
>         things and I still
>         cannot get a clue on these.
>         
>         I wonder if you have (or can produce manually) a sample of
>         working KMZ with
>         superoverlays, so I'd be able to have a look
>         
>         
>         _______________________________________________
>         gdal-dev mailing list
>         gdal-dev at lists.osgeo.org
>         http://lists.osgeo.org/mailman/listinfo/gdal-dev
>         
> 
> _______________________________________________
> gdal-dev mailing list
> gdal-dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/gdal-dev