Style Colours

[Cameron Price-Austin]

Hi,

I've noticed that the colours I specify in the map styles aren't necessarily the colours which are displayed.

For example, as a simple test, I tried to make the water, roads and landscape of a map all pure red using the following style definition:

[

   {

      featureType : "water",

      elementType : "all",

      stylers : [

         { hue : "#FF0000" },

         { saturation : 100 },

         { lightness : 0 },

         { gamma : 1.0 }

      ]

   },

   {

      featureType : "road.highway",

      elementType : "all",

      stylers : [

         { hue : "#FF0000" },

         { saturation : 100 },

         { lightness : 0 },

         { gamma : 1.0 }

      ]

   },

   {

      featureType : "road.arterial",

      elementType : "all",

      stylers : [

         { hue : "#FF0000" },

         { saturation : 100 },

         { lightness : 0 },

         { gamma : 1.0 }

      ]

   },

   {

      featureType : "landscape.man_made",

      elementType : "all",

      stylers : [

         { hue : "#FF0000" },

         { saturation : 100 },

         { lightness : 0 },

         { gamma : 1.0 }

      ]

   },

   {

      featureType : "landscape.natural",

      elementType : "all",

      stylers : [

         { hue : "#FF0000" },

         { saturation : 100 },

         { lightness : 0 },

         { gamma : 1.0 }

      ]

   }

]

Instead, these elements come out as various shades of red. Why is that? Is there something I'm missing? Why aren't the colours applied uniformly?

[Chris Broadfoot]

On Tue, Jun 14, 2011 at 1:05 PM, Cameron Price-Austin <pric...@gmail.com> wrote:

Instead, these elements come out as various shades of red. Why is that? Is there something I'm missing? Why aren't the colours applied uniformly?

See the docs:

http://code.google.com/apis/maps/documentation/javascript/maptypes.html#StyledMapStylers

Note: while hue takes an HTML hex color value, it only uses this value to determine the basic color (its orientation around the color wheel), not its saturation or lightness, which are indicated separately as percentage changes.

Chris

--
http://twitter.com/broady

[Cameron Price-Austin]

Yeah I read that.

In each feature, I'm specify #FF0000 as the hue (the orientation around the colour wheel) and I'm specifying the saturation as 100 and lightness as 0. I'm also explicitly setting the gamma for each feature.

That being the case, why are the features not the same colour?

[Chris Broadfoot]

saturation, lightness and gamma are relative. Read here again:

http://code.google.com/apis/maps/documentation/javascript/maptypes.html#StyledMapStylers

--
You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-maps-js-api-v3/-/6y3LtylMVWoJ.

To post to this group, send email to google-map...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.

--
http://twitter.com/broady

[Cameron Price-Austin]

Relative to what? The default colour? That seems fairly counter-intuitive. In fact, it makes it almost impossible to explicitly determine the colour of a feature.

Is there a way to reset the defaults? Or at least some kind of table so I can calculate the transforms which would need to be applied to achieve a specific colour?

[Chris Broadfoot]

It might seem that way but makes styling a whole lot easier. If we didn't have relative color styling, then developers would have to specify colors for each specific feature type.

This way, you can say - "I want all roads to be red" - and we'll adjust the type of red for you according to the type of road.

This is an intended limitation designed to minimise the number of cartographically terrible combinations you can come up with.

Chris

On Tue, Jun 14, 2011 at 2:35 PM, Cameron Price-Austin <pric...@gmail.com> wrote:

Relative to what? The default colour? That seems fairly counter-intuitive. In fact, it makes it almost impossible to explicitly determine the colour of a feature.

Is there a way to reset the defaults? Or at least some kind of table so I can calculate the transforms which would need to be applied to achieve a specific colour?

--

You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group.

To view this discussion on the web visit https://groups.google.com/d/msg/google-maps-js-api-v3/-/DLrymj9u528J.

To post to this group, send email to google-map...@googlegroups.com.
To unsubscribe from this group, send email to google-maps-js-a...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.

--
http://twitter.com/broady

[Cameron Price-Austin]

OK, thanks, I appreciate your help.

I still maintain that there are better ways to implement this. The obvious limitation of this approach is, as I said, that where a programmer is given a palette to use by a designer, it prevents the programmer from achieving an exact colour for a feature without manually playing around with the gamma.

Wouldn't a better approach be to use the default gamma if that styler is omitted from the style specification, but permit the user to override it if they choose?

Using your example, if the user says "I want all roads to be red" and specifies the appropriate hue, saturation and lightness (#FF0000, 100, 0) without specifying gamma, then you can automatically adjust the type of red according to the type of road. However if the user explicitly defines gamma as 1.0, surely that should be interpreted as "I want this exact colour, without any adjustment" ?

It doesn't have to be gamma. Perhaps some other styler where, when omitted, you can automatically adjust the colour, but where given, the HSL value should be interpreted literally (e.g. sat and lum are explicit values in the range -100 to 100, rather than percentage changes to some unspecified magic value).

[Rossko]

> I still maintain that there are better ways to implement this. The obvious
> limitation of this approach is, as I said, that where a programmer is given
> a palette to use by a designer, it prevents the programmer from achieving an
> exact colour for a feature without manually playing around with the gamma.

It's worth bearing in mind the 'features' you are wanting to
manipulate have been supplied by cartographers, not programmers. (Map-
making is an art, not just data crunching) The raw data may not even
come in a form suitable for this, and as it comes from different
cartographers all over the world I'll bet Google servers have to work
hard just to hide differences in the data structures and conventions
from us. Then we need to remember the bulk of this data is under
licence from third parties, it's not inconceivable their terms
prohibit too much adulteration. Just saying it might not be
straightforward because of hidden constraints.
I'd say it's more like a facilitator is passing you a pallette that
has been cobbled together to please a number of stakeholders?

[Cameron Price-Austin]

I'd say it's more like a facilitator is passing you a pallette that
has been cobbled together to please a number of stakeholders?

It's not so much that. It's more about matching the look-and-feel of a site where a Google Map will be integrated. 

It's my understanding that that's the purpose of allowing styling in the first place.

I take your point re: the hidden constraints, however we know it's possible to adjust the colours of each feature individually by playing with the HSL and gamma. My point is that by defining the saturation, luminance and gamma as values relative to some hidden default, the output is unpredictable and it's very difficult to achieve a particular colour.