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

[Tim Schaub]

On 9/30/10 2:55 AM, Peter Robins wrote:
> 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

Yes, I agree with what you say below.  I was only talking about deriving 
sensible defaults in the case where no values are given.  The Google 
layer (and other fixed layers) will only be available at limited 
resolutions on the server.  We can also work in functionality to scale 
images to fit whatever resolution the user desires in many cases 
(continuous zoom on the client, limited resolutions on the server).

For EPSG:4326, we could assume [-180, -90, 180, 90] a a max extent if 
none is given.  We could also have a default number of zoom levels (say 
20) and a default zoom factor (2).  We also have a default tile size 
(256x256).  If you assume the user wants to see the whole world one tile 
high, you can derive the rest.

Again, each of these should be configurable when the map is constructed. 
  In the case where values are not given, we can do a fair bit with the 
CRS identifier alone.

The difference between what I sketched out here and what we have now is 
subtle but significant.  We have a default projection, default units, 
default maxResolution, and a default maxExtent.  These things are all 
coupled.  This makes it easy to screw up.

> 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'.
> _______________________________________________
> Dev mailing list
> Dev at lists.osgeo.org
> http://lists.osgeo.org/mailman/listinfo/openlayers-dev


-- 
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.