[Geoserver-devel] Little annoying thing about the CSS scale treatment

Hi,
was making some CSS styles today and kept on adding rules like:

[@scale < 75000]

After a while something inside me rebelled… this is wrong.
The scale threshold I’m looking for is 1/75000=0,000013333, 75000 is the
scale denominator.

For the cartographer that actually knows what a scale is, and to avoid spreading
even more confusion on the topic of scales (before people start really thinking
the denominator and the scale are the same thing), can we deprecate scale and
use, uh, whatever, scaled, scale-denominator, or even just sd instead?

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


Hi Andrea,
I have to admit pretty much everyone I’ve ever heard has used “scale” rather than “scale denominator”. I think this is probably a lost cause. :slight_smile:

However if you do change it, I’d suggest against “sd”; while terse, it’s unclear what it is without knowing the lexicon. From your options “scale-denominator” would be the clearest to users I think even if verbose.

Cheers,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

On 17 September 2013 16:18, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
was making some CSS styles today and kept on adding rules like:

[@scale < 75000]

After a while something inside me rebelled… this is wrong.
The scale threshold I’m looking for is 1/75000=0,000013333, 75000 is the
scale denominator.

For the cartographer that actually knows what a scale is, and to avoid spreading
even more confusion on the topic of scales (before people start really thinking
the denominator and the scale are the same thing), can we deprecate scale and
use, uh, whatever, scaled, scale-denominator, or even just sd instead?

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



LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk


Geoserver-devel mailing list
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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.

···

On Tue, Sep 24, 2013 at 12:37 PM, Jonathan Moules <jonathanmoules@anonymised.com> wrote:

Hi Andrea,
I have to admit pretty much everyone I’ve ever heard has used “scale” rather than “scale denominator”. I think this is probably a lost cause. :slight_smile:

However if you do change it, I’d suggest against “sd”; while terse, it’s unclear what it is without knowing the lexicon. From your options “scale-denominator” would be the clearest to users I think even if verbose.

Cheers,
Jonathan

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

David Winslow

Boundless - http://boundlessgeo.com/

On 17 September 2013 16:18, Andrea Aime <andrea.aime@anonymised.com> wrote:

Hi,
was making some CSS styles today and kept on adding rules like:

[@scale < 75000]

After a while something inside me rebelled… this is wrong.
The scale threshold I’m looking for is 1/75000=0,000013333, 75000 is the
scale denominator.

For the cartographer that actually knows what a scale is, and to avoid spreading
even more confusion on the topic of scales (before people start really thinking
the denominator and the scale are the same thing), can we deprecate scale and
use, uh, whatever, scaled, scale-denominator, or even just sd instead?

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



LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of tutorials including VisualStudio 2012, Windows 8, SharePoint
2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes
Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13.
http://pubads.g.doubleclick.net/gampad/clk?id=58041151&iu=/4140/ostg.clktrk


Geoserver-devel mailing list
Geoserver-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

On Tue, Sep 24, 2013 at 6:51 PM, David Winslow <dwinslow@anonymised.com>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
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it

-------------------------------------------------------

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 <andrea.aime@anonymised.com> wrote:

On Tue, Sep 24, 2013 at 6:51 PM, David Winslow <dwinslow@anonymised.com> wrote:


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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive

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
fax: +39 0584 1660272
mob: +39 339 8844549

http://www.geo-solutions.it
http://twitter.com/geosolutions_it


On Tue, Oct 1, 2013 at 3:25 PM, Justin Deoliveira <jdeolive@anonymised.com

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".

I could live with that... but we should at least add an explanation in the
guide, at least to
tame those that really know what a scale really is :wink:

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

-------------------------------------------------------

This transmission is intended for the named addressee(s) only and may contain sensitive or protectively marked material up to RESTRICTED and should be handled accordingly. Unless you are the named addressee (or authorised to receive it for the addressee) you may not copy or use it, or disclose it to anyone else. If you have received this transmission in error please notify the sender immediately. All email traffic sent to or from us, including without limitation all GCSX traffic, may be subject to recording and/or monitoring in accordance with relevant legislation.

···

On 1 October 2013 14:28, Andrea Aime <andrea.aime@anonymised.com> wrote:

On Tue, Oct 1, 2013 at 3:25 PM, Justin Deoliveira <jdeolive@anonymised.com> wrote:

Yes, all three of them! :slight_smile:

But yes, that seems like the best idea on all fronts.


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
Geoserver-devel@anonymised.comsts.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

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”.

I could live with that… but we should at least add an explanation in the guide, at least to
tame those that really know what a scale really is :wink:

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


On Tue, Oct 1, 2013 at 7:28 AM, Andrea Aime <andrea.aime@anonymised.com>wrote:

On Tue, Oct 1, 2013 at 3:25 PM, Justin Deoliveira <
jdeolive@anonymised.com> 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".

I could live with that... but we should at least add an explanation in the
guide, at least to
tame those that really know what a scale really is :wink:

Right, definitely on board with documenting it clearly in the guide.

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

-------------------------------------------------------

--
*Justin Deoliveira*
Vice President, Engineering | Boundless
jdeolive@anonymised.com
@j_deolive <https://twitter.com/j_deolive&gt;

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 <andrea.aime@anonymised.com<mailto:andrea.aime@anonymised.com>> wrote:
On Tue, Sep 24, 2013 at 6:51 PM, David Winslow <dwinslow@anonymised.com<mailto:dwinslow@anonymised.com>> 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
Geoserver-devel@lists.sourceforge.net<mailto:Geoserver-devel@anonymised.comrge.net>
https://lists.sourceforge.net/lists/listinfo/geoserver-devel

--
Justin Deoliveira
Vice President, Engineering | Boundless
jdeolive@anonymised.com<mailto:jdeolive@anonymised.com>
@j_deolive<https://twitter.com/j_deolive&gt;