On 20 September 2010 07:23, Eric Lemoine <eric.lemo...@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 :-( _______________________________________________ Dev mailing list d...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/openlayers-dev
