Export private fields to create custom elements

customElement := &kml.CompoundElement{
    StartElement: xml.StartElement{Name: xml.Name{Local: "Folder"}, Attr: []xml.Attr{{Name: xml.Name{Local: "id"}, Value: "myCustomID"}}},
    Children: []kml.Element{
        kml.Name("My custom folder name"),
    },
}

k := kml.KML(
    customElement,
)

if err := k.WriteIndent(os.Stdout, "", "  "); err != nil {
    log.Fatal(err)
}

Output

<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns="http://www.opengis.net/kml/2.2">
  <Folder id="myCustomID">
    <name>My custom folder name</name>
  </Folder>
</kml>

Thanks for this useful library!

I noticed that the example from README.md cannot be imported into Google Earth as-is because it nests Placemarks underneath the <kml> tag, whereas it should nest them underneath a <Document> tag.

Other examples are correct in that regard, but it would be good to fix this one, too, I think :)

// A SimpleElement is an Element with a single value.
type SimpleElement struct {
	xml.StartElement
	value string
}

// A CompoundElement is an Element with children.
type CompoundElement struct {
	xml.StartElement
	children []Element
}

// A SharedElement is an element with an id.
type SharedElement struct {
	CompoundElement
	id string
}

Those struct should have get/setter for custom user modifications See below an example for SimpleElement.

func (s *SimpleElement) GetValue(value string) {
    s.value = value
}

That allow user to customize Element or create new ones.

Currently strings are written on a single line, e.g.

<description>Attached to the ground. Intelligently places itself at the height of the underlying terrain.</description>

It would be nice if these strings were split to some width (e.g. 80 columns) when the output is pretty, e.g.

<description>
  Attached to the ground. Intelligently places itself at the height of the
  underlying terrain.
</description>

This is similar to #5 in that it requires MarshalXML to know whether the indent is not empty.

Currently <coordinates> are emitted on a single line, e.g.

<coordinates>1,2,3 4,5,6 7,8,9</coordinates>

It would be nice if coordinates, when emitted with WriteIndent were neatly indented, e.g.

<coordinates>
  1,2,3
  4,5,6
  7,8,9
</coordinates>

This would required Coordinates.MarshalXML to "know" whether it is being called in pretty or compact node. This information is currently not exported by the standard encoding/xml library.

The package currently contains all elements in KML 2.2. There is a specification for KML 2.3: http://www.opengeospatial.org/standards/kml#downloads

The package should be extended to support KML 2.3.

As raised by @stapelberg in #1, currently the package offers no protection against generating invalid KML documents (indeed, it is an explicit non-goal of the package).

It would be great if the package could offer run-time verification of KML documents as a sanity check in the absence of #2.

As raised by @stapelberg in #1, currently the package offers no protection against generating invalid KML documents (indeed, it is an explicit non-goal of the package).

It would be great if the package could offer compile-time protection against generating invalid documents.