[OpenLayers-Dev] Re: [OpenLayers 3] code sprint summary, and request for comments

[Paul Spencer]

Hi Eric and others,

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.

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).  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.

Finally, a little off topic on the original thread - I think that we should be removing all user controls from OpenLayers (the library) and creating a separate library or build target or something that just includes the user controls (perhaps OpenLayersUI.js ?) so that we really focus the API design of the core library on being an API.

My $0.02

Cheers

Paul

On 2010-09-22, at 11:31 AM, Eric Lemoine wrote:

> On Tue, Sep 21, 2010 at 7:54 PM, Peter Robins
> <openlayers at peterrobins.co.uk> wrote:
>> On 21 September 2010 12:34, Eric Lemoine <eric.lemoine at 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.lemoine at camptocamp.com
> http://www.camptocamp.com
> _______________________________________________
> Dev mailing list
> Dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev


__________________________________________

   Paul Spencer
   Chief Technology Officer
   DM Solutions Group Inc
   http://research.dmsolutions.ca/