----- "Joshua Judson Rosen" <[email protected]> wrote: > > 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.
[...] > 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. The issue is really uncoupling the size of the viewport from the zoom level. At a given zoom, let's say 14, you get a certain number of square miles of actual land visible in the viewport, let's say 400. If you zoom in to 15, you get 1/4 that amount of land, 100 sq mi. Generally, you do that by loading the zoom-15 tiles for that smaller area. But if you do that, you get features that are also scaled for that size, and those can be too small to read unless you're holding the device in your hand, or sitting at a desk with it, which is the problem Josh is talking about. 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? To reply to another thread here overnight: the generic term for map tiles such as we use and the protocols to retrieve them seems to be TMS, or, if you weld in the tile-name-addressing protocol, Worldwind, after NASA's setup, which appears to have been the first implementation widely used. Cheers, -- jra -- Jay R. Ashworth Baylink [email protected] Designer The Things I Think RFC 2100 Ashworth & Associates http://baylink.pitas.com '87 e24 St Petersburg FL USA http://photo.imageinc.us +1 727 647 1274 Start a man a fire, and he'll be warm all night. Set a man on fire, and he'll be warm for the rest of his life. _______________________________________________ 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
