On Thursday, September 23, 2010, Paul Spencer <pspen...@dmsolutions.ca> wrote:
> Hi Eric and others,
Hi Paul
> I'm just catching up on this thread and I have some comments that I would
> like to add.
>
> I'd really like to see 3.0 put control into the hands of the map and do away
> with 'magic' behaviour. I think there are other ways to provide convenience
> (define a new map sub-class with the appropriate projection/resolutions for
> instance) without breaking a nice clean API. So for the record, I think it
> should be required to provide the projection when defining a map and not
> magically pick it up from some sort of special layer.
Determining ways to provide convenience is key to the discussion. At
this point I have no other solution than having
fixed-projection/resolutions layers determine the map projection and
resolutions. I'm interesting in other ways.
> Also, I'm not convinced that introducing the concept of master layers and
> master groups is a good thing. I think there are some very straight-forward
> rules that can be applied to a layer to determine if it should be displayed
> at the current resolution and there is no need to add the concept of mutual
> exclusion in the core library (i.e. can it display at this resolution, can it
> be displayed in the current projection, is it within maxExtent).
The goal of layer groups isn't related to resolutions, maxExtent, etc.
It is just a way for the user to create mutually exclusive layers, and
have radio buttons in the layer tree.
The "master" group just aims to identify master layers.
And I'd like to say again that the map doesn't require a master layer.
If there's no master layer the map determines the projection and
resolutions.
>User controls and the application developer should handle this kind of thing.
>From the point of view of the library, it shouldn't matter if there is more
>than one non-transparent layer displayed on top of each other and it (the
>library) should not prevent it.
Agreed. I think the proposed design does go in that direction. It just
introduces master layers to provide convenience when working with
fixed-projection/resolutions layers. And, with the proposed design,
the user can even use fixed-resolutions/projection layers without them
being master layers, by just not making them part of the "master"
group (new Google("gmap", {group: null}).
Again, if you have other ways to provide convenience I'm interested.
Thanks a lot for you feedback Paul!
--
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
