Flutterby™! : Geodata tools 2010-08-04 04:14:14.585561+00

Geodata tools

2010-08-04 04:14:14.585561+00 by Dan Lyke 6 comments

Okay, I'm now tracking pretty much everwhere I go, using a Wintec WBT-202. Of course this means I have a lot of time sitting on my butt at home, with occasional excursions out. What I need is a few command-line tools that can do interesting things with my trackpoints.

The data's coming out in Wintec proprietary format, but gpsbabel seems to be handling it okay, however, NMEA format seems to be dropping speed information, GPX throws away all sorts o' stuff, KML actually seems to be the least lossy.

What I'd like is the ability to say "give me the points from when I crossed this line to when I cross it again (or another line)", or "give me the points from time X to time Y", or even "break this set of trackpoints into segments wherever I stopped for more than X seconds".

Fairly simple stuff, I could whip it together in a few hours in Perl, but if someone else has already done it I can build on what they've got rather than reinventing the wheel.

Suggestions?

Oh, and someone else has undoubtedly already fought the "why does my KML work in Google Earth but not in Google Maps" problem. I know I've fought it once. If anyone's got refreshers on the subset of KML Google Maps likes (or maybe I should just switch to OpenStreetMap...)

OpenLayers has had a significant release since the last time you tried it. Maybe they've straightened out the issue. Otherwise, I'll point out Chris Schmidt to you at WhereCamp next year so you can make him fix it!

Okay, sounds like I do need to write some Perl that handles gpsbabel's KML for input and spits out that or a Google Maps capable subset for output. Might do it on NMEA data, but it's handy to use Google Earth as a first-pass viewer and at that point it's already in KML.

And I remember there was a reason I decided to not go with OpenLayers last time I was in the Flutterby.net code, I wish I could remember what it was. Probably something about the state of their KML support at that point.

Most GIS formats loose information - especially metadata at each conversion. There's usually not much lost in terms of positional or geometric accuracy. Most differential GPS capture hundreds of readings for every point and to do the differential correction, they are all factored in but then thrown away.

Most formats also ditch everything about points when you are storing lines. The points lose their individual identity.

One possibility is to convert to .OSM format and save all your metadata as tags. The OSM XML format treats each node (point) uniquely with it's own tags, even if it participates as part of a way (line) or relation. I believe that OpenLayers can overlay an OSM XML file on Google Maps or OSM.

As for trimming/thinning, I know such tools exist in Trimble's high-end software and as plug-ins for ArcGIS. Shouldn't be too hard to do otherwise.

I've got my own layer on top of Google's API, so, yeah, I could also switch to OpenStreetMap for display.

But I guess that, per Mark's link, I really need to be generating the KML myself rather than letting gpsbabel do it, and there aren't any tools to do basic operations on tracks?

It's not Google vs. OpenStreetMap - it's Google API vs. OpenLayers. Google conflates their cartgraphic product with their interface. You can use OpenLayers with Google, OSM, Bing, even The National Map.