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

[Eric Lemoine]

On Tue, Sep 21, 2010 at 11:02 AM, Peter Robins
<openlayers at peterrobins.co.uk> wrote:
> On 20 September 2010 07:23, Eric Lemoine <eric.lemoine at camptocamp.com> wrote:
>> In the code I've started to write I'm introducing two new notions:
>> layer groups, and master layers. A group is a collection of layers
>> that are mutually exclusive - only one layer is turned on at any given
>> time. A master layer determines the map projection and resolutions.
>> The map can work with a master layer, and it can also work without
>> one. In this latter case the map itself determines the projection and
>> resolutions, this is how we handle the "all layers are equal" case.
>> Master layers are mutually exclusive, and they're all included in a
>> built-in group, the "master" group. If layers of the "master" group
>> are added to the map, the map switches to "controlled by master layer"
>> mode, and it switches back to "all layers are equal" mode when it does
>> no longer include layers of the "master" group. By default commercial
>> layers are in the "master" group, and the application developer can
>> add more layers to this group if needed. The concept of master layer
>> is different than that of base layer in two ways: the map doesn't
>> require a master layer, and master layers aren't necessarily at lower
>> z-indexes than the other layers.
>
> there is another scenario. Google, for example, also has overlay
> layers, which are also only available in one projection, but which are
> intended to be used in conjunction with their 'baselayers'. I've never
> tried using these in OL, but in principle it should be possible to
> overlay these or other similar layers (rasters with a transparent
> background) on a mapbase from another source, so long as they're in
> the same projection. So these rasterised vectors would have to have
> the same projection as the baselayer, as they're not transformable
> like vectors, but would not be part of your mutually exclusive
> baselayer group.

Right. Do you think the proposed design doesn't address this scenario?
If so, could you elaborate a bit?

>
> I suppose we just have to try and be as flexible as possible, whilst
> making it as simple as possible to enable common use cases like
> 'display these vectors on these rasters'.
>
>> Some time ago we decided to keep the LayerSwitcher control simple and
>> stupid. Fancy layer switchers, with support for groups, drag&drop,
>> legends, etc. are to be implemented in other libs, such as GeoExt.
>
> The layerswitcher was just an example. Vectors would be another
> example of the advantage of separating OL layer from source. A vector
> layer might take data from several different sources, which might be
> in different projections - the projection is a property of the source
> not the layer. The vector layer doesn't need a projection property, as
> it will always be that of the map, as determined by the baselayer (or
> whatever you want to call it). The read() function should use the
> projection defined in the source file (or the default for formats like
> kml that are always in one (non-)projection), and do the appropriate
> transforms. The current requirement to specify internal/external
> projections shouldn't be necessary.

Our BBOX, Fixed, and Save strategies already have support for this. If
the vector layer has a projection defined then the strategy will do
the transformation. Are you thinking of something else?

-- 
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