On Thu, May 20, 2010 at 9:08 PM, Sander van Grieken <[email protected]> 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 _______________________________________________ This message is sent to you from [email protected] 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
