[FOSS-GPS] FoxtrotGPS Mapping Library

[Joshua Judson Rosen]

Joshua Judson Rosen <rozzin at geekspace.com> writes:
>
> John Stowers <john.stowers.lists at gmail.com> writes:
> > 
> > I was interested to see the announcement of foxtrotgps.
> > 
> > I am the author of the mapping library osm-gps-map
> > ( http://nzjrs.github.com/osm-gps-map/) which I originally developed
> > from the tangoGPS codebase when I forked it a few years ago
> > (for many of the same reasons I suspect you did).
> [...]
> > I suspect you could recreate the whole of tangoGPS UI/app in less than
> > a few thousand lines of C, or a few hundred of python. Additionally
> > v0.5.0 is available in the lucid repositories.
[...]
> At a glance, it looks like osm-gps-map did in fact retain a *huge*
> portion of the functionality of tangoGPS--much of which it'd be
> appropriate to call `core competency', and much of which does in fact
> overlap overlaps with what foxtrotGPS does; and I wouldn't be
> surprised if there are even similarities in *ways* that we're doing
> things, right now (especially given our common lineage...). Though,
> some things *did* certainly change (or get added) in tangoGPS between
> when you forked-off and our 0.99.3 base, so I'll have to allocate some
> time to give osm-gps-map a fair look.
> 
> There are some changes in the works for foxtrotGPS to open things up
> architecturally, generalise some things, and probably integrate some
> of the new newer features (like `friend'-tracking) with some of the
> older features (like self-tracking); we've also been talking about
> pursuing things like different autocentre modes, and smarter
> tile-downloading strategies (like downloading all of the tiles along a
> path). So, I'm curious about how those plans interact with the idea of
> switching to osm-gps-map--how much stuff osm-gps-map would want to
> manage itself, and basically to what extent the library is
> parameterised.

So, it looks like osm-gps-map would mostly be a pretty good fit to FoxtrotGPS.

There are a few things that initially scared me but have turned out to
be non-issues and a few minor nits for which I'm preparing some patches
foryour review, but also a couple of other items that are still bothering me
and for which I don't have a solution on-hand. Critique and questions follow.


The things that initially scared me were some of the points on the website,
like:

    * Recording of points of interest on the map (and the ability to
      add arbitary pixmaps at those points
    * Automatically draws a GPS track (a line showing the history of
      past added points)
    * Automatic centering on new GPS points

The `POI management' scared be because I was expecting osm-gps-map to do
more than it does--I was pleased to find that it just manages a set of
pixmaps and their positions on the map-buffer :)

I see that "automatically draws a GPS track" is something that can be
toggled, so that's OK. That you have things like `tracks are drawn in red'
hard-coded in osm_gps_map_print_track() makes the whole track-management
API basically useless to me, so I'd want to do something about that.
It's not necessarily a deal-breaker, though--we could presumably use your
`layer' API to just do the track-rendering ourselves.

Since one of the things that we had been discussing for FoxtrotGPS was
providing different (more intelligent) autocentre modes, and
osm-gps-map does provide something for autocenter, it'd be nice if we
could make use of your autocenter feature somehow; but you have only a
boolean `do it or don't' option right now. Would you be open to
expanding that a little?


Looking deeper...:

The map-repository properties are usable, but seem awkward: several
properties that would seem to be more appropriate on an `OsmGpsMapSource'
class ("repo-uri", "tile-cache", "image-format") are instead on the
OsmGpsMap class, which means managing all of these properties individually
in order to support custom map-repositories like we currently do in
FoxtrotGPS. I may just be allocating rope to hang myself here, but would
you be open to expanding the API to include a GObject type for map-sources?

As Sander pointed out, the high-level osm_gps_map_draw_gps() may be either
too high-level or just not quite the right fit: at the very least, we need
to be able to provide a second directional indicator that points to a
destination; if Sander's concerns about slowness of the alpha-blended icon
are correct, then we'd also want to find another way of indicating HDOP.
I suppose we may want to be able to augment or change the icon in other
ways in the future, but I don't have anything specific in mind right now.
Actually, we could just skip using osm_gps_map_draw_gps() altogether and
use a layer or `poi' image instead instead of trying to re-parameterise
osm_gps_map_draw_gps(). That would probably be a better idea, anyway.

The only issues that I see right now that don't even have work-arounds
are that there's no way for to communicate `overzoom bounds' down to
osm_gps_map_render_missing_tile() or any of the logic underneath it,
and that there actually is no tile-scaling functionality except in the
handler for *missing* tiles; if we're to replace FoxtrotGPS' map-drawing
code with osm-gps-map, I'd need some sort of `tile zoom' knob to replace
the one that we have integrated into our current tile-loader/-renderer.

The fact that there's nothing in your `POI' (image) API to remove a single
POI from the display rather than removing all of the POIs that (happen to)
have the same pixbuf associated with them also bothers me, though we don't
currently have anything better in our codebase.... I might be keen on
getting an opaque pointer back from osm_gps_map_add_image() that I could
later pass to some `remove...()' function (which would be the same as
osm_gps_map_remove_image(), except would have an additional argument to
specify which specific POI to remove or NULL for `all of them').
Would you take a patch for that?

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."