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

[Peter Robins]

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.

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.

> tell me if you're interested in working on code, I can open up my
> development branch.

interested yes. How much time I will have is quite another matter :-(