On 9/30/10 2:55 AM, Peter Robins wrote:
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
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
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
--
Tim Schaub
OpenGeo - http://opengeo.org
Expert service straight from the developers.
_______________________________________________
Dev mailing list
d...@lists.osgeo.org
http://lists.osgeo.org/mailman/listinfo/openlayers-dev
