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

[Joshua Judson Rosen]

"Jay R. Ashworth" <jra at baylink.com> writes:
>
> ----- "Joshua Judson Rosen" <rozzin at geekspace.com> wrote:
> > > 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.
> 
> [...]
> 
> > 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.
> 
> Indeed it does, as I leaned when driving around the east coast of Florida
> last week with my 12" 1024x768 Thinkpad in the trunk next to me.
[...]
> His solution, which I like a lot, is to build in a scaling-factor
> offset, such that you don't *use* the zoom-N tiles at zoom level N,
> you use the zoom-(N-X) tiles, where X is the scaling factor in
> question; you might set it to 1, and use the zoom-14 at zoom level
> 15, but scale them up by 2:1, using the machinery that already
> exists.
> 
> You'd just only display the parts of those tiles that fit in the
> zoom-15 viewport; that is, the center of the area; this might
> require clipping tiles, but that support's clearly already in there.
> 
> My idea of the optimum user implementation of this is to put the
> offset manipulation on another pair of keyboard keys (for those
> devices that have keyboards), probably [ and ], and I would clip it
> at unity; I don't know that I see that X needs to be able to go
> negative; do you, Josh?

I don't know--as far as the UI goes, probably not with the current
set of map-sources (OpenStreetMap, Google, Yahoo!...), but maybe;
images almost never downscale as well as they upscale without special
attention, and some of the tile-providers actually provide a fairly
extreme case of this be using *single-pixel-wide* lines that may
(or may not, depending on the details of the downscaling-algorithm...)
disappear entirely. This is why I haven't bothered adding support to
FoxtrotGPS for negative zoom-offsets thus far.

But, regardless of whether we support it in the application, I don't
see any reason why the *back-end library* should impose a *hard* limit
at either end; after all, if someone does actually find a set of very
high-density tiles that they like, but they're using lower-density
display (say, tiles using 128-pixel map-icons, and a 96-px/inch VGA
display), then it may make sense to enable that. We'll see, I guess.
I don't intend to clutter-up our UI (or even the GConf interface)
with things like this unless their absense is causing someone pain.

-- 
"Don't be afraid to ask (λf.((λx.xx) (λr.f(rr))))."