On Friday 14 May 2010 14:04:34 John Stowers wrote: > > > > This is just a friendly reminder to invite you all to check out > > > osm-gps-map [1]. The optimisations you describe and many others were > > > implemented in osm-gps-map a while ago. In fact, the excellent > > > performance of osm-gps-map is one of the main reasons it is used in many > > > of the most popular mapping apps on maemo. > > > > It sure looks very nice and I'd love to ditch my stuff and replace it with > > osm-gps- map, > > but there are some issues, AFAICS from the API; > > Cool, comments follow, > > > - There seems to be no callback for download-progress-reporting (number of > > threads, queue > > depth). I'd hate to ditch the visual download feedback foxtrot currently > > has. > > No callbacks is by design, the number of queued tiles is exposed as a > gobject property (tiles-queued). It can be polled at whatever frequency > the UI wishes (see python demo for example).
Well I actually meant signals instead of callbacks, but fair enough, this should suffice. Is it also possible to inspect currently running download threads, and is there a way to cancel the queue? > > - why are draw_gps and clear_gps exposed to the public API? They look like > > paint > > primitives, while the rest of the rendered objects are handled in a > > 'managed' fashion. I > > would have expected something like 'enable_draw_gps(boolean)' and > > 'update_position' or > > something. > > Yeah, I am carrying around a bit of backward compatibility cruft - this > falls into that category... Ok. Is it sufficient to only call draw_gps when the position gets updated or are there more situations where I need to (re)draw? > > - functions for managing tracks, images and layers are not symmetric; > > tracks have no > > remove function, layers have no remove function, images have no replace > > function (which > > would be nice for e.g. highlighting) > > Partly as above. Images and layers serve a different purpose (layers = > overlays to use your term) so their API will not be entirely > symmetrical, although I really should add a remove_layer call. Yeah after looking at the code I will probably not use layers to render friends, photo's etc, but instead use the image functions.. > The next signifigant API break I make (which will probbably be when > someone gives me enough reason) will be to clean up the track interface > so that there is no distinction between the first track (i.e. the > xxx_gps_xxx API) and a more general API for adding/removing/managing > multiple tracks. Tracks can get quite large. Is the entire track redrawn when calling replace_track, or does it do a comparison and only draw the new segments of the track? > > From playing around a bit with gpxview on maemo, there seem to be some > > glitches with > > downloading tiles. Sometimes a whole zoom-level stays white, sometimes a > > scaled tile > > doesn't get updated with the tile from the correct zoom level. > > I cant say I have observed such bugs, I will take your word (if gpxview > is using a recent version and correct build etc). Unfortunately I don't > have any maemo stuff to test with Dont know any details, I've only played with it for 15 minutes or so, so might be nothing.. Will keep you updated on what I observe while integrating with foxtrot. grtz, Sander _______________________________________________ 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
