The KML Problem

KML is if nothing well supported by many applications. We allow export of it at WeoGeo. But why is it every time I use it I get just a little bit angry? Take this simple OGR command:

ogr2ogr – extract_chairlifts.sh
1
ogr2ogr -where "description LIKE '%chair_lift%'" -f KML chair_lifts.kml output.kml "aerialway_line"

See that LIKE? It’s in there because the KML has no database. I’m basically searching the description bubble and finding something. I felt pretty dirty after resorting to that hack. Of course you COULD create a KML that had more “fields” but those are few and far between. It might be my database background, but I almost require a database backend for me to actually use spatial files. So how do I interchange GIS?

  1. Shapefile – No, I already said I’m leaving.
  2. KML – No database, no bueno (can I have a t-shirt with that?)
  3. File Geodatabase – Non-standard outside of the Esri stack
  4. WKT – in an alternate timeline we are happy and this is our interchange format.

I could go on, but you get the point. GIS formats are either poor choices from a technological standpoint or they are poorly supported. I’ve joked around quite a bit about SpatiaLite being poorly supported, but maybe it is time for me to get back on that wagon. Consider this my goal for 2013, use SpatiaLite as my personal GIS file format of choice.

GeoMonkey SpatiaLite

The GeoMonkey is wearing his SpatiaLite jacket waiting for the bandwagon to show up.

KML is if nothing well supported by many applications. We allow export of it at WeoGeo. But why is it every time I use it I get just a little bit angry? Take this simple OGR command:

ogr2ogr – extract_chairlifts.sh
1
ogr2ogr -where "description LIKE '%chair_lift%'" -f KML chair_lifts.kml output.kml "aerialway_line"

See that LIKE? It’s in there because the KML has no database. I’m basically searching the description bubble and finding something. I felt pretty dirty after resorting to that hack. Of course you COULD create a KML that had more “fields” but those are few and far between. It might be my database background, but I almost require a database backend for me to actually use spatial files. So how do I interchange GIS?

  1. Shapefile – No, I already said I’m leaving.
  2. KML – No database, no bueno (can I have a t-shirt with that?)
  3. File Geodatabase – Non-standard outside of the Esri stack
  4. WKT – in an alternate timeline we are happy and this is our interchange format.

I could go on, but you get the point. GIS formats are either poor choices from a technological standpoint or they are poorly supported. I’ve joked around quite a bit about SpatiaLite being poorly supported, but maybe it is time for me to get back on that wagon. Consider this my goal for 2013, use SpatiaLite as my personal GIS file format of choice.

GeoMonkey SpatiaLite

The GeoMonkey is wearing his SpatiaLite jacket waiting for the bandwagon to show up.

Author: James Fee

National GIS/IT Practice Leader at Matrix New World

17 thoughts on “The KML Problem”

  1. Here are my preferences

    Editing of Data
    – Database (postgis, oracle etc) for any long term stable data sets
    – File database (ESRI FGDB, Spatialite) for more dynamic data sets

    Exchange of data
    – KML only if it’s designed to be viewed in Google earth on maps
    – CSV with EWKT for geometry for a compact exchange format
    – JSON with WKT for geometry for more complex data models

    Definitely not the following as they are too verbose
    – GeoJSON
    – GML
    – Random XML or ESRI’s XML format

    Still need to have a way to define an embedded schema for exchange formats.

    Just need to get tools on board.

    Consider a simple JSON document (excuse formatting the editor keeps messing it up)

    {
    “schema”: [
    {
    “name: “Road”,
    “attributes”: [
    {
    “name”: “id”,
    “type”: “integer”
    },
    {
    “name”: “geometry”,
    “type”: “EWKTPoint”
    }
    ]
    }],

    “data”: [
    {
    “type”: “Road”,
    “srid”: 4326
    “records”: [
    [1, “POINT(-90 90)”],
    {
    “id”: 2,
    “geometry””POINT(-90 90)”
    }
    ]

    }

    ]

    }

    1. I’d take WKT over those other exchange formats personally. I guess that’s why we don’t have consensus.

      The thing about SQLite/SpatiaLite is I’ve got a database that I can take with me and use out of the box. That’s awesome on many levels.

  2. Here are my preferences

    Editing of Data
    – Database (postgis, oracle etc) for any long term stable data sets
    – File database (ESRI FGDB, Spatialite) for more dynamic data sets

    Exchange of data
    – KML only if it’s designed to be viewed in Google earth on maps
    – CSV with EWKT for geometry for a compact exchange format
    – JSON with WKT for geometry for more complex data models

    Definitely not the following as they are too verbose
    – GeoJSON
    – GML
    – Random XML or ESRI’s XML format

    Still need to have a way to define an embedded schema for exchange formats.

    Just need to get tools on board.

    Consider a simple JSON document (excuse formatting the editor keeps messing it up)

    {
    “schema”: [
    {
    “name: “Road”,
    “attributes”: [
    {
    “name”: “id”,
    “type”: “integer”
    },
    {
    “name”: “geometry”,
    “type”: “EWKTPoint”
    }
    ]
    }],

    “data”: [
    {
    “type”: “Road”,
    “srid”: 4326
    “records”: [
    [1, “POINT(-90 90)”],
    {
    “id”: 2,
    “geometry””POINT(-90 90)”
    }
    ]

    }

    ]

    }

    1. I’d take WKT over those other exchange formats personally. I guess that’s why we don’t have consensus.

      The thing about SQLite/SpatiaLite is I’ve got a database that I can take with me and use out of the box. That’s awesome on many levels.

  3. KML standard supports ExtendedData, which lets you do key-value data with each feature. It’s just that the main tools for authoring and displaying KML don’t do a very good job of exposing or explaining this (thanks Google!)

    Bare SQLite + R-Tree > Spatialite, but for the time being let’s all just talk GeoJSON until there’s a standard TopoJSON-infused protobuf-encoded binary equivalent.

  4. KML standard supports ExtendedData, which lets you do key-value data with each feature. It’s just that the main tools for authoring and displaying KML don’t do a very good job of exposing or explaining this (thanks Google!)

    Bare SQLite + R-Tree > Spatialite, but for the time being let’s all just talk GeoJSON until there’s a standard TopoJSON-infused protobuf-encoded binary equivalent.

  5. Second that. For now, SpatiaLite is a good all around compromise. Add in some QGIS/QSpatialLite plug-in action, and you don’t even have to type anything.

  6. I like WKT also, its elegant. The whole point of an interchange format is that everyone can use it. Everyone can use shapefile. Its massive limitations make it work everywhere easily.

  7. I like WKT also, its elegant. The whole point of an interchange format is that everyone can use it. Everyone can use shapefile. Its massive limitations make it work everywhere easily.

Comments are closed.