[FOSS-GPS] Manual tile-scaling control in FoxtrotGPS (and osm-gps-map?) (was: FoxtrotGPS Mapping Library)

[John Stowers]

On Fri, May 21, 2010 at 2:09 AM, Joshua Judson Rosen
<rozzin at geekspace.com> wrote:
> John Stowers <john.stowers.lists at gmail.com> writes:
>>
>> > 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?
>
> Yes--there's no way for me to specify limits on the upscaling.
> I'm not sure how much I should be concerned with the upper limit
> (tangoGPS used a hard-coded limit of 3; Stefan Fröbe has raised it
> to 5 in his geocaching patchset), but there are times when we want
> to set a *lower* limit on upscaling--because we don't actually always
> want to use higher-res tiles. In particular, the pixel-densities of
> some of the phone/tablet screens are so much higher (3x!) than typical
> desktop resolutions (which the map-renderers target) that we basically
> need to upscale just to make a lot of the details (lines, text, icons)
> scrutable by the naked eye at a reasonable distance.
>
> The FreeRunner's screen is ~300 px/inch, so text and icons that are
> perfectly legible at 96 px/inch can be extremely difficult to read
> from more than about a foot (~30 cm) away, which is absolutely
> necessary when driving--as is being to see things at a glance
> rather than with intentful scrutiny. :)
>
> Nokia's N-series tablets are somewhat lower-density (~200 px/inch?),
> but presumably still high enough to cause issues.
>
> The same issue actually still manifests with lower-density displays
> like most laptops (though mine's still ~145 px/inch...), just at
> greater distances.
>
> Some other aspects were described on the openmoko community list
> <http://article.gmane.org/gmane.comp.handhelds.openmoko.community/55877>:
>
>    So, when you select `fewer, bigger details', the code just decreases
>    *pixel-density* and a `zoom-level offset' adjusted accordingly.
>    The map remains at the same zoom-level; but the text and icons get
>    bigger, the streets and other lines get wider; the amount of
>    visual `clutter' decreases, and information-clarity goes up.
>
>    If you select `more, smaller details', the pixel-density is increased
>    and the zoom-offset adjusted in the other direction. Again, the map
>    remains at the same zoom-level; but the text and icons get smaller,
>    the streets and other lines become thinner; the amount of information
>    visible at a given zoom-level (the information-density) increases.
>
>
> If you want to see what I mean, I merged the back-end code into FoxtrotGPS's
> trunk at revid rozzin at geekspace.com-20100507055217-p98k7n2pk08fskk7, and the
> UI was merged at rozzin at geekspace.com-20100507130010-ykfut9y4nwcw4dn5
> (about 2 weeks ago).

Ahh OK, I see now, this (and in particular your previous mail on
openmoko list) has cleared things up. Very interesting, and I will be
sure to take a look next week.

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
>