Hi Eric,
On 2010-09-23, at 1:22 AM, Eric Lemoine wrote:
> On Thursday, September 23, 2010, Paul Spencer <pspen...@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.
I guess I feel that if there is a magic layer that can override the map then we
haven't really made any fundamental change from the 2.x baseLayer concept. I
understand that this is entirely optional but I think will be a source of
confusion in the long run. Just adding a layer to a Map should not change the
fundamental behaviour of the Map.
My counter proposal to master layers would be to introduce sub-classes of Map
that are pre-configured for some scenarios or preset blocks of options that can
be passed to a Map constructor. This might look like:
var map = new OpenLayers.Map.Google({
// additional user options
});
or
var options = OpenLayers.Util.extend(OpenLayers.Config.Google, {
// additional user options
});
var map = new OpenLayers.Map(options);
or
var map = new OpenLayers.Map({
config: OpenLayers.Config.Google
// additional user options
});
In both cases, it is clear that the *Map* is going to be configured
Google-style with preset resolutions, projection etc.
BTW I'm not sure that having OpenLayers.Map.Google is the right naming choice
:) Probably preset config objects would be a better way to go.
>
>> 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.
I think layer groups should not be handled in the core API, but rather in the
UI component of the library. I can definitely see the utility in being able to
define groups of mutually exclusive layers, though.
Cheers
Paul
> 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.lemo...@camptocamp.com
> http://www.camptocamp.com
__________________________________________
Paul Spencer
Chief Technology Officer
DM Solutions Group Inc
http://research.dmsolutions.ca/
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
