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

[Peter Robins]

On 29 September 2010 00:15, Tim Schaub <tschaub at opengeo.org> wrote:
> 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.

hm, don't think I'd agree with that. Units are definitely part of a
projection definition, but resolutions or extent? They surely depend
on the server, i.e. the layer. A given server may use Google Mercator,
but for only part of the globe, and may also provide resolutions that
differ from Google's. Google's tiling/resolution system is
mathematically simple and used by other providers, but is not inherent
to the projection. As another example, UTM zones have an extent, but
in practice it's just a guideline and there's no reason why a server
may not go beyond those borders if needed.

Because every map that uses a given server is not going to use all the
available extents/resolutions/projections, ISTM the definition of that
server for that map will have to be defined in the layer corresponding
to the server. If you allow reprojection, then that can only be to a
projection supported by at least one of the layers, so the list of
available projections is simply the sum of what's available in the
layers. The map would store only the current projection. Because
maxExtent is simply a list of coordinates, that can be defined at the
start, stored in the map, and then transformed if the map is
reprojected (with the proviso that the transform logic has to be
available). That will commonly be different from the extent of what's
available on the server(s). Resolutions though is trickier, because
different layers/servers may provide different resolutions. To take an
example, say server A provides 10,20,30,40,50; server B provides
25,30,35,40; say your map is only concerned with 20-35. ISTM that the
best way to handle this is to store only those resolutions you need in
the layers, so the layer for server A would be 20,30, and that for B
would be 25,30,35. Then the map resolutions would again be the sum of
the layers, and there would be no need for a separate list of
resolutions in the map object. If you are allowing reprojection, then
you would have to define this for each projection you want to cater
for. I don't know how common this sort of thing is in practice, but
ISTM the software needs to be able to handle it.

So, I would say, yes, definitely start with something simple and
gradually expand it. Yes, store the available
projections/resolutions/extents for commonly used servers in some kind
of catalogue, so programmers don't have to keep redefining them. Yes,
make it easy to use common defaults. But I'm not sure it's as simple
as saying that 'map properties rule'.