[FOSS-GPS] FoxtrotGPS Mapping Library

[John Stowers]

On Thu, May 20, 2010 at 9:08 PM, Sander van Grieken <sander at 3v8.net> wrote:
> 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.

Good idea.

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

According to another poster it is TMS or WorldWind.

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

Not that I can think of.

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

OK, this sounds like a bug then. I will investigate

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

Thanks.

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

To keep compatibility I will leave (but deprecate) the changed signal
and start to recommend people use the appropriate notify::foo signal.

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

No prob. Its a shame I wont be back at my development PC until Sunday

John