[FOSS-GPS] FoxtrotGPS Mapping Library

[Sander van Grieken]

On Wednesday 19 May 2010 04:51:32 Joshua Judson Rosen wrote:
> So, it looks like osm-gps-map would mostly be a pretty good fit to FoxtrotGPS.

Yes I see no big problems finishing the migration.

> 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.

No I don't think the layer API is suitable for this. It solves a different problem and 
would generate more overhead than is needed. I DO think the track API should be extended 
though, as I already discussed with John, at least with the ability to specify a color per 
track, but possibly expose the whole Cairo object used to draw the track.

> 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?

Right now my branch uses foxtrot's autocenter function, but it could be using osm-gps-map 
provided autocenter functionality. 

However, while it's nice to have autocenter functionality on the widget, we should be 
careful to put too much application level functionality into osm-gps-map.

Autocenter is a bit of a 50/50 case (app vs. widget), and it's nice to have a default 
implementation in osm-gps-map, but IMO we shouldn't put a super-fancy autocenter module 
inside the widget, but instead let the application define it that's most suitable to the 
application's usecase.

For example, if some application does navigation, it might decide to center the map not on 
where you are but instead some distance along the planned route, so you see most of the 
map ahead of you. This kind of logic should not be integrated in osm-gps-map.

> 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; 

This function is OK, it's not the drawing primitive the function name suggested it was. I 
can fire-and-forget GPS locations to it. Maybe the parameters could be replaced by some 
struct that can contain also bearing, HDOP, speed, altitude and GPS time, so it could 
render some of these components, or dispatch them to the OSD layer for displaying.

> 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 haven't yet tested on the freerunner, which is probably the best slowness test :)
Anyway, foxtrotGPS displays HDOP in the status bar, so we can pass HDOP=0 to osm-gps-map 
on freerunner if it's a problem.

> 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.

No I don't agree. The current draw_gps does what it needs to do and is highly optimized 
(i.e. only drawing last gps-track segment) and there are dynamic parts to it (heading, 
HDOP, bearing) that are hard to do when you make it image based. Absolutely the widget's 
responsibility.

> 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?

Yes I agree here. I'm running into this problem right now with the friends and POIs. I'm 
working around that at the moment by removing all friend images, and re-adding them, but 
this might have a more than necessary impact on performance.

I'm eagerly waiting for this change, so I can implement friends and POIs the right way :)

grtz,
Sander