On Tue, Sep 21, 2010 at 11:02 AM, Peter Robins <openlay...@peterrobins.co.uk> wrote: > 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.
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.lemo...@camptocamp.com http://www.camptocamp.com _______________________________________________ Dev mailing list d...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/openlayers-dev
