Re: (Fwd) [Gpsbabel-code] massive s&r scheduled

[Robert L. <rob...@us...>]

Mark Bradley wrote:

> Any chance of adding in two double values to store depth and proximity

No problem.   That's less of a hassle as it won't "break" code that's not
yet checked into the tree.   

What is the preferred unit of these?   I've just thrown them in my local
tree, with the prose you suggested, and will commit them at the same time.

> As waypoints are relatively low in number (compared, say, to tracks),
> the memory overhead is minimal in my opinion.

Internally, tracks are sequenced lists of waypoints.  With these
changes, a waypoint becomes 112 bytes on my system.  While we need to
stay conscious of memory footprint and not do dumb things, I don't think
we need to microoptimize things yet.

As perspective, newer garmins will allow 10,000 trackpoints.  So yes,
that is over a megabyte of internal storage to represent those.  Yes,
most of those fields are nonsensical for trackpoints but there's a nice
internal symmetry in having waypoints, trackpoints, and routepoints all
be the same structure.

When I start hearing about out-of-memory errors in the Real World, I'll
get more excited about making that common type into a union that's
dynamically typed.

RJL