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). My 2 cents. Jesse On 25-Jan-07, at 2:55 AM, Andrea Aime wrote: > Hi all, > today I noticed an error in the streaming renderer > scale computation algorithm. The current algorithm works as follows: > 1 try to gather the area of validity of current projection > 2 if not found, back-project the whole world and use that > as validity area > 3 intersect the map bounds with the validity area, if the > intersection changes the bounds, adjust screen width and height > accordingly so that they are reduced by the same proportion > 4 get lower left and upper right corner of the intersected > area, and compute an orthodromic distance > 5 compute the on screen diagonal distance in meters assuming 90DPI > 6 divide > > Now, point 3 is where the error triggers. Say you have a > -180,-90 to 180,90 rendering area. > The orthodromic distance computed there is not along > a "diagonal" connecting the two points, but along the -180/180 > meridian! This algorithm is broken each time the orthodromic path > connecting the two corners does not look like the diagonal connecting > them on a plate carre map (another way to break it is to use -170,-90, > 170,90 the connecting orthodromic path is outside the "rectangle"). > > This made me think about Jesse asking to compute the scale on the > "center pixel" instead of using the diagonal, which really means using > a short arc crossing the geographic location of the center pixel. > I think we should really do that do avoid the above issue. > > Yet, if we are to play with the SLD recommendations, we should > not compute the orthodromic distance at all. The SLD spec, at page > 27 onwards does not speak about taking into consideration the > projection deformations, and for unprojected data, to assume the > earth as spherical using the wgs84 equator diameter for computation. > What's fun is that in the case of lat/lon data the spec is doing > a bounds width/screen width computation, assuming all pixel as > squares. > This may account for the difference in scale computation > between MapBuilder and Geoserver too (see my other thread on > the geoserver/mapbuilder dev mailing lists). > > Feedback is very much appreciated. I've also opened a jira > issue about this: http://jira.codehaus.org/browse/GEOT-1137 > 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 ------------------------------------------------------------------------- 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
