Hey-
I think we would all agree that we could start strict, make sure we
cover all the functionality we want with a clean API, and then begin a
discussion about convenience.
The key part for me starting out is that we agree that map properties
rule (already agreed) and get rid of all the coupled default properties
(projection is related to units and extent and resolutions).
If we require just "projection" as a map config property to start, we
can get most of what we need by providing a lookup of units and valid
extent for common CRS identifiers.
Whether we go with Paul's suggestion of map sub-classes, provide factory
functions for common configurations, or bake in some more magic is up
for discussion later.
I know I started with the masterLayerIndex suggestion at the sprint.
This was largely prompted by Chris' (valid) suggestion for Google layer
convenience. I think now that it makes sense to defer this discussion
until a bit more is implemented.
Tim
On 9/23/10 9:34 AM, Paul Spencer wrote:
Hi Eric,
On 2010-09-23, at 1:22 AM, Eric Lemoine wrote:
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.
I guess I feel that if there is a magic layer that can override the map then we
haven't really made any fundamental change from the 2.x baseLayer concept. I
understand that this is entirely optional but I think will be a source of
confusion in the long run. Just adding a layer to a Map should not change the
fundamental behaviour of the Map.
My counter proposal to master layers would be to introduce sub-classes of Map
that are pre-configured for some scenarios or preset blocks of options that can
be passed to a Map constructor. This might look like:
var map = new OpenLayers.Map.Google({
// additional user options
});
or
var options = OpenLayers.Util.extend(OpenLayers.Config.Google, {
// additional user options
});
var map = new OpenLayers.Map(options);
or
var map = new OpenLayers.Map({
config: OpenLayers.Config.Google
// additional user options
});
In both cases, it is clear that the *Map* is going to be configured
Google-style with preset resolutions, projection etc.
BTW I'm not sure that having OpenLayers.Map.Google is the right naming choice
:) Probably preset config objects would be a better way to go.
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.
I think layer groups should not be handled in the core API, but rather in the
UI component of the library. I can definitely see the utility in being able to
define groups of mutually exclusive layers, though.
Cheers
Paul
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
__________________________________________
Paul Spencer
Chief Technology Officer
DM Solutions Group Inc
http://research.dmsolutions.ca/
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
