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

[Tim Schaub]

Hey-

I think we would all agree that we could start strict, make sure we 
cover all the functionality we want with a clean API, and then begin a 
discussion about convenience.

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.

Whether we go with Paul's suggestion of map sub-classes, provide factory 
functions for common configurations, or bake in some more magic is up 
for discussion later.

I know I started with the masterLayerIndex suggestion at the sprint. 
This was largely prompted by Chris' (valid) suggestion for Google layer 
convenience.  I think now that it makes sense to defer this discussion 
until a bit more is implemented.

Tim

On 9/23/10 9:34 AM, Paul Spencer wrote:
> Hi Eric,
>
> On 2010-09-23, at 1:22 AM, Eric Lemoine wrote:
>
>> 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.
>
> 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.lemoine at camptocamp.com
>> http://www.camptocamp.com
>
>
> __________________________________________
>
>     Paul Spencer
>     Chief Technology Officer
>     DM Solutions Group Inc
>     http://research.dmsolutions.ca/
>
> _______________________________________________
> 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.