"Jay R. Ashworth" <[email protected]> writes: > > ----- "Joshua Judson Rosen" <[email protected]> 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))))." _______________________________________________ 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
