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

[Roland Duhaime]

Thanks Brian,

I will give your suggestion a try.

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.

Thanks,
Roland


On Wed, Feb 23, 2011 at 5:41 PM, brian <rush at winkey.org> wrote:

> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/gdal-dev/attachments/20110223/913cdf6f/attachment-0001.html