[FOSS-GPS] FoxtrotGPS Mapping Library

[John Stowers]

2010/5/19 John Stowers <john.stowers.lists at gmail.com>:
>> 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,
>
> Yeah, as I said on previous mail, they look good. I will apply them
> when I get back at my development PC.
>
>> 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.
>>
>> 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.
>
> I am currently cleaning up the track API at the moment (see my
> previous reply to Sander) and the track-api-rework branch
> (http://github.com/nzjrs/osm-gps-map/tree/track-api-rework).
>
> Your comments would be appreciated.
>
>>
>> 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?
>
> Yes, I guess there are a few ways this could be done without too much pain.
>  * add an autocenter-mode property and switch-case on that inside the lib
>  * do the existing autozoom calculation in an internal signal handler
> that derived classes could intercept/connect before (and hence add
> their own autozoom behaviour)
>  * expose the autozoom as a vfunc that derived types could override
>  * mystery option 4
>
> What do you think of these approaches considering
>  * the implementation should be future proof to some degree, so that
> new autozoom modes could be added
>  * existing users of the library will not be impacted too much
>  * the library retains a good default level of functionality
>
>>
>>
>> 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?
>
> Perhaps, although the GObject per map source seems a little complex
> considering almost all the code in the different sources will be
> identical. Is there an intermediate option perhaps?
>
>  * add OsmGpsMapSource and OsmGpsMapSourceSlippy
>  * add map-source-object property
>  * by default map-source-object gets assigned a OsmGpsMapSourceSlippy
> object with the values pulled from the current MapSource_t machinery
>
> While this could be almost a way draw an interface between tile
> fetching and rendering, as far as your use is concerned it almost
> seems as the worst of both worlds and the better of none.
>
> More thought and your comments would be appreciated on this.
>
>>
>> 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.
>
> I have also had other people suggest that they wanted other ways to
> draw the current GPS point/HDOP/etc. I think this definately qualifies
> (i.e. patches welcome) as the kind of thing that would be suitable for
> a vfunc (draw_gps_point) that derived classes could then override.

draw_gps_point has now been made a virtual function that subclasses
can override if they wish.

John