KML produced is too rich

[jidanni]

https://www.gpsbabel.org/htmldoc-development/fmt_kml.html says:

GPSBabel's KML writer is relatively strong.

Too strong in fact. The KML produced is bloated with tons of... well,
one needs e.g., perl:

for (qw!Style LookAt StyleMap snippet styleUrl!) {
    $_->unbindNode for $x->findnodes("//k:$_");
}

to make the KML barely readable again.
Don't get me wrong. It's great KML.
But any KML going through it might triple in size.
So do add more options like trackdata to cut down on all the LookAts etc.,
in case someone just wants to get back to basics. Thanks.

[robertlipe]

In broad strokes we agree on this one. (Finally!) This has been on my list of "Feynman's Problem Solving" candidates list for a long time.

When this was implemented for Earthviewer (nee Google Earth), the defaults were chosen to maximize eye candy and provide lots of ${STUFF} inside the balloons. This has problems in practice (the times don't localize or respect language setttings, very large output, doesn't integrate well with Earth Pro's terrain profile tool, etc. because this is all instead of/in addition to the actual data. We can generate kilobytes of text for a single LLAT. We were also trying to strike balances for old versions of Earth (long forgotten) and even Maps.

Prescription: Turn off the default 'points' flag in the KML writer:
/gpsbabel -t -D9 -i gpx -f reference/skytraq.gpx -o kml,points=0 -F -
reference/skytraq.gpx

Good: This means that you don't have a clickable balloon at every vertex in the line.
Bad: This means that you don't have a clickable balloon at every vertex in the line.

The kml_points (clickable balloons) line (writing a Linestring or not) and track (write the "new" gx:Track features) are three different knobs that can be controlled independently (they may be co-dependant in some way I can't remember at 01:30) but they allow you to control how much bloat, err "value added features" we generate when writing a KML

✗ make && ./gpsbabel -t -D9 -i gpx -f reference/skytraq.gpx -o kml,points=1,lines=1,track=1 -F - | wc -c
207583
✗ make && ./gpsbabel -t -D9 -i gpx -f reference/skytraq.gpx -o kml,points=0,lines=0,track=0 -F - | wc -c
3084

OTOH, turning everything off as in that last example is great for file sizes, but produces literally no useable visual data, so that extreme can kindly be thought of as lossy compression.

There is probably space for some modernization of our default flags here, but we have to think about our integration into the larger ecosystem and revisit my thoughts on using ExtendedData and custom style sheets, including in geocache updates.

Prescription: experiment with points, line, track sub-options. If we can shrink our output without breaking backs on Google Maps users, XSD validations, incompatibility with versions of Earth that Google has tried to kill unsuccessfully, etc. great. revisit in follow-up appointment.

[tsteven4]

I seem to recall our balloons have valuable information the default balloons generated by the latest Earth don't, perhaps the timestamp and/or name.

[jidanni]

I seem to recall our balloons have valuable information the default balloons generated by the latest Earth don't, perhaps the timestamp and/or name.

Yes, that is https://www.gpsbabel.org/htmldoc-development/fmt_kml.html#fmt_kml_o_trackdata . And yes, the user can optionally turn it off already.

Prescription: ...

I am sorry, none of the current possible prescriptions work.

You see, I want a way to chop down

$ echo|gpsbabel -i csv -f - -o kml -F -|wc -l
39

Yes, we tried

$ echo|gpsbabel -i csv -f - -o kml,points=0,lines=0,track=0 -F -|wc -l
39

So it would be great if one could use

-o kml,lookat=0,styles=0,snippit=0

Yup, I'm talking about the power to selectively opt-out of

• Lookat
• all styles
• and the snippit

Currently they are obligatory.