[FOSS-GPS] FoxtrotGPS Mapping Library

[John Stowers]

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

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

I think this need to be considered in light of the tracks-api-rework
branch, so I will need to think about this too.

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

Im not sure I understand you here. Could you please explain furthur.

Are you referring to how osm-gps-map first upscales the low res tile
while it waits for the high res one to arrive?

>
> 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, a patch for this would be great. It would also be worthwhile to
rename the functions to osm_gps_map_poi_{add,remove} to match the work
going on in the tracks-rework / gtk-3.0 branch.

Regards,

John

>
> --
> "Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."
> _______________________________________________
> This message is sent to you from FOSS-GPS at lists.osgeo.org mailing list.
> Visit http://lists.osgeo.org/mailman/listinfo/foss-gps to manage your subscription
> For more information, check http://wiki.osgeo.org/wiki/FOSS-GPS
>