[OpenLayers-Dev] OpenLayers for Mobile devices

[Beau Anderson]

Kind of:

I'm definitely looking for "No white screen", but I'm also looking for more
than that.  In the Map.js source code there is a parameter called
"factionalZoom" and the comment says:

     * When fractionalZoom is set to true, it is possible to zoom to
     *     an arbitrary extent.  This requires a base layer from a source
     *     that supports requests for arbitrary extents (i.e. not cached
     *     tiles on a regular lattice).  This means that fractionalZoom
     *     will not work with commercial layers (Google, Yahoo, VE), layers
     *     using TileCache, or any other pre-cached data sources.

...but the truth is that even commercial cached tile maps like Google
support a raster-based fractional zoom.  In other words, let's pretend that
Google only supported two different resolutions, 0.5 and 1.0, but then the
user uses a gesture or a mouse wheel or something and zooms to a resolution
of 0.6.  Google displays the 1.0 resolution tile, but does a raster resize
down to 0.6.  Sure, the tile looses some useful information during the
resize, but the UI experience is smoother than forcing predefined
resolutions on the user.  I guess what I really want is "No White Screen"
and "No Resolution Restrictions Within The Min/Max Resolutions A Map
Supports".  A browser can scale vectors and rasters reasonable well enough
that OpenLayers could be a lot smoother experience for users.  This is less
pronounced on desktop implementations than on devices that support finger
gestures, but is applicable in both cases.

Once client-based fractional zooming works well, you can do things like a
good animated zoom-in effect when a user double-clicks, etc. as well.
 Another "nice-to-have" is gradual fade-in of new tiles, which I have
already implemented for OpenLayers.Tile.Image's.  Once these things are
done, OpenLayers will behave the same way that users are used to in modern
commercial map providers.

On Mon, Dec 27, 2010 at 10:23 AM, Bob Basques
<Bob.Basques at ci.stpaul.mn.us>wrote:

>  All,
>
>  I think the general idea that Beau is describing is "No white screen"!!
>  Always hate a blank screen when transistioning a map, especially when
> zooming.  Even something wildly pixelated is valuable to the end user to key
> on reference points, it also allows for rapid transitioning without waiting
> for the final rendering of things.
>
>  Using a wheel zoom on this interface would be my example of how zooming
> should work visually: *http://gis.ci.stpaul.mn.us/gis/gismo_public/html/,* this
> could use possibly more transistion steps as well as better end loop
> control, as in I should be able to pan, while waiting for the new tiles to
> download and replace the previously rescaled tiles.  Right now the user
> needs to wait for the new tiles to display before rezooming or panning.
>   This interface has been in use for a number of years (before OpenLayers
> even . . .) and is a preferred transistion effect.  We've done some smaller
> implementations of OpenLayers from time to time, and the "always on" Map
> Feature is usually brought up at some point as a desirable feature, this is
> especially important in a emergency response/preparedness situation.
>
>  bobb
>
>
>
>
>
> >>> Beau Anderson <elbeau at gmail.com> wrote:
>
> No, the "resize" behavior is not the same as what I am describing. Using
> Google maps as an example, as you pinch to zoom in/out the raster image
> tiles resize to sized in-between the zoom levels. The "resize"
> transitionEffect does do a raster resize, but only to an actual zoom level.
> In other words, there is no graceful zooming to fractional zoom levels. In
> order to get an effect similar to Google's, you need to not only make the
> background tiles zoom to fractional zoom levels, but the actual foreground
> tiles themselves need to do the same, because if you've pinched to zoom in
> to a fractional zoom level, you need any newly loaded tiles to also be
> resized appropriately.
>
>
>   To put it another way, if you're loading tiles whose actual dimensions
> are 256X256 pixels, it doesn't mean that you will actually be displaying the
> image at 256X256. The fractional zooming is second-nature for users on iOS
> and the newer versions of Android mobile devices these days. The other
> benefit you get for desktop computer users is that once you have fractional
> zooming, then even if the're doing a zoom to a new zoom level, it's not hard
> to do an animated zoom-in/zoom-out (again, the same way Google does). In the
> end, OpenLayers is AWESOME in it's support for various formats, but there
> are a couple UI paradigms that I really want to tweak before I turn it loose
> on my user base. The thing I HAVEN'T delved into yet is how easy/hard this
> will be to implement on other types of layers so that the whole UI acts
> appropriately :s
>
>
>   On Sun, Dec 26, 2010 at 6:13 AM, Tom Hughes <tom at compton.nu> wrote:
>
>>  On 23 December 2010 17:21, Beau Anderson <elbeau at gmail.com> wrote:
>>
>>>  I've got an existing successful iPhone application that I'm porting to
>>> other platforms. There's a lot that I want to add to my app's mapping
>>> functionality and OpenLayers looks like it would fit the bill great, but the
>>> user experience is just not as smooth as Google and Bing provide. The
>>> headache that I've been working on is getting layers that extend from
>>> OpenLayers.Grid to act more like Google where when you zoom in or out it
>>> simply scales the tiles you already have loaded then loads new tiles on top
>>> of them. To accomplish this we need to rethink the way that Grid layers
>>> layout their tiles so that there are multiple layers of tiles within one
>>> Grid (not just foreground and background img's in Image.js).
>>>
>>
>>   Doesn't setting transitionEffect to "resize" on the layer already do
>> that?
>>
>> Tom
>>
>> --
>> Tom Hughes (tom at compton.nu)
>> http://compton.nu/
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.osgeo.org/pipermail/openlayers-dev/attachments/20101227/acddc88f/attachment-0001.html