Thanks Brian,<br><br>I will give your suggestion a try.<br><br>Going back to the original post, I have made some progress with compressing the output of gdal2tiles to a kmz file. The resulting kmz file opens in Google Earth as red X's. It appears to be an issue with 7zip, because I am able to compress the same folder structure using the compression tool in Windows 7 and the kmz file opens in Google Earth as it should (and the transparency is correct). I just have posted my experience to the 7zip forum to see if that group is aware of any issues with creating kmz files using 7zip.<br>
<br>Thanks,<br>Roland<br> <br><br><div class="gmail_quote">On Wed, Feb 23, 2011 at 5:41 PM, brian <span dir="ltr"><<a href="mailto:rush@winkey.org">rush@winkey.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Roland<br>
<br>
it is probably worth your time to include another step in in your<br>
proccess<br>
<br>
run nearblack -setmask -near 0 -nb 0 -of GTiff infile -o nearblack.tif<br>
<br>
nearblack options change if the source is a white background and if the<br>
image format is lossy<br>
<br>
gdalwarp -dstalpha -t_srs "EPSG:4326 nearblack.tif warped.tif<br>
<br>
gdal_translate -of kmlsuperoverlay warped.tif final.kmz<br>
<font color="#888888"><br>
brian<br>
</font><div><div></div><div class="h5"><br>
On Tue, 2011-02-22 at 15:38 -0500, Roland Duhaime wrote:<br>
> I have been working with the png creation option under "gdal_translate<br>
> -of kmlsuperoverlay" to create kmz files that include transparency. I<br>
> haven't had much luck with controlling specific colors that becomes<br>
> transparent, or even maintaining transparency in the source HFA file.<br>
> The handling of transparency is different from gdal2tiles, where I<br>
> have had good results. This leads me back to gdal2tiles and<br>
> attempting to create a kmz file from the tile structure. The key<br>
> difference I see between the .kml files using the two different<br>
> processes is below. In order to be able to compress the gdal2tiles<br>
> output into one file, I believe that I may need to modify<br>
> gdal2tiles.py to create the gx:LatLonQuad tag from section 1 below as<br>
> opposed to the LatLonBox from section 2 below. Does anyone know the<br>
> difference between gx:LatLonQuad and LatLonBox before I decide if this<br>
> change is appropriate?:<br>
><br>
> (1) KML Superoverlay snippet:<br>
><br>
> <GroundOverlay><br>
> <drawOrder>0</drawOrder><br>
> <Icon><br>
> <href>0.png</href><br>
> </Icon><br>
> <gx:LatLonQuad><br>
> <coordinates><br>
> -74.885604, 40.373168, 0<br>
> -74.269963, 40.373582, 0<br>
> -74.267506, 41.083329, 0<br>
> -74.889723, 41.082904, 0<br>
> </coordinates><br>
> </gx:LatLonQuad><br>
> </GroundOverlay><br>
><br>
> (2)GDAL2Tiles Kml snippet:<br>
><br>
> <GroundOverlay><br>
> <drawOrder>16</drawOrder><br>
> <Icon><br>
> <href>159.png</href><br>
> </Icon><br>
> <LatLonBox><br>
> <north>40.97989806962016</north><br>
> <south>39.90973623453719</south><br>
> <east>-74.53125000000000</east><br>
> <west>-75.93750000000000</west><br>
> </LatLonBox><br>
> </GroundOverlay><br>
><br>
> Thanks Again,<br>
> Roland<br>
><br>
><br>
> On Sun, Feb 20, 2011 at 6:12 AM, Vadim Shlyakhov <<a href="mailto:vadp.devl@gmail.com">vadp.devl@gmail.com</a>><br>
> wrote:<br>
> brian <rush <at> <a href="http://winkey.org" target="_blank">winkey.org</a>> writes:<br>
><br>
> > the problem is in /12/1211/2558.kml line 26<br>
> ><br>
> > <href>2558.png</href><br>
> ><br>
> > this should be a relative path from the root of the zipfile<br>
> not from<br>
> > 2558.kml<br>
> ><br>
><br>
><br>
> Hello Brian,<br>
><br>
> I've made another tile cutter<br>
> (<a href="http://code.google.com/p/tilers-tools/" target="_blank">http://code.google.com/p/tilers-tools/</a>). It<br>
> produces a directory tree in a manner which is very similar to<br>
> gdal2tiles.py. So<br>
> I had a look into this problem.<br>
><br>
> I must say it didn't work for me either: GE shows KML just<br>
> fine, but if I zip a<br>
> dir tree into KMZ it fails altogether. I've tried relative<br>
> paths to PNGs, to<br>
> internal KMLs. All these were to no avail.<br>
><br>
> I think that the problem actually lies in '<NetworkLink>'<br>
> things and I still<br>
> cannot get a clue on these.<br>
><br>
> I wonder if you have (or can produce manually) a sample of<br>
> working KMZ with<br>
> superoverlays, so I'd be able to have a look<br>
><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> gdal-dev mailing list<br>
> <a href="mailto:gdal-dev@lists.osgeo.org">gdal-dev@lists.osgeo.org</a><br>
> <a href="http://lists.osgeo.org/mailman/listinfo/gdal-dev" target="_blank">http://lists.osgeo.org/mailman/listinfo/gdal-dev</a><br>
<br>
</div></div></blockquote></div><br>