I'm increasingly persuaded that we're dealing with three behaviours
here: 'pure hue' behaviour ('360'), RGB behaviour ('#FF0000') and
hexadecimal behaviour ('0xFFFFF000'). 'Pure hue' probably passes the
value to the API 'color generator' without affecting saturation or
lightness values, and RGB passes a base colour that is
'processed' (pure hue extracted from the base colour, and the
remainder (saturation and lightness) passed to the other style HSL
elements. I'm almost certain that the API engine expects the
hexadecimal input to contain ~all three~ behaviours - hue, saturation
and lightness - as well as an 'override' factor (any hexadecimal 9
characters or over overrides default Google colours - behaving in the
same way as RGB input).I'll play a bit more, but I'm not sure how far I'm going to take this... I only need the 'override factor' for roads (high colour difference between highway/local road signs), and since the saturation in my colours is set to minimal levels, the difference is not so remarkable. On Aug 27, 11:11 am, Sefu <[email protected]> wrote: > ...so basically, the 'Fxxxxxxx' has to be a multiple of anything > between 0(1?) and 360... and that multiplying number has to be > something large enough to create an 8-digit hex number (if it was a > constant, things would be easy - but I think not). '0' == 'no > change' (default map hue). Yet when I take a '360-divisible' number > and transform it to hex (4293918720 - 360 == 4293918360 == 0xffeffe98) > it won't work - the example I gave actually breaks the API engine (no > hue) - btw, '4293918360' entered as a decimal value won't work either. > '0xF000F0F0' should work if all that was important that the hex number > be a '360-multiple', but it doesn't. So wee can conclude that the > first character must be an 'F', and it seems that those last two > characters have to be '00'. > > ... but it still isn't that easy! '0xF00FF011' ~still~ results in pure > red (through to 0xF00FF077 and 0xF00FF07F), but if the seventh > character is '8' and above, a 'color shift and add' is provoked... > (resulting color: #4400FF). > > Still twiddling... > > On Aug 27, 8:49 am, William <[email protected]> wrote: > > > > > On Aug 27, 12:08 am, Sefu <[email protected]> wrote: > > > > Now all I have to do is convert a 6-character RGB hexidecimal color > > > code to an 8-character hexidecimal string. > > > I tried something which takes a hue (0 ... 360) and converts it to a 8- > > character hex string, using this series of numbers: > > > 0xF0000000 = hue 240 > > 0xF0000100 = hue 136 = (240+256) mod 360 > > 0xF0000200 = hue 32 = (136+256) mod 360 > > etc > > > This series generates every 8th hue, which produces a range of 45 hues > > (0,8,16,24 ...,352,360) > > > On the Paris map it nearly works, except for the water where the hue > > chosen is "off by one", so I had to adjust that hue: > > >http://www.william-map.com/20100827/1/paris.htm > > > ... -- You received this message because you are subscribed to the Google Groups "Google Maps JavaScript API v3" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-maps-js-api-v3?hl=en.
