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.d...@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@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev > > > _______________________________________________ > gdal-dev mailing list > gdal-dev@lists.osgeo.org > http://lists.osgeo.org/mailman/listinfo/gdal-dev _______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/gdal-dev
