Hi Andrea,
Thanks for your complete answer!
I totally agree, the recommendation is not only ill defined but also
problematic and inconsistent...
I understand the discussion and the arguments, technically geoserver is doing
the correct thing.
The only problem is the implementation differences cross WMS 1.1.1 servers. The
problematic, ill defined recommendation is expected,
because people are used to that wrong recommendation....
For me the option you described: 'let the admin choose if and how the scalehint
is propagated in the GetCapabilities' would be the best solution....
Properly not using WMS 1.1.1 and/or not using the ScaleHint client side is even
better.... :)
Roy
_____
From: Andrea Aime [mailto:[email protected]]
To: Roy Braam [mailto:[email protected]]
Cc: Geoserver-devel [mailto:[email protected]]
Sent: Wed, 10 Jul 2013 14:23:04 +0100
Subject: Re: [Geoserver-devel] Scalehint in WMS getCapabilities
On Wed, Jul 10, 2013 at 8:52 AM, Roy Braam <[email protected]> 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
--
==
Our support, Your Success! Visit http://opensdi.geo-solutions.it for more
information.
==
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
-------------------------------------------------------
------------------------------------------------------------------------------
See everything from the browser to the database with AppDynamics
Get end-to-end visibility with application monitoring from AppDynamics
Isolate bottlenecks and diagnose root cause in seconds.
Start your free trial of AppDynamics Pro today!
http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
_______________________________________________
Geoserver-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/geoserver-devel
