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

Eric Lemoine eric.lemoine at camptocamp.com
Thu Sep 23 01:22:23 EDT 2010


On Thursday, September 23, 2010, Paul Spencer <pspencer at dmsolutions.ca> wrote:
> Hi Eric and others,

Hi Paul

> I'm just catching up on this thread and I have some comments that I would like to add.
>
> I'd really like to see 3.0 put control into the hands of the map and do away with 'magic' behaviour.  I think there are other ways to provide convenience (define a new map sub-class with the appropriate projection/resolutions for instance) without breaking a nice clean API.  So for the record, I think it should be required to provide the projection when defining a map and not magically pick it up from some sort of special layer.

Determining ways to provide convenience is key to the discussion. At
this point I have no other solution than having
fixed-projection/resolutions layers determine the map projection and
resolutions. I'm interesting in other ways.

> Also, I'm not convinced that introducing the concept of master layers and master groups is a good thing.  I think there are some very straight-forward rules that can be applied to a layer to determine if it should be displayed at the current resolution and there is no need to add the concept of mutual exclusion in the core library (i.e. can it display at this resolution, can it be displayed in the current projection, is it within maxExtent).

The goal of layer groups isn't related to resolutions, maxExtent, etc.
It is just a way for the user to create mutually exclusive layers, and
have radio buttons in the layer tree.

The "master" group just aims to identify master layers.

And I'd like to say again that the map doesn't require a master layer.
If there's no master layer the map determines the projection and
resolutions.

>User controls and the application developer should handle this kind of thing.  From the point of view of the library, it shouldn't matter if there is more than one non-transparent layer displayed on top of each other and it (the library) should not prevent it.

Agreed. I think the proposed design does go in that direction. It just
introduces master layers to provide convenience when working with
fixed-projection/resolutions layers. And, with the proposed design,
the user can even use fixed-resolutions/projection layers without them
being master layers, by just not making them part of the "master"
group (new Google("gmap", {group: null}).

Again, if you have other ways to provide convenience I'm interested.

Thanks a lot for you feedback Paul!

-- 
Eric Lemoine

Camptocamp France SAS
Savoie Technolac, BP 352
73377 Le Bourget du Lac, Cedex

Tel : 00 33 4 79 44 44 96
Mail : eric.lemoine at camptocamp.com
http://www.camptocamp.com


More information about the Dev mailing list