[FOSS-GPS] FoxtrotGPS Mapping Library

[Sander van Grieken]

On Thursday 20 May 2010 00:44:33 John Stowers wrote:
> Fair enough. Is the current autocenter mode sane enough for foxtrotgps?

It is exactly the same as the autocenter code in tango/foxtrot, so should give nobody 
reason to complain :) It has a hardcoded dead-zone of 25% of the view though, which might 
be good to expose as property, so we can set it to 0 to always follow GPS exactly, or to 
1.0 to only re-center when GPS goes outside the view.

> >> > 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
> >
> > Slippy? Isn't that a view mode? IMO has nothing to do with map sources.
> 
> I was using Slippy as the term to describe the format of all these map
> sources, i.e. mercator projection and derivation of tile_x and tile_y
> from lat/lon/zoom
> (http://wiki.openstreetmap.org/wiki/Slippy_map_tilenames). What would
> be an adequate term for this?

Good question. There's many aspects to it (mercator, power-of-two zoom levels, 256px 
tiles, underlying directory structure) but it seems to be the standard way of serving up 
tiles, so maybe call this way the 'standard' or 'MercatorStandard' or 'OSM' way or 
something.

Is there anything out there that works with tiles, but in a totally different way?

> > John, I also found another bug in osm-gps-map:
> >
> > - map scale indicator is incorrect. It is location/center-map specific and changes 
with
> > the latitude.
> 
> The current implementation osm_gps_map_get_scale takes the scale at
> the center. Do you want me to expose
> osm_gps_map_get_scale_at_point (which is currently private)?

No, the center is fine, but if that take_scale function is working correctly, then it's 
probably another bug. My observation is that the OSD scale indicator doesn't get updated 
when staying in the same zoom level but dragging the map to another latitude.

> > And on the wishlist:
> > - I would like to have a zoom-changed signal, so I can update the zoom slider when 
zooming
> > in and out with the keybindings or mouse-scrollwheel.
> 
> You should be able to connect to "changed" which is called anytime the
> bounding box is changed, i.e. zoom or scroll. I should probably also
> emit notify::zoom signal here (i.e. patch welcome)

"changed" will do, thanks :)

> > - tangogps zoomed in and out on the mouse cursor when using the scrollwheel. I'd love 
to
> > see that also working with osm-gps-map.
> 
> Umm this is already supported and works in the test app AFAIR (I am
> not at my development PC)

Strange.. The scrollwheel events go directly to osm-gps-map but it always zooms on 
mapcenter. Will take another look.

> I am filing all the bugs you mention as issues on github
> (http://github.com/nzjrs/osm-gps-map/issues). It would be great if you
> can take a quick look there to see if I have forgotten any of the
> things mentioned in your mail.

Something to add to issue #3:
- keypresses that have bindings also do not get propagated, so not propagating mouse 
button events on OSD elements would make it consistent.
- Possible caveat: button_press and button_release should be symmetrical, so if a 
button_press is propagated, so should the button_release, even if it's on top of an OSD  
layer element.

And issue #7 is not a bug and not on my wishlist anymore, since "changed" will suffice. 
But maybe "changed" is a too generic term, and might be better named "bbox-changed" or 
something.

Anyway, thanks for your quick responses, it really helps keeping the pace.

grtz,
Sander