The LIBKML driver is a client of Libkml from Google, a reference implementation of KML reading and writing, in the form of a cross platform C++ library. You must build and install Libkml in order to use this OGR driver. Note: you need to build libkml from its latest SVN version (libkml 1.2 isn't enough).
Note that if you build and include this LIBKML driver, it will become the default reader of KML for ogr, overriding the previous KML driver . You can still specify either KML or LIBKML as the output driver via the command line
Libkml from Google provides reading services for any valid KML file. However, please be advised that some KML facilities do not map into the Simple Features specification OGR uses as its internal structure. Therefore, a best effort will be made by the driver to understand the content of a KML file read by libkml into ogr, but your mileage may vary. Please try a few KML files as samples to get a sense of what is understood. In particular, nesting of feature sets more than one deep will be flattened to support ogr's internal format.
You may specify a
datasource
as a kml file somefile.kml ,
a directory somedir/ , or a kmz file somefile.kmz .
By default on directory and kmz datasources, an index file of all the layers will be read from or written to doc.kml. It contains a <NetworkLink> to each layer file in the datasource. This feature can be turned off by setting the environment variable LIBKML_USE_DOC.KML to "no"
Datasource style tables are written to the <Document> in a .kml, style/style.kml in a kmz file, or style.kml in a directory, as one or more <Style> elements. Not all of OGR Feature Style can translate into KML.
Starting with OGR 1.11, the following datasource creation options can be used to generate a <atom:Author> element at the top Document level.
The href of an <atom:link> element at the top Document level can be specified with the LINK creation option.
The <phoneNumber> element at the top Document level can be specified with the PHONENUMBER creation option. The value must follow the syntax of IETF RFC 3966.
Starting with GDAL 2.2, the DOCUMENT_ID datasource creation option can be used to specified the id of the root <Document> node. The default value is root_doc.
The following dataset creation options can be used to set container options :
The following dataset creation options can be used to control how the main folder (folder of layers) appear in the Places panel of the Earth browser, trough a <ListStyle> element:
If a style foo is defined, it is possible to add a <BalloonStyle> element to it, by specifying the foo_BALLOONSTYLE_BGCOLOR and/or foo_BALLOONSTYLE_TEXT elements.
A <NetworkLinkControl> element can be defined if at least one of the following dataset creation option is specified:
When defining the dataset creation option UPDATE_TARGETHREF, a NetworkLinkControl KML file with an <Update> element will be generated. See the tutorial about update.
The CreateFeature() operation on a layer will be translated as a <Create> element.
The SetFeature() operation on a layer will be translated as a <Change> element.
The DeleteFeature() operation on a layer will be translated as a <Delete> element.
Layers are mapped to kml files as a <Document> or <Folder>, and in kmz files or directories as a separate kml file.
Layer style tables can not be read from or written to a kml layer that is a <Folder>, otherwise they are in the <Document> that is the layer.
Read and write of <Schema> is supported for .kml files, .kmz files, and directories.
Starting with OGR 1.11, the following layer creation options can be used to generate a <LookAt> element at the layer level.
Alternatively, a <Camera> element can be generated.
A <Region> element can be generated to control when objects of the layer are visible or not. If REGION_XMIN, REGION_YMIN, REGION_XMAX and REGION_YMAX, the region coordinates are determined from the spatial extent of the features being written in the layer.
A <ScreenOverlay> element can be added to display a logo, a legend, etc...
By default, layers are written as <Document> elements. By settings the FOLDER layer creation option to YES, it is also possible to write them as <Folder> elements (only in .kml files).
The following layer creation options can be used to set container options :
The following layer creation options can be used to control how the folder of a layer appear in the Places panel of the Earth browser, trough a <ListStyle> element:
An OGR feature generally translates to kml as a <Placemark>, and vice-versa.
If the model field is defined, a <Model> object within the Placemark will be generated.
If the networklink field is defined, a <NetworkLink> will be generated. Other networklink fields are optional.
If the photooverlay field is defined, a <PhotoOverlay> will be generated (provided that the camera_longitude, camera_latitude, camera_altitude, camera_altitudemode, head and/or tilt and/or roll, leftfov, rightfov, bottomfov, topfov, near fields are also set. The shape field is optional.
In case the PhotoOverlay is a big image, it is highly recommended to tile it and generate overview levels, as explained in the PhotoOverlay tutorial. In which case, the URL should contain the "$[level]", "$[x]" and "$[y]" sub-strings in the photooverlay field, and the imagepyramid_tilesize, imagepyramid_maxwidth, imagepyramid_maxheight and imagepyramid_gridorigin fields should be set.
Placemark, Model, NetworkLink and PhotoOverlay objects can have an associated camera if the camera_longitude, camera_latitude, camera_altitude, camera_altitudemode, head and/or tilt and/or roll fields are defined.
Starting with OGR 1.10, KML <GroundOverlay> elements are supported for reading (unless the LIBKML_READ_GROUND_OVERLAY configuration option is set to FALSE). For such elements, there are icon and drawOrder fields.
Style Strings at the feature level are Mapped to KML as either a <Style> or <StyleUrl> in each <Placemark>.
When reading a kml feature and the environment variable LIBKML_RESOLVE_STYLE is set to yes, styleurls are looked up in the style tables and the features style string is set to the style from the table. This is to allow reading of shared styles by applications, like mapserver, that do not read style tables.
When reading a kml feature and the environment variable LIBKML_EXTERNAL_STYLE is set to yes, a styleurl that is external to the datasource is read from disk or fetched from the server and parsed into the datasource style table. If the style kml can not be read or LIBKML_EXTERNAL_STYLE is set to no then the styleurl is copied to the style string.
When reading a kml StyleMap the default mapping is set to normal. If you wish to use the highlighted styles set the environment variable LIBKML_STYLEMAP_KEY to "highlight"
When writing a kml, if there exist 2 styles of the form "astylename_normal" and "astylename_highlight" (where astylename is any string), then a StyleMap object will be creating from both styles and called "astylename".
OGR fields (feature attributes) are mapped to kml with <Schema>; and <SimpleData>, except for some special fields as noted below.
Note: it is also possible to export fields as <Data> elements if the LIBKML_USE_SCHEMADATA configuration option is set to NO.
A rich set of environment variables are available to define how fields in input and output, map to a KML <Placemark>. For example, if you want a field called 'Cities' to map to the <name>; tag in KML, you can set an environment variable.
Translation of OGR Geometry to KML Geometry is pretty strait forwards with only a couple of exceptions. Point to <Point> (unless heading and/or tilt and/or roll field names are found, in which case a Camera object will be generated), LineString to <LineString>, LinearRing to <LinearRing>, and Polygon to <Polygon>. In OGR a polygon contains an array of LinearRings, the first one being the outer ring. KML has the tags <outerBoundaryIs> and <innerBoundaryIs> to differentiate between the two. OGR has several Multi types of geometry : GeometryCollection, MultiPolygon, MultiPoint, and MultiLineString. When possible, OGR will try to map <MultiGeometry> to the more precise OGR geometry type (MultiPoint, MultiLineString or MultiPolygon), and default to GeometryCollection in case of mixed content.
Sometimes kml geometry will span the dateline, In applications like qgis or mapserver this will create horizontal lines all the way around the globe. Setting the environment variable LIBKML_WRAPDATELINE to "yes" will cause the libkml driver to split the geometry at the dateline when read.
The driver supports reading and writing to files managed by VSI Virtual File System API, which include "regular" files, as well as files in the /vsizip/ (read-write) , /vsigzip/ (read-write) , /vsicurl/ (read-only) domains.
Writing to /dev/stdout or /vsistdout/ is also supported.
The following bash script will build a csv file and a vrt file, and then translate them to KML using ogr2ogr into a .kml file with timestamps and styling.
#!/bin/bash
# Copyright (c) 2010, Brian Case
#
# Permission is hereby granted, free of charge, to any person obtaining a
# copy of this software and associated documentation files (the "Software"),
# to deal in the Software without restriction, including without limitation
# the rights to use, copy, modify, merge, publish, distribute, sublicense,
# and/or sell copies of the Software, and to permit persons to whom the
# Software is furnished to do so, subject to the following conditions:
#
# The above copyright notice and this permission notice shall be included
# in all copies or substantial portions of the Software.
#
# THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS
# OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES OF MERCHANTABILITY,
# FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL
# THE AUTHORS OR COPYRIGHT HOLDERS BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER
# LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING
# FROM, OUT OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER
# DEALINGS IN THE SOFTWARE.
icon="http://maps.google.com/mapfiles/kml/shapes/shaded_dot.png"
rgba33="#FF9900"
rgba70="#FFFF00"
rgba150="#00FF00"
rgba300="#0000FF"
rgba500="#9900FF"
rgba800="#FF0000"
function docsv {
IFS=','
while read Date Time Lat Lon Mag Dep
do
ts=$(echo $Date | sed 's:/:-:g')T${Time%%.*}Z
rgba=""
if [[ $rgba == "" ]] && [[ $Dep -lt 33 ]]
then
rgba=$rgba33
fi
if [[ $rgba == "" ]] && [[ $Dep -lt 70 ]]
then
rgba=$rgba70
fi
if [[ $rgba == "" ]] && [[ $Dep -lt 150 ]]
then
rgba=$rgba150
fi
if [[ $rgba == "" ]] && [[ $Dep -lt 300 ]]
then
rgba=$rgba300
fi
if [[ $rgba == "" ]] && [[ $Dep -lt 500 ]]
then
rgba=$rgba500
fi
if [[ $rgba == "" ]]
then
rgba=$rgba800
fi
style="\"SYMBOL(s:$Mag,id:\"\"$icon\"\",c:$rgba)\""
echo $Date,$Time,$Lat,$Lon,$Mag,$Dep,$ts,"$style"
done
}
wget http://neic.usgs.gov/neis/gis/qed.asc -O /dev/stdout |\
tail -n +2 > qed.asc
echo Date,TimeUTC,Latitude,Longitude,Magnitude,Depth,timestamp,OGR_STYLE > qed.csv
docsv < qed.asc >> qed.csv
cat > qed.vrt << EOF
<OGRVRTDataSource>
<OGRVRTLayer name="qed">
<SrcDataSource>qed.csv</SrcDataSource>
<GeometryType>wkbPoint</GeometryType>
<LayerSRS>WGS84</LayerSRS>
<GeometryField encoding="PointFromColumns" x="Longitude" y="Latitude"/>
</OGRVRTLayer>
</OGRVRTDataSource>
EOF
ogr2ogr -f libkml qed.kml qed.vrt