I am in need of support for GroundOverlay loading from KML and I've been prototyping some ideas. The biggest issue is that GroundOverlays are conceptually raster data in a primarily vector format so it's unclear how OGR/GDAL should handle this. It's useful to have relational information and bounding rectangle information coming back from OGR but OGR shouldn't load the raster data, that's obviously a GDAL job.
For background, here's now GroundOverlays are specified. A GroundOverlay element has to have a LatLonBox to specify the bounding rectangle for the imagery and it also needs to have a URL specifying the source of the imagery. This can be a web url, a file url or a relative path (if it's in a KMZ). In addition, descriptive metadata and a DrawOrder can be specified. Defined behavior when an image URL isn't specified or can't be loaded is to draw a rectangle with the specified (or default) color and style information. I propose the following behavior. In OGR, the GroundOverlay is added as a polygon feature specifying the bounding box and style/draw information for the "can't load" display mode. Draw order, and URL are attached as fields as well as a field indicating this is a GroundOverlay and not a Placemark. This is enough to load and work with the bounds, etc. and the URL can be passed to GDAL for raster loading (via /vsicurl/ if necessary). This will not allow a user to pass a KML directly to GDAL and get access to the embedded images. Thoughts? ------------------ Trevor R.H. Clarke Ball Aerospace & Technologies Corp Opticks, Free Your Imagery (http://opticks.org) GPG key available on random.sks.keyserver.penguin.de This message and any enclosures are intended only for the addressee. Please notify the sender by email if you are not the intended recipient. If you are not the intended recipient, you may not use, copy, disclose, or distribute this message or its contents or enclosures to any other person and any such actions may be unlawful. Ball reserves the right to monitor and review all messages and enclosures sent to or from this email address. _______________________________________________ gdal-dev mailing list [email protected] http://lists.osgeo.org/mailman/listinfo/gdal-dev
