On Tue, Sep 21, 2010 at 7:54 PM, Peter Robins <openlay...@peterrobins.co.uk> wrote: > On 21 September 2010 12:34, Eric Lemoine <eric.lemo...@camptocamp.com> wrote: >> Right. Do you think the proposed design doesn't address this scenario? > > not sure :-) Google's overlay layers are commercial layers but should > not be part of the Google master group, as then you wouldn't be able > to overlay them. As long as the proposal can handle that, no problem.
Commercial layers being in the master group is the default, but this is configurable. > >>> 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? > > yes. Setting projection on the layer doesn't help in the case where > you have more than one source in different projections (though I agree > that's probably not very common). IMO it also confuses things, as it's > not the projection that the feature coordinates of the layer are in, > which will always be the same as the map projection.IMO it would be > better if this were renamed sourceProjection or some such. If you add > the ability to reproject maps, then the projection of the vectors > currently in the layer will have to be transformed from the old map > projection to the new. The current layer projection property won't be > of use for this. I fully agree with this. If you care enough about it then feel free to create a ticket with OpenLayers 3.0 for the milestone. -- 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
