[OpenLayers-Dev] Re: [OpenLayers 3] code sprint summary, and request for comments

Sun Oct 3 03:07:19 EDT 2010

Hi,

thanks a lot for your offer to cooperate on this! Personally, I am not too deep into the BaseLayer discussion yet, because I agree with Tim that we first should look at removing the baselayer/overlay dichtomy, and think about convenience functionality afterwards. If you guys can provide us feedback from your users, that would be great.

Regarding the question about the free zoom mode, there should be no technical blockers. The best way to go would be relative positioning of tiles on the grid (with percentages), and then just resizing the grid with css would also make the tiles scale.

Regards,
Andreas.

On Oct 2, 2010, at 02:11 , Bouiaw wrote:

> Hi guys,
> 
> I am really interested by this discussion, since we discussed a lot on
> that on OpenScales side too. I think it could be interesting to share
> what we have implemented in 1.2 and what we plan to do in 2.x, since
> we have the same starting point (OpenScales 1.0 = OpenLayers 2
> behaviour).
> 
> We are also very interested by some feedbacks, in order to know if
> what we have done could make sense, or not, in OpenLayers. We may be
> be interested to backport it in an OpenLayers 3 fork on GitHub if
> there is some interest.
> 
> About previous discussion, I think Paul Spenser proposal is great.
> 
> The behaviour we have on OpenScales 1.2 is the following :
> - Layer has no more isBaseLayer property
> - baseLayer is just a reference to a Layer (could be any layer),
> stored in the map, in order to identify the current baseLayer
> - baseLayer define current projection, reolutions and extent
> - map has no projection, no resolutions, and use active baseLayer values
> - No more overlays, all layers have the same capabilities
> 
> Source code :
> http://bitbucket.org/gis/openscales/src/tip/openscales-core/src/main/flex/org/openscales/core/Map.as
> http://bitbucket.org/gis/openscales/src/tip/openscales-core/src/main/flex/org/openscales/core/layer/Layer.as
> 
> For 2.x, we plan to implement free zoom mode and make resolution level
> optional (not anymore in Layer, but deeper in inheritance tree). The
> main "issue" we want to fix is the strong link between cached raster
> layer resolution levels and display zoom levels. We will remove this
> strong link, allowing the user to display any intermediate resolution
> (continous zooming) and use raster scaling on client side to display
> the closest raster cache level.
> 
> Consequences of theses changes are the following :
> - No more baselayer
> - No more resolutions array or numZoomLevel in Layer class
> - We create a new DiscreteLevelLayer class with resolutions array,
> numZoomLevel and related stuffs
> - Map have a projection property, that is used to define the display projection
> - Layer have a native projection property, and an information that
> allow us to know if we can request data in another projection (server
> ide reprojection)
> 
> Any feedback about these 2 behaviours applyed to OpenLayers 3 ?
> Do you think free zoom mode based on client image scaling could make
> sense in OpenLayers ? Is there some technical blocking points ?
> 
> Regards,
> Sébastien Deleuze
> 
> On Fri, Oct 1, 2010 at 12:32 AM, Tim Schaub <tschaub at opengeo.org> wrote:
>> On 9/30/10 2:55 AM, Peter Robins wrote:
>>> 
>>> On 29 September 2010 00:15, Tim Schaub<tschaub at opengeo.org>  wrote:
>>>> 
>>>> The key part for me starting out is that we agree that map properties
>>>> rule
>>>> (already agreed) and get rid of all the coupled default properties
>>>> (projection is related to units and extent and resolutions).
>>>> 
>>>> If we require just "projection" as a map config property to start, we can
>>>> get most of what we need by providing a lookup of units and valid extent
>>>> for
>>>> common CRS identifiers.
>>> 
>>> hm, don't think I'd agree with that. Units are definitely part of a
>>> projection definition, but resolutions or extent? They surely depend
>> 
>> Yes, I agree with what you say below.  I was only talking about deriving
>> sensible defaults in the case where no values are given.  The Google layer
>> (and other fixed layers) will only be available at limited resolutions on
>> the server.  We can also work in functionality to scale images to fit
>> whatever resolution the user desires in many cases (continuous zoom on the
>> client, limited resolutions on the server).
>> 
>> For EPSG:4326, we could assume [-180, -90, 180, 90] a a max extent if none
>> is given.  We could also have a default number of zoom levels (say 20) and a
>> default zoom factor (2).  We also have a default tile size (256x256).  If
>> you assume the user wants to see the whole world one tile high, you can
>> derive the rest.
>> 
>> Again, each of these should be configurable when the map is constructed.  In
>> the case where values are not given, we can do a fair bit with the CRS
>> identifier alone.
>> 
>> The difference between what I sketched out here and what we have now is
>> subtle but significant.  We have a default projection, default units,
>> default maxResolution, and a default maxExtent.  These things are all
>> coupled.  This makes it easy to screw up.
>> 
>>> on the server, i.e. the layer. A given server may use Google Mercator,
>>> but for only part of the globe, and may also provide resolutions that
>>> differ from Google's. Google's tiling/resolution system is
>>> mathematically simple and used by other providers, but is not inherent
>>> to the projection. As another example, UTM zones have an extent, but
>>> in practice it's just a guideline and there's no reason why a server
>>> may not go beyond those borders if needed.
>>> 
>>> Because every map that uses a given server is not going to use all the
>>> available extents/resolutions/projections, ISTM the definition of that
>>> server for that map will have to be defined in the layer corresponding
>>> to the server. If you allow reprojection, then that can only be to a
>>> projection supported by at least one of the layers, so the list of
>>> available projections is simply the sum of what's available in the
>>> layers. The map would store only the current projection. Because
>>> maxExtent is simply a list of coordinates, that can be defined at the
>>> start, stored in the map, and then transformed if the map is
>>> reprojected (with the proviso that the transform logic has to be
>>> available). That will commonly be different from the extent of what's
>>> available on the server(s). Resolutions though is trickier, because
>>> different layers/servers may provide different resolutions. To take an
>>> example, say server A provides 10,20,30,40,50; server B provides
>>> 25,30,35,40; say your map is only concerned with 20-35. ISTM that the
>>> best way to handle this is to store only those resolutions you need in
>>> the layers, so the layer for server A would be 20,30, and that for B
>>> would be 25,30,35. Then the map resolutions would again be the sum of
>>> the layers, and there would be no need for a separate list of
>>> resolutions in the map object. If you are allowing reprojection, then
>>> you would have to define this for each projection you want to cater
>>> for. I don't know how common this sort of thing is in practice, but
>>> ISTM the software needs to be able to handle it.
>>> 
>>> So, I would say, yes, definitely start with something simple and
>>> gradually expand it. Yes, store the available
>>> projections/resolutions/extents for commonly used servers in some kind
>>> of catalogue, so programmers don't have to keep redefining them. Yes,
>>> make it easy to use common defaults. But I'm not sure it's as simple
>>> as saying that 'map properties rule'.
>>> _______________________________________________
>>> Dev mailing list
>>> Dev at lists.osgeo.org
>>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>> 
>> 
>> --
>> Tim Schaub
>> OpenGeo - http://opengeo.org
>> Expert service straight from the developers.
>> _______________________________________________
>> Dev mailing list
>> Dev at lists.osgeo.org
>> http://lists.osgeo.org/mailman/listinfo/openlayers-dev
>> 
> _______________________________________________
> Dev mailing list
> Dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev

-- 
Andreas Hocevar
OpenGeo - http://opengeo.org/
Expert service straight from the developers.