Hi, I do not like using "scale" when it means the number in the denominator. Even Mapnik css seems to be using [scale-denominator>=400000] as an alternative for [zoom>10] http://mapnik-utils.googlecode.com/svn/trunk/serverside/cascadenik/doc/index.html.
However, the battle may be lost. Mapserver did change from MAX/MINSCALE into MAX/MINSCALEDENOM a few years ago but now the basemap style system seems to use "scale" https://github.com/mapserver/basemaps/blob/master/generate_style.py. Same thing with the Scribe styles if this is about those https://github.com/mapgears/scribeui/blob/master/application/workspaces/templates/Standard/scales It is not so hard to understand what scale=20000 means, but if someone says "Show layer at bigger scale than 20000" it is impossible to know if the number should be made bigger or smaller. "When scale-denominator is greater than 20000" is at least unambiguos. But as I said, I believe that the battle is lost anyway. Best reason to use "scale-denominator" might be that cascadenik css is using it but the de-facto standard in GIS is that the second implementation brakes the interoperability. -Jukka Rahkonen- ________________________________ Justin Deoliveira wrote: > I certainly don't have a strong opinion but will offer it as another view. > While I realize it's technically incorrect to use the term "scale" i would > vote for sticking with it as is. Rationale being: > - it is very common mis-nomenclature > - it is the most readable while still adequately terse > I think the second point is not to be overlooked since readability and > compactness are two of the main reasons that css based styling paradigm is so > attractive. And I think the spirit of the language was derived more from > "what's easy" rather than "what is technically correct". $0.02 On Tue, Sep 24, 2013 at 11:01 AM, Andrea Aime <[email protected]<mailto:[email protected]>> wrote: On Tue, Sep 24, 2013 at 6:51 PM, David Winslow <[email protected]<mailto:[email protected]>> wrote: Sorry, I forgot to reply to this email. Here's the plan (stop me if I'm going off the rails.) The new name for this property will be @scale-denominator and @scale will be ignored (just as if, right now, you made a style with @rutabaga). However, due to the likelihood of changing style semantics, I'm also adding support for generating warnings along with a style (as opposed to the current model where either your style fails to parse or you get an SLD document out. Notifying users of @scale that they need to switch to @scale-denominator will be the first but not the only use of this mechanism, which gives us a little more flexibility in changing the language without leaving existing users stranded. Nice, but can I propose a slightly different behavior? When you see @scale, treat it as @scale-denominator, but let's remove it from the docs and issue the warning. At least, those having existing CSS styles won't have to rewrite them all right away, and besides, 2.4.0 is out, we have to maintain backwards compatibility at this point. 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<tel:%2B39%200584%20962313> fax: +39 0584 1660272<tel:%2B39%200584%201660272> mob: +39 339 8844549<tel:%2B39%20%C2%A0339%208844549> http://www.geo-solutions.it http://twitter.com/geosolutions_it ------------------------------------------------------- ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60133471&iu=/4140/ostg.clktrk _______________________________________________ Geoserver-devel mailing list [email protected]<mailto:[email protected]> https://lists.sourceforge.net/lists/listinfo/geoserver-devel -- Justin Deoliveira Vice President, Engineering | Boundless [email protected]<mailto:[email protected]> @j_deolive<https://twitter.com/j_deolive> ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk _______________________________________________ Geoserver-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/geoserver-devel
