Jesse Eichar ha scritto: > I've been using SLD 1.0 page 26 for the basis of my research. But > I'd like to look at map server as well since it is one of the big Web > Map Servers out there. If their calculation fits into the spec it > would be nice to align with them as much as possible. I personally > would like to see the scale be calculated based on the > specification. As you know I am primarily a client developer and > having to special case for each server is a real pain. > > With regard to projection deformations. Lets see if mapserver does > that if not then I wouldn't worry about it either. (at least if it > is more work).
The Mapserver code to compute scales is located in mapscale.c Mapserver does not take care of projection deformations. Yet, it does not use the standard SLD method neither :-( For projected maps, it applies the following formula: scale = rw / iw * (dpi * inchesPerUnit) rw: map envelope width iw: image width in pixels dpi: 75! inchesPerUnit: as the name says, the scale can be computed in different units, whilst SLD assumes meters afaik For lat/lon maps, the formula is: scale = rw / iw * (dpi * sqrt((1 + cos^2(cLat))/2) * inchesPerUnit) inchesPerUnit: in this case is the size of one degree of latitude at the equator in inches cLat: latitude of the central parallel crossing the rendered map bounds Here the sqrt(...) takes into account that the actual diagonal of a 1*1 degree square varies according to the latitude and adjusted for that (r * cos(cLat) is the radius of the parallel if r is the radius of the earth, the rest is the Pythagorean theorem). Unfortunately this is not what SLD suggests. As David noted, the SLD suggestion is incorrect from mathematical point of view (it always uses the radius of the earth no matter what the latitude is), but has the merit of a stable scale when panning, whilst this one will provide a different scale as you move from the equator to the poles. Soo... it seems everybody is doing its own :-( I'd suggest two possible course of action: * fix the current algorithm to handle wide area, add the standard SLD way to compute the scale, and have a rendering hint to choose which one we do want * the same as above, but move the above in a separate class hierarchy where everybody can implement his scale computation algorthm according to his preferences. The base would be the OGC one, since it's simple, fast and very tolerant about coordinates out of the CRS definition area. Feedback and suggestions welcomed, I would like to fix this before releasing Geoserver 1.5.x and 1.4.x (yes, I want a stable and simple scale computation alghoritm in 2.2.x too) :-) Cheers Andrea ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Geotools-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geotools-devel
