On 29 September 2010 00:15, Tim Schaub <tsch...@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'. _______________________________________________ Dev mailing list d...@lists.osgeo.org http://lists.osgeo.org/mailman/listinfo/openlayers-dev
