On Wed, Jul 10, 2013 at 8:52 AM, Roy Braam <roybraam@anonymised.com> wrote:
Hi,
The scalehint in the WMS-GetCapabilities response is not what i was
expecting. After reading the JIRA ticket:
https://jira.codehaus.org/browse/GEOS-5830 and the suggested pull request
https://github.com/geoserver/geoserver/pull/244 i'm still a bit
confused...
The WMS 1.1.1 specs (7.1.4.5.8) says:
*"The following definition of Scale Hint is recommended. Consider a
hypothetical map with a given Bounding Box, width
and height. The central pixel of that map (or the pixel just to the
northwest of center) will
have some size, which can be expressed as the ground distance in meters of
the southwest
to northeast diagonal of that pixel. The two values in ScaleHint are the
minimum and maximum recommended
values of that diagonal. It is recognized that this definition is not
geodetically precise,
but at the same time the hope is that by including it conventions will
develop that can be later specified more clearly."*
So, what I was expecting was the scalehint as the diagonal map units of 1
pixel, like how other WMS services use it. But GeoServer is using the
scaledenomination values in the scalehint.
According the specs it's correct (it's just a recommendation) but it's a
bit confusing that it's implemented differently then in other WMS services.
The recommendation above is problematic, and in my opinion should be
ignored.
The strongest argument I can find is a simple one of consistency, but there
are others which are good too.
Consistency wise, GeoServer should use a single way to compute scale
denominators, and that way is the one
suggested by the SLD spec, which has nothing to do with the suggestion
above.
We cannot go out with a suggestion in one place, and then have a client do
a GetStyles operation and encounter
completely different values in the SLD rule's min/max scale denominators.
The second argument pertains more to people that know a bit of geodesy. The
above definition is way more than "not geodetically
precise", it simply has little or no meaning because all depends on where
in the world that central pixel is.
Say I have a world wide map depicted in EPSG:4326 (not a good choice, but a
common one). In the depiction, all pixels
apparently have the same size. Say, to keep the example easy, that the map
is 360 pixels wide, and 180 pixels height,
and encompasses the whole world, so that each pixel is roughly 1x1 degrees.
If one picks a point along the equator, the diagonal of the pixel is
roughly 157km
(refer to
http://en.wikipedia.org/wiki/Latitude#The_length_of_a_degree_of_latitude),
however
if one picks a pixels that is at 75° of latitude the value is instead 114km.
Now, when a certain value is given to the client, what is the client
supposed to do? Show the map
at lower latitudes, but then refuse to show it as you pan towards north?
(or vice versa?)
This problem is very evident in the case of geographic data, but the issue
remains for projected data
too, because the above definition does say "ground distance", which to me
means real ground
distance, not the projected distance that one sees on the projected map
(and this problem of interpretation
alone is serious, if I'm looking at a map in 3857 the projected distance
can be a few times bigger than
the ground distance if I'm looking at data located north enough in the
world).
The confusion gets even worse in the case of a WMS that allows for
reprojection such as geoserver,
do the scalehint change for the different output projections? (I believe
they stay consistent only if we
always compute the ground distance using proper elliptical geometry)
And if so, is there a way for the client to predict how the values change
for the different output
projections?
The SLD scale computation definition is very imprecise, but has at least
the gift of consistency,
the scale remains the same no matter where I'm looking at the map, and
there are no doubts of what
distance one is supposed supposed to use when looking at projected data too.
If I'm not wrong with the above, the scale hints in WMS are so ill defined
that, imho, we should probably not generate
them in output by default, and if we do, it should be probably left up to
the administrator to choose whether to be consistent
with SLD and its protocol extensions or to follow the WMS definition (and
here too, one should somehow
try to pick up what "ground distance" means in the case of projected data
from the admin again).
Cheers
Andrea
--
Ing. Andrea Aime
@geowolf
Technical Lead
GeoSolutions S.A.S.
Via Poggio alle Viti 1187
55054 Massarosa (LU)
Italy
phone: +39 0584 962313
fax: +39 0584 1660272
mob: +39 339 8844549
http://www.geo-solutions.it
http://twitter.com/geosolutions_it
-------------------------------------------------------
