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

[Eric Lemoine]

Hi

Thanks a lot for your feedback Peter.

On Sunday, September 19, 2010, Peter Robins
<openlayers at peterrobins.co.uk> wrote:
> On 17 September 2010 12:33, Eric Lemoine <eric.lemoine at camptocamp.com> wrote:
>> a projection. But, to be able to support
>>
>> new OpenLayers.Map({
>>    div: "map",
>>    layers: new OpenLayers.Layer.Google()
>>    center: [0, 0]
>> });
>>
>> we could introduce a kind of fallback mechanism, where the map gets
>> the projection from the first layer (the one at index 0 in the layers
>> array) when it has no projection itself.
>
> this seems contradictory to me. On the one hand, you're saying that
> all layers are equal, but then you're saying the first layer somehow
> has priority - so all layers are equal, but some are more equal than
> others :-)

My previous email has this sentence:

"But again, I think that the case where no projection is set in the
map should the exception rather than the rule, it should be seen as a
convenience for creating a map with a minimum of configuration."

So what I'm saying is that we want to support the "all layers are
equal" case in OL 3; but, to enable easy configuration in certain
(actually not so exceptional) cases, the map can also work with a
"master layer".

Also, I've started working on code since I wrote this RFC email, and
the design I've come up with so far is a bit different than that
previously described. See below.

> I agree that it would be better to make things more flexible, and not
> make the baselayer/overlay distinction compulsory. But this
> distinction is surely useful, and ISTM that getting rid of it is going
> too far the other way. It's surely a common use case that people want
> to display some vectors over a fixed raster like Google. The raster
> layer is only available in a limited number of
> projections/resolutions, and the vectors have to adapt themselves to
> that. So in this case the raster layer not the vector layer has to
> determine the map projection/resolution. These 2 layers are not equal,
> and I don't see the point in pretending they are. This is implicit in
> your example above, but would it not be better to make it explicit by
> distinguishing between the base/master/inflexible/whateverothername
> layer and the overlay/flexible/whateverothername one?

Yes, I actually agree with you that entirely getting rid of the
baselayer/overlay paradigm may be going too far. For example we
certainly need that commercial and cached layers determine the
projection and resolutions.

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.

> Having said that, I agree that it would be nice to be able to combine
> different layers with different projections in the same map, and be
> able to toggle between them. For example, a walking route map in the
> Pyrenees could enable the user to look at the French map in the French
> projection for French sections, and to switch to the Spanish
> map/projection for the Spanish sections. (It would also be a good
> tutorial on how different projections represent the earth in different
> ways.)
>
> On the subject of layers, it would be nice to have a distinction
> between source/server and OL layers. Google for example has several
> different layers, and it would be nice to be able to set these up in a
> layerswitcher control and allow the user to change between them
> without the programmer having to set up a separate OL layer for each
> one.

This, I believe, would imply major changes to the current code. And it
would possibly require Google-specific code in the LayerSwitcher
control.

> The same applies to WMS servers, where it's common to have
> different layers for road, rail, river etc. It would simplify things
> if the programmer could just define 1 OL layer for this, and then have
> the layerswitcher determine the LAYERS parameter. (Ok, I know this can
> be done at the moment with custom code, but it would be nice if it
> could be simple to set up.)

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.

> Another point about vectors would be that a vector source too might be
> available in several different projections. Depending on
> circumstances, it might be better to fetch the file in the new
> projection if available rather than rely on the appropriate
> transformation logic (proj or whatever) being present for those
> particular projections. So a way to specify this layer as supporting
> projections a and b, otherwise use transform().

Right, good point.

>
> As the EPSG has now set up a code for 'Google Mercator' (3857), ISTM
> it would be better to use that and remove the fictitious 900913. Also,
> get rid of the 'spherical mercator' param, which is inherent in the
> projection and should not need to be specially defined.

Right too.


Again, any comment on the described design is very welcome. And please
tell me if you're interested in working on code, I can open up my
development branch.

Cheers,




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