JSON-encoded url's blocked/broken by some 3g/Edge network carriers

[Sefu]

This thread is a continuation of another now incorrectly-titled one:
we've managed to narrow down the problem since then.

I've used Google's styledMap tools to make a custom map for my
website, but it is not working for telephones linked to a (French) 3G/
Edge network. The problem seems to be that the carriers here are
either blocking or corrupting Google's styled map tile requests,
example:

http://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=s.t:5|p.h:%23ff8000|p.s:49|p.l:60,s.t:82|p.s:-30|p.h:%236eff00|p.l:-5,s.t:82|s.e:l|p.s:-30|p.h:%236eff00|p.l:-20,s.t:3|s.e:g|p.h:%23ff8800|p.s:-69,s.t:3|s.e:l|p.h:%23ff8800|p.s:-69,s.t:2|s.e:g|p.h:%23ff8800,s.t:33|p.h:%23ff3c00|p.l:-17|p.s:9,s.t:40|s.e:g|p.h:%2333ff00|p.l:30,s.t:65|s.e:g|p.s:80|p.h:%23ff9100,s.t:6|p.h:%230099ff|p.l:40|p.s:25,s.t:1|p.h:%23ff2200|p.s:50&x=4149&y=2818&z=13&s=G


...I have looked for a method for sending tile requests in another
format (I have found none) and have also looked into the 'goo.gl' URL-
shortening service... but I don't see any way of modifying Google map
tile requests before they are sent. Has anyone come across a similar
problem?

Thanks for any insight.

[William]

another thing to check is whether it's just the length of the url, or
something about the characters in styled map url, so you could try the
following url which is less than the 160 characters (sms) and 140
character (tweet) that limit mobile communications. But packet length
limits in the physical network layers shouldn't affect the abstract
Internet Protocol layer??

Styled URL:
http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-GB&apistyle=p.v:off,s.t:1|p.v:on,s.t:6|p.v:on&x=126&y=93&z=8&s=Galileo

Regular Map Tile URL:
http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-GB&x=126&y=93&z=8&s=Galileo

...

[Sefu]

Thanks again, William.

Both URL's seem to be working - perhaps it is the excessive length
that is being blocked by (my) carrier(s)?

On Aug 22, 4:16 am, William <william.g...@gmail.com> wrote:
> another thing to check is whether it's just the length of the url, or
> something about the characters in styled map url, so you could try the
> following url which is less than the 160 characters (sms) and 140
> character (tweet) that limit mobile communications.  But packet length
> limits in the physical network layers shouldn't affect the abstract
> Internet Protocol layer??
>

> Styled URL:http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-GB&apistyle=p.v:off...p.v:on,s.t:6|p.v:on&x=126&y=93&z=8&s=Galileo
>
> Regular Map Tile URL:http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-GB&x=126&y=93&z=8&s...
>
> ...

[Ben Appleton]

For what it's worth, even when fully escaped that URL only amounts to 520 bytes:

http://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=s.t:5%7Cp.h:%23ff8000%7Cp.s:49%7Cp.l:60,s.t:82%7Cp.s:-30%7Cp.h:%236eff00%7Cp.l:-5,s.t:82%7Cs.e:l%7Cp.s:-30%7Cp.h:%236eff00%7Cp.l:-20,s.t:3%7Cs.e:g%7Cp.h:%23ff8800%7Cp.s:-69,s.t:3%7Cs.e:l%7Cp.h:%23ff8800%7Cp.s:-69,s.t:2%7Cs.e:g%7Cp.h:%23ff8800,s.t:33%7Cp.h:%23ff3c00%7Cp.l:-17%7Cp.s:9,s.t:40%7Cs.e:g%7Cp.h:%2333ff00%7Cp.l:30,s.t:65%7Cs.e:g%7Cp.s:80%7Cp.h:%23ff9100,s.t:6%7Cp.h:%230099ff%7Cp.l:40%7Cp.s:25,s.t:1%7Cp.h:%23ff2200%7Cp.s:50&x=4149&y=2818&z=13&s=G

It would be interesting to test the maximum length of a working URL for your 3G network.  I suggest you contact them about this; the more reports they receive the faster they'll fix it.

Note too: goo.gl, bit.ly and other URL shortening services just redirect your browser to the full URL.  So I don't think they will work around your carrier's URL length problem?

- Ben

>
> ...

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

[Sefu]

This is very odd - I am able to download tiles individually (both
fully-escaped and non-escaped), but when I try to download the entire
map, not even one tile will load. The rapidity/volume of the tile
requests must be triggering an 'overload' of some sort that makes the
carrier cut the connection... In the meantime, the iPhone Safari debug
console is very limited (and reporting 'no errors'), so I'm going to
see if there's a more extensive debugging tool.

On Aug 22, 7:14 am, Ben Appleton <apple...@google.com> wrote:
> For what it's worth, even when fully escaped that URL only amounts to 520
> bytes:
>

> http://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=s.t:5%7...<http://mt1.google.com/vt/http:%E2%80%8B/%E2%80%8B/%E2%80%8Bmt1.google...>

>
> It would be interesting to test the maximum length of a working URL for your
> 3G network.  I suggest you contact them about this; the more reports they
> receive the faster they'll fix it.
>
> Note too: goo.gl, bit.ly and other URL shortening services just redirect
> your browser to the full URL.  So I don't think they will work around your
> carrier's URL length problem?
>
> - Ben
>
>
>
> On Sun, Aug 22, 2010 at 2:50 PM, Sefu <the.promena...@gmail.com> wrote:
> > Thanks again, William.
>
> > Both URL's seem to be working - perhaps it is the excessive length
> > that is being blocked by (my) carrier(s)?
>
> > On Aug 22, 4:16 am, William <william.g...@gmail.com> wrote:
> > > another thing to check is whether it's just the length of the url, or
> > > something about the characters in styled map url, so you could try the
> > > following url which is less than the 160 characters (sms) and 140
> > > character (tweet) that limit mobile communications.  But packet length
> > > limits in the physical network layers shouldn't affect the abstract
> > > Internet Protocol layer??
>
> > > Styled URL:

> >http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-GB&apistyle=p.v:off...p.v:on&x=126&y=93&z=8&s=Galileo

>
> > > Regular Map Tile URL:
> >http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-GB&x=126&y=93&z=8&s...
>
> > > ...
>
> > --
> > 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
> > google-map...@googlegroups.com.
> > To unsubscribe from this group, send email to

> > google-maps-js-a...@googlegroups.com<google-maps-js-api-v3%2B unsub...@googlegroups.com>
> > .

[William]

On Aug 22, 2:50 pm, Sefu <the.promena...@gmail.com> wrote:
>
> Both URL's seem to be working - perhaps it is the excessive length
> that is being blocked by (my) carrier(s)?
>

maybe you could try a sequence of increasing length URLs, to see what
length might be a problem? Like this Shakespeare quote:

118 characters
http://www.ask.com/web?q=Life's+but+a+walking+shadow%2C+a+poor+player%2C+that+struts+and+frets+his+hour+upon+the+stage

148 characters
http://www.ask.com/web?q=Life's+but+a+walking+shadow%2C+a+poor+player%2C+that+struts+and+frets+his+hour+upon+the+stage%2C+and+then+is+heard+no+more.

178 characters
http://www.ask.com/web?q=Life's+but+a+walking+shadow%2C+a+poor+player%2C+that+struts+and+frets+his+hour+upon+the+stage%2C+and+then+is+heard+no+more.+It+is+a+tale+told+by+an+idiot

204 characters
http://www.ask.com/web?q=Life's+but+a+walking+shadow%2C+a+poor+player%2C+that+struts+and+frets+his+hour+upon+the+stage%2C+and+then+is+heard+no+more.+It+is+a+tale+told+by+an+idiot%2C+full+of+sound+and+fury

227 characters
http://www.ask.com/web?q=Life's+but+a+walking+shadow%2C+a+poor+player%2C+that+struts+and+frets+his+hour+upon+the+stage%2C+and+then+is+heard+no+more.+It+is+a+tale+told+by+an+idiot%2C+full+of+sound+and+fury%2C+signifying+nothing.

...

[Sefu]

This forum seems to trunciate long URL's (using the goo.gl service?),
but I managed to test your shakespeare quotes by copying the URL after
the redirect... all are working fine. So the problem is... volume?

If I don't find a suitable iPhone webapp debugging tool, the only
other thing I can do is make a series of progressively less-stylised
maps to find out what the carrier will or will not load.

On Aug 22, 7:57 am, William <william.g...@gmail.com> wrote:
> On Aug 22, 2:50 pm, Sefu <the.promena...@gmail.com> wrote:
>
>
>
> > Both URL's seem to be working - perhaps it is the excessive length
> > that is being blocked by (my) carrier(s)?
>
> maybe you could try a sequence of increasing length URLs, to see what
> length might be a problem?  Like this Shakespeare quote:
>

> 118 charactershttp://www.ask.com/web?q=Life's+but+a+walking+shadow%2C+a+poor+player...
>
> 148 charactershttp://www.ask.com/web?q=Life's+but+a+walking+shadow%2C+a+poor+player....
>
> 178 charactershttp://www.ask.com/web?q=Life's+but+a+walking+shadow%2C+a+poor+player...
>
> 204 charactershttp://www.ask.com/web?q=Life's+but+a+walking+shadow%2C+a+poor+player...
>
> 227 charactershttp://www.ask.com/web?q=Life's+but+a+walking+shadow%2C+a+poor+player....
>
> ...

[William]

On Aug 22, 4:06 pm, Sefu <the.promena...@gmail.com> wrote:
> If I don't find a suitable iPhone webapp debugging tool, the only
> other thing I can do is make a series of progressively less-stylised
> maps to find out what the carrier will or will not load.

I don't know any iPhone debugging tools, but the minimal styled
example I tried before was only administrative features:

http://www.william-map.com/20100822/1/admin.htm

...

[Sefu]

There doesn't seem to be any iPhone web debugging app out there....
Your map is working fine, thanks. I'm going to start 'cutting' styles
from mine and see what happens.

[Sefu]

Er, wow.

I trunciated my styles progressively until there was only one style
left remaining... and the map as a whole STILL refused to load. Yet
tiles will load individually:

http://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=s.t:1|p.h:%23ff2200|p.s:50&x=4145&y=2819&z=13&s=Galile

I then stripped ALL styles, and the map suddenly started loading.

The only logical source of the problem I can think of is some sort of
faulty (outdated) compression algorithm used by France's carriers...
individual image requests to a given domain are not compressed, but
multiple requests to the same domain are - resulting in corrupted
url's. If only the iPhone Safari had the 'Activity' window present in
their mac-based app, I could really see what's going on...

[Sefu]

Yet, William, your map is working in my iphone!

All I can do is compare the tile request URL's...

http://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=s.t:1|p.h:%23ff2200|p.s:50&x=4145&y=2819&z=13&s=Galile

... mine
http://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=p.v:off,s.t:1|p.v:on,s.t:6|p.v:on&x=33&y=20&z=6&s=Galileo
... william's

...???

When I replace my styles with yours (taken from the page source),
william, my map will load in iPhone Safari.

(scratching head)

[William]

one difference is that your style has a hue, which gets an escaped
character %23 for the #.

I think it will still work without the #, so maybe you could try:

{ hue: "ff2200" }

instead of

{ hue: "#ff2200" }

...

[Sefu]

Om(f)g.

I found it. A simple, stupid error that still may/may not have
something to do with my carrier.

I noticed that in your custom map, William, you used only a single
'visible' style option - so I reduced my styles to a single (multiple
option) one and started eliminating the options one by one. When I
eliminated the "hue" option the map started working - so I replaced
it, but this time eliminating the "#" symbol from the hex colour code.
The map started working. I then replaced all my styles, but removed
the "#" from all of them - and the map still worked.

This is odd because the "#" is present in the hue colour code in both
the Google Maps v3 documentation and the Styled Map Wizard (http://
gmaps-samples-v3.googlecode.com/svn/trunk/styledmaps/wizard/
index.html)... but again, this "#" problem may only concern my
carrier.

One side effect - when I eliminated the "#", all my orange hues
changed to red... and there may be some other colour changes too.

On Aug 22, 9:09 am, Sefu <the.promena...@gmail.com> wrote:
> Yet, William, your map is working in my iphone!
>

> All I can do is compare the tile request URL's...http://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=s.t:1|p.h:%23ff2200|p.s:50&x=4145&y=2819&z=13&s=Galile
> ... minehttp://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=p.v:off...p.v:on,s.t:6|p.v:on&x=33&y=20&z=6&s=Galileo

[Sefu]

Thanks, William - Great minds think alike, it seems ; )

On Aug 22, 9:43 am, Sefu <the.promena...@gmail.com> wrote:
> Om(f)g.
>
> I found it. A simple, stupid error that still may/may not have
> something to do with my carrier.
>
> I noticed that in your custom map, William, you used only a single
> 'visible' style option - so I reduced my styles to a single (multiple
> option) one and started eliminating the options one by one. When I
> eliminated the "hue" option the map started working - so I replaced
> it, but this time eliminating the "#" symbol from the hex colour code.
> The map started working. I then replaced all my styles, but removed
> the "#" from all of them - and the map still worked.
>
> This is odd because the "#" is present in the hue colour code in both
> the Google Maps v3 documentation and the Styled Map Wizard (http://
> gmaps-samples-v3.googlecode.com/svn/trunk/styledmaps/wizard/
> index.html)... but again, this "#" problem may only concern my
> carrier.
>
> One side effect - when I eliminated the "#", all my orange hues
> changed to red... and there may be some other colour changes too.
>
> On Aug 22, 9:09 am, Sefu <the.promena...@gmail.com> wrote:
>
>
>
> > Yet, William, your map is working in my iphone!
>
> > All I can do is compare the tile request URL's...http://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=s.t:1|p.h:%23ff2200|p.s:50&x=4145&y=2819&z=13&s=Galile

> > ... minehttp://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=p.v:off...p.v:on&x=33&y=20&z=6&s=Galileo

[William]

I think the carrier might be seeing the unsafe characters in the
Styled url (such as the pipe | character) and then encoding the url,
which has the effect of double encoding the # (already encoded as %23,
which would then become %2523)

http://www.w3.org/Addressing/rfc1738.txt

Unsafe:

Characters can be unsafe for a number of reasons. The space
character is unsafe because significant spaces may disappear and
insignificant spaces may be introduced when URLs are transcribed or
typeset or subjected to the treatment of word-processing programs.
The characters "<" and ">" are unsafe because they are used as the
delimiters around URLs in free text; the quote mark (""") is used to
delimit URLs in some systems. The character "#" is unsafe and should
always be encoded because it is used in World Wide Web and in other
systems to delimit a URL from a fragment/anchor identifier that might
follow it. The character "%" is unsafe because it is used for
encodings of other characters. Other characters are unsafe because
gateways and other transport agents are known to sometimes modify
such characters. These characters are "{", "}", "|", "\", "^", "~",
"[", "]", and "`".

All unsafe characters must always be encoded within a URL. For
example, the character "#" must be encoded within URLs even in
systems that do not normally deal with fragment or anchor
identifiers, so that if the URL is copied into another system that
does use them, it will not be necessary to change the URL encoding.

...

[Sefu]

Boy, that may have seemed arrogant of me - was just poking fun at the
fact that we saw the same thing at the same time. I'd still be lost in
the details were it not for your insight - thanks a million!

That problem out of the way, the lack of a "#" character causes other
minor problems elsewhere - transit lines, for example, refuse to be
anything but red when there is a "hue" option present - I even tried
indicating "blue" or "orange" (which worked in earlier experiments),
but rail lines remain stubbornly bright red - I think this concerns
any hue (hex or named) beginning with an alphabetical character (eg
"orange" or "ff9900").

In all, would you think this a problem worthy of announcing to Google,
or should I forward it to my carrier? I am certain that the problem
was the same across three carriers here (SFR, Orange, Virgin) -
perhaps they all are using the same 3g network distributor.

Thanks again, Cheers,

Sefu.

On Aug 22, 9:45 am, Sefu <the.promena...@gmail.com> wrote:
> Thanks, William - Great minds think alike, it seems ; )
>
> On Aug 22, 9:43 am, Sefu <the.promena...@gmail.com> wrote:
>
>
>
> > Om(f)g.
>
> > I found it. A simple, stupid error that still may/may not have
> > something to do with my carrier.
>
> > I noticed that in your custom map, William, you used only a single
> > 'visible' style option - so I reduced my styles to a single (multiple
> > option) one and started eliminating the options one by one. When I
> > eliminated the "hue" option the map started working - so I replaced
> > it, but this time eliminating the "#" symbol from the hex colour code.
> > The map started working. I then replaced all my styles, but removed
> > the "#" from all of them - and the map still worked.
>
> > This is odd because the "#" is present in the hue colour code in both
> > the Google Maps v3 documentation and the Styled Map Wizard (http://
> > gmaps-samples-v3.googlecode.com/svn/trunk/styledmaps/wizard/
> > index.html)... but again, this "#" problem may only concern my
> > carrier.
>
> > One side effect - when I eliminated the "#", all my orange hues
> > changed to red... and there may be some other colour changes too.
>
> > On Aug 22, 9:09 am, Sefu <the.promena...@gmail.com> wrote:
>
> > > Yet, William, your map is working in my iphone!
>
> > > All I can do is compare the tile request URL's...http://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=s.t:1|p.h:%23ff2200|p.s:50&x=4145&y=2819&z=13&s=Galile
> > > ... minehttp://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=p.v:off...

[Sefu]

"I think the carrier might be seeing the unsafe characters in the
Styled url (such as the pipe | character) and then encoding the url,
which has the effect of double encoding the # (already encoded as
%23,
which would then become %2523)"

...that makes perfect sense, and that is no doubt the source of the
problem exactly. But who to send it to: carrier or Google?

[William]

On Aug 22, 6:54 pm, Sefu <the.promena...@gmail.com> wrote:
> ...that makes perfect sense, and that is no doubt the source of the
> problem exactly. But who to send it to: carrier or Google?
>

I'm not certain that's the problem, but I think you should report the
issue to google on the issue tracker, using a single styled url
containing a hue, with a version of the map that has # and another
version without the #. That would allow easy replication of the
problem for google engineers.

http://code.google.com/p/gmaps-api-issues/issues/entry?template=Maps+API+v3+-+Bug

It's difficult to report to the carrier because you saw different
behaviour when you directly visited the url as a link on the browser,
compared to the api usage of the url, as a background-image of a div
style using the url("...") syntax.

...

[Sefu]

I don't see how it can be anything else than the "%" character in the
tile request URL - we've eliminated all other possibilities (the '|'
causes no problems for sure). I think it may have something to do with
mobile providers applying the same encoding protocols they use for SMS
to all network traffic... a practice both lazy and cro-magnon by
today's standards IMHO.

I've submitted an issue - please find it here:

http://code.google.com/p/gmaps-api-issues/issues/list

...it has yet to be approved, but let's see how it goes ; P

Thanks again for all your help.

On Aug 22, 11:08 am, William <william.g...@gmail.com> wrote:
> On Aug 22, 6:54 pm, Sefu <the.promena...@gmail.com> wrote:> ...that makes perfect sense, and that is no doubt the source of the
> > problem exactly. But who to send it to: carrier or Google?
>
> I'm not certain that's the problem, but I think you should report the
> issue to google on the issue tracker, using a single styled url
> containing a hue, with a version of the map that has # and another
> version without the #.  That would allow easy replication of the
> problem for google engineers.
>

> http://code.google.com/p/gmaps-api-issues/issues/entry?template=Maps+...

[William]

On Aug 22, 7:58 pm, Sefu <the.promena...@gmail.com> wrote:
>
> I've submitted an issue - please find it here:
>
> http://code.google.com/p/gmaps-api-issues/issues/list
>
> ...it has yet to be approved, but let's see how it goes ; P
>

OK google was quick to say it was an invalid issue and to follow it up
with the carrier.

You made a list of test urls, saying "all of the above behave as they
should over a normal ISP connection (Numéricable, Free, Orange), but
the 'hue inclusive' pages fail over mobile networks (Virgin, Orange,
SFR, Bouygues)." Have you tried them on Android yet? I read an
article which says Orange now sells Android in France, so you could
visit an Orange shop and try out your test urls with an Android
handset:

http://www.9to5mac.com/orange_france_interview_20278

...

[Sefu]

Ouch. 'Invalid'? That problem means that styledMaps feature is
unusable for any cellphone (and perhaps phone apps) operating in
France - and who knows for how many other operators in other
countries. Okay, there's no problem with their code, their URL
requests should pass... you were right earlier to say that it would be
easier to find a google fix than contact (all the!) operator(s), but I
guess this feature isn't important enough to Google at present for
them to implement a workaround for backwards carriers - true, I
haven't found one French website using styledMaps - nor many others
for that matter.

Disappointed rant aside, now I have to look at my options: either take
this up with (all!) the operators, or somehow find a way to ensure
certain characters are not misinterpreted/misencoded by any operator.

The only way I can do that is capture the returned request URL from
the API before it is sent and modify it (narrowed the problem down to
':%' and not just '%' btw) so that it works with French carriers, but
if I do that, will it break in others? There's no possible way to test
that across all operators.

The only imaginable thing I can do in the immediate future is create a
condition where a styledMap tile request resulting in an error would
make the entire map reload in default format.

[Sefu]

"Have you tried them on Android yet?"

Unless this was an iPhone/Safari-specific behaviour concerning only
Edge/3g connections (it's not as far as I can see), I don't see why
they would work on Android and not the iPhone. Still, I'll ask someone
to test later today.

On Aug 23, 4:59 am, William <william.g...@gmail.com> wrote:

[Sefu]

Uh-oh addendum.

More strange behaviour. Using iPhone's Safari (after cleaning the
iPhone cache of course), when I follow the single-tile 'hue active'
links on the aforementioned 'issues' page (http://code.google.com/p/
gmaps-api-issues/issues/detail?id=2657), I get a 'bad request' error.
Yet when I copy the link and paste it into the iPhone Safari
navigation bar (or that of any other iPhone browser, FTR), I can load
that single tile - but I can never load the entire map.

[William]

On Aug 23, 3:48 pm, Sefu <the.promena...@gmail.com> wrote:
> (narrowed the problem down to ':%' and not just '%' btw)

that's interesting, does %3A for : make any difference?

getting back to first principles, what is the definition of a URI???

Is it the following BNF:
http://tools.ietf.org/html/rfc2396#appendix-A

this definition makes any characters (*uric) acceptable for the query
part of a url, the part following a ?

however the google urls do not have a ? even though there are
arguments on the url like x=2&y=1 etc, therefore the end of the url
may be interpreted as a path segment.

So does it make any difference if you put a ? after the final /

With ?
http://mt0.google.com/vt/?lyrs=m@130&src=api&hl=en-GB&apistyle=s.t:4|p.h:%2300ff00|p.s:50&x=33186&s=&y=22560&z=16&s=Galile

Without ?
http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-GB&apistyle=s.t:4|p.h:%2300ff00|p.s:50&x=33186&s=&y=22560&z=16&s=Galile

...

[William]

On Aug 23, 4:52 pm, Sefu <the.promena...@gmail.com> wrote:
> Using iPhone's Safari (after cleaning the
> iPhone cache of course), when I follow the single-tile 'hue active'
> links on the aforementioned 'issues' page (http://code.google.com/p/
> gmaps-api-issues/issues/detail?id=2657), I get a 'bad request' error.

just to confirm, this 'bad request' error is the http 400 error
message from the google tile server, which looks like this?

Google Error
Bad Request
Your client has issued a malformed or illegal request.

...

[Sefu]

> (narrowed the problem down to ':%' and not just '%' btw)

...I'd put the above statement on hold for the moment - iPhone safari
seems to be able to handle single tile requests without error, and the
gpositioning query (posted in the issues thread by a google dev) is
also a single query... so comparing the two for 'similarities' is
actually pointless. That was how I got my ':%' conclusion, so we can
ignore that for now.

> With ?http://mt0.google.com/vt/?lyrs=m@130&src=api&hl=en-GB&apistyle=s.t:4|p.h:%2300ff00|p.s:50&x=33186&s=&y=22560&z=16&s=Galile
>
> Without ?http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-GB&apistyle=s.t:4|p.h:%2300ff00|p.s:50&x=33186&s=&y=22560&z=16&s=Galile

...both work. But both are single requests, so... were I able to apply
that formula to the entire map, we would be getting somewhere.

What is most frustrating is that I have no access to iPhone, carrier
nor Google logs... I want to see exactly what Url Google is getting.

On Aug 23, 9:00 am, William <william.g...@gmail.com> wrote:
> On Aug 23, 3:48 pm, Sefu <the.promena...@gmail.com> wrote:
>
> > (narrowed the problem down to ':%' and not just '%' btw)
>
> that's interesting, does %3A for : make any difference?
>
> getting back to first principles, what is the definition of a URI???
>
> Is it the following BNF:http://tools.ietf.org/html/rfc2396#appendix-A
>
> this definition makes any characters (*uric) acceptable for the query
> part of a url, the part following a ?
>
> however the google urls do not have a ? even though there are
> arguments on the url like x=2&y=1 etc, therefore the end of the url
> may be interpreted as a path segment.
>
> So does it make any difference if you put a ? after the final /
>

> With ?http://mt0.google.com/vt/?lyrs=m@130&src=api&hl=en-GB&apistyle=s.t:4|p.h:%2300ff00|p.s:50&x=33186&s=&y=22560&z=16&s=Galile
>
> Without ?http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-GB&apistyle=s.t:4|p.h:%2300ff00|p.s:50&x=33186&s=&y=22560&z=16&s=Galile
>
> ...

[Sefu]

Yes, that's it...

[dfd]

Try to replace the hash sign (#) in the color code(s) with a 0x (zero
x)
i.e. p.h:%2300ff00 becomes p.h:0x00ff00

http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-GB&apistyle=s.t:4%7Cp.h:0x00ff00%7Cp.s:50&x=33186&s=&y=22560&z=16&s=Galileo
give nice green railroads...

Kind regards, Frank aka dfd

On Aug 23, 9:00 am, William <william.g...@gmail.com> wrote:

> On Aug 23, 3:48 pm, Sefu <the.promena...@gmail.com> wrote:
>
> > (narrowed the problem down to ':%' and not just '%' btw)
>
> that's interesting, does %3A for : make any difference?
>
> getting back to first principles, what is the definition of a URI???
>
> Is it the following BNF:http://tools.ietf.org/html/rfc2396#appendix-A
>
> this definition makes any characters (*uric) acceptable for the query
> part of a url, the part following a ?
>
> however the google urls do not have a ? even though there are
> arguments on the url like x=2&y=1 etc, therefore the end of the url
> may be interpreted as a path segment.
>
> So does it make any difference if you put a ? after the final /
>

> With ?http://mt0.google.com/vt/?lyrs=m@130&src=api&hl=en-GB&apistyle=s.t:4|p.h:%2300ff00|p.s:50&x=33186&s=&y=22560&z=16&s=Galile
>
> Without ?http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-GB&apistyle=s.t:4|p.h:%2300ff00|p.s:50&x=33186&s=&y=22560&z=16&s=Galile
>
> ...

[Sefu]

Thanks - I tried that, but it throws the colours off - Example page
here:

http://www.paris-promenades.com/pp_tp/index_numto0x.html

...I even tried replacing the hexidecimal with "orange" - google
ignores anything not hexidecimal.

On Aug 23, 9:35 am, dfd <dfddurstew...@googlemail.com> wrote:
> Try to replace the hash sign (#) in the color code(s) with a 0x (zero
> x)
> i.e.  p.h:%2300ff00 becomes p.h:0x00ff00
>

> http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-GB&apistyle=s.t:4%7...

[William]

On Aug 23, 5:31 pm, Sefu <the.promena...@gmail.com> wrote:
> ...both work. But both are single requests, so... were I able to apply
> that formula to the entire map, we would be getting somewhere.
>

Maybe a page that loads the tile the same way as the API?
Here's a page from how the API places the tiles in Firefox (might be
different in iPhone?)

Without ?
http://www.william-map.com/20100823/1/tile.htm

With ?
http://www.william-map.com/20100823/1/tile1.htm

...

[Sefu]

...but again I only get that error with single tile requests from
the... doh!

The Geocode links in the 'issues' page work directly within the page
(no cutting and pasting elsewhere), but the single tile requests
don't... yet when I ~cut and paste~ the same tile request link from
that page and paste it either into the iPhone Safari URL field, it
works... wtf?

This would mean that a link that passes through the iPhone iOS gets
'corrected', and a link that remains untouched within the iPhone
Safari browser gets/remains corrupted. This is looking more and more
like an iPhone issue - have to check the doctypes of both the 'issues'
page and my own.

This is not a Google issue for sure, but I would love to find a google
workaround.

On Aug 23, 9:14 am, William <william.g...@gmail.com> wrote:

[William]

On Aug 23, 6:04 pm, Sefu <the.promena...@gmail.com> wrote:
> ...but again I only get that error with single tile requests
>

here's some pages with 4 tile requests at the same time, do these load
on the iPhone?

http://www.william-map.com/20100823/1/tile4.htm

http://www.william-map.com/20100823/1/tile4q.htm

...

[dfd]

On Aug 23, 9:43 am, Sefu <the.promena...@gmail.com> wrote:
> Thanks - I tried that, but it throws the colours off - Example page
> here:
>
> http://www.paris-promenades.com/pp_tp/index_numto0x.html
>
> ...I even tried replacing the hexidecimal with "orange" - google
> ignores anything not hexidecimal.

Hm, for me your URL with the 0x works (in Germany) in Chrome dev,
also on Android 1.6, i made a screenshot at
http://picasaweb.google.de/lh/photo/SqA2gueNy4xJeAO1IDWQEA?feat=directlink

Sorry, no further idea :-(

Frank aka dfd

[Sefu]

Thanks for your input - I twiddled with the '0x' possibilities a bit,
but the colour that should appear with a certain hexadecimal value
doesn't - I think the google API accepts the '0x' but then trunciates
the first character after the 'x'... I found some other rather odd
behaviour...

> also on Android 1.6, i made a screenshot athttp://picasaweb.google.de/lh/photo/SqA2gueNy4xJeAO1IDWQEA?feat=direc...

[Shadow]

FYI -- Not sure if this is why but sometimes Google stuffs use
0xAARRGGBB format for colors: A = alpha, R = red, G = green, B = blue.

[Sefu]

LOL those are all the wrong colors - no hue values at all for most of
them (the 0x broke 'em) so all that remained were the saturation,
lightness and gamma options (all set to low, explaining the map's
'browniness').

I finally solved the problem. '0x' broke all hexadecimal values (in a
way I still cannot determine), but it works with HSL values (namely
the 'degree' of the 'pure' Hue color (format: 0x000360 for 360º) - in
fact, I think 0x is reserved for them. I'll implement it through all
my styles tomorrow and see if my tile loads still break through my
iPhone/carriers.

On Aug 23, 11:22 am, dfd <dfddurstew...@googlemail.com> wrote:

> also on Android 1.6, i made a screenshot athttp://picasaweb.google.de/lh/photo/SqA2gueNy4xJeAO1IDWQEA?feat=direc...

[Sefu]

Odd - in both cases it loads three before choking - the unloaded one
(the NE tile) just shows white without any 'sorry, no imagery here'.

The '#' problem is still unsolved, but I managed to figure out the
correct way of using the '0x' alternative... with the 'degree'
declaration in HSL values (#ff0000, at 1º, would be 0x000001 - don't
know the reason for those three leading 0's). I'm dead tonight, but
will implement it into the 'main' page first thing tomorrow, then see
if my tile loads still choke.

Thanks!

[Sefu]

Thanks for that - I'll try that as well tomorrow. If that works too, I
hope Google won't change its coding habits any time soon ; P

Night all, thanks again ; )

[William]

On Aug 24, 9:38 am, Sefu <the.promena...@gmail.com> wrote:
> The '#' problem is still unsolved, but I managed to figure out the
> correct way of using the '0x' alternative... with the 'degree'
> declaration in HSL values (#ff0000, at 1º, would be 0x000001 - don't
> know the reason for those three leading 0's).
>

Good work! Now we are making real progress ... removing the hex and #
altogether, I just tried simple hue values like hue: "60" for yellow,
"120" for green, "180" for cyan, "240" for blue etc. Or the transit
line example from your webpage, { hue: #ff9100 { is { hue: "34" }

....

[Sefu]

Perhaps a side note, but there ~is~ a(n unattainable) tranceparency
setting for each map element... when I was trying to note the location
of 'pure' colours for the HSL colour scheme, I chose to target
'poi.parks' to test for pure green: after I had the results I wanted,
I noticed that I had forgot to remove the base 'poi' settings. When I
commented out everything but the map element I was working on, the
park's former pure green changed into an almost orange hue. Let's have
some fun with that once I get my colour updates out of the way ; )

[Sefu]

It's working. It'll probably be as ugly as sin (I'm still
experimenting with colour/possible gamma settings), but here it is :
http://www.paris-promenades.com/pp_tp/index_numto0x.html .

...as long as I remain consistant in my method (using 0x000360, 360 as
a hue) I can tweak the colours to a satisfactory result, but there
~does~ seem to be some sort of 'gamma factor' in play here: all
modifications I make seem to be 'applied' to the base values of the
existing Google styledMap options: my changes do not replace them
completely. For example, a '0x000021' hue applied to transit lines
(that seem to have only saturation and lightness options set (to make
grey), I get orange (the 'default' hue seems to be red - seen in my
other example where only the raised ssaturation/lightness options were
working), whereas applying the same hue to roadways gives me green.
Still tweaking.

[William]

On Aug 24, 5:31 pm, Sefu <the.promena...@gmail.com> wrote:
> ...as long as I remain consistant in my method (using 0x000360, 360 as
> a hue) I can tweak the colours to a satisfactory result, but there
> ~does~ seem to be some sort of 'gamma factor' in play here: all
> modifications I make seem to be 'applied' to the base values of the
> existing Google styledMap options
>

yeah when I tried it, the hues seemed to be relative to the existing
hues in the ROADMAP style, instead of absolute hues, see the following
example:

http://www.william-map.com/20100824/1/paris.htm

...

[Sefu]

Thanks again William - I can't believe you went through the whole
thing! I've only been looking at my 'park-ugly' colour-experimentation
page through the iPhone until now, so I hope you don't mind my
'borrowing' your code so that I could look at the page the way it is
'supposed' to. Would you mind if I keep your notes for reference?

I'm sure google wants people to make plans that can be visually
associable with their base product - and their method is a good means
to that end. Especially their RGB to HSL calculations... grrr.

I found a few things in my twiddlings, but nothing conclusive. Hint:
if you set the saturation to 100 and gamma to -48 for certain elements
(parks and water, namely) you will have settings that will let you
play with saturated 'pure' colours.

Before even getting to the colours, I wanted to see what 'switched'
what in their conversion, to better control what their server sent
back to me. First off, I found that strings (for the 'hue' option of
course) without a leading '0x' longer than 16 characters 'broke' the
style engine, forcing the server to render 'standard' images.
Secondly, there seems to be some sort of 'byte count' operation going
on... if I have my 'roads' option set to apply changes to 'all', the
colour changes are minimal at best, and the labels (especially the
highly-differing highway ones) remained as equally contrasted when
trying to pass just hues. I found that:

First off, there is no color variation between, say, '0x360' and
'0x00000000000360' (the leading zeros are just trunciated)
Yet there is a big difference between '0x36000000' and '0x360000000' -
the colours (constantly changing as you add zeros) suddenly begin
affecting the road labels as well (beyond a certain byte count, the
selected hue overrides the standard colour scheme entirely and only
the saturation/lightness settings are applied).

As for the colours, using the technique mentioned above, I found some
oddities that may lead somewhere. I noticed a few patterns emerge
while attempting to apply a 'gamma addition' to the front end of a hue
hex literal (as suggested in an earlier post):

The hexadecimal format will render parks pure red (remember to
disactivate the base 'poi' settings) if the hue hex code is
0xf0f03600, 0xfff00000, 0xf0ff0000; 0xf0003600, 0xf0f00000, 0xff000000
will render pure green; 0xf0ff360, 0xffff0000 and 0xf0000000 will
render pure blue. Not sure where that's pointing, but it's pointing
somewhere.

[William]

On Aug 25, 12:34 am, Sefu <the.promena...@gmail.com> wrote:
> I'm sure google wants people to make plans that can be visually
> associable with their base product - and their method is a good means
> to that end. Especially their RGB to HSL calculations... grrr.

wow you've discovered a lot about the RGB --> HSL calculations! To be
honest I'd never looked at the HSL color system before this, and it's
not as straightforward as the RGB or CMYK system.

I'd like to see a pure HSL option with the styled maps, where the user
can either specify the hue as:
1. RGB as it is done now with a #, or
2. as a pure hue from 0 to 360.

That would avoid the need for translating from RGB to HSL for cases
when the graphic designer already knows the hue they want to use? I'm
no expert in graphic design but I can see that Photoshop makes it easy
if you want to use HSL, so I'm not sure why RGB was chosen for hue in
the maps API?

I made a feature request for this:
http://code.google.com/p/gmaps-api-issues/issues/detail?id=2665

...

[Thor Mitchell (Google Employee)]

Just out of curiosity, on the devices on which the styled map does not
work, what happens if instead of specifying your hue as '#00ff00' in
your app you specify it as '%2300ff00'?

Just wondering if the devices concerned are not URL encoding the # as
they should, perhaps because the # character is permitted in URLs, but
only as the fragment separator.

Thor.

[Sefu]

Replacing "#" with "%23" results in an url that passes successfully
without modification (through the iPhone and carrier - still don't
know where the urlEncoding is being done) to the Google maps API, but
"%2300ff00" will break Google's RGB-to-HSL calculation.

This means that the tiles will appear if "%23" is used, but they will
be tiles affected only by 'saturation', 'lightness' and 'gamma' style
options.

On Aug 25, 1:15 am, "Thor Mitchell (Google Employee)"

[Sefu]

I don't think RGB=>HSL conversion calculation is a complicated affair
(I had a look at the Google styledMaps Wizard code), but even having a
correct conversion technique will be pointless until we can figure out
what google maps server does with the 'hue' option... all we know for
now is that Google:

... accepts and understands '0x' ('xff0000' fails, '0zff0000' fails,
'ff0000' alone fails)
... yet '#' and '0x' trigger different behaviours (#ff0000 renders
red, 0xff0000 renders blue)
... accepts and understands 'pure hue' input (any number with or
without '#' or '0v' works)
... yet '225' renders magenta, '#225' renders blue, and '0x225'
renders purple
... the server strips all leading zeroes in '0000225' (renders the
same as '225') and '0x0000225' (ditto as '0x225')
... and that any 'hue number' longer than 9 characters (after a '0v')
will override any mix with 'Google colours'.

No matter what number you put as a hue, I think that the 'HSL hue
calculation engine' extracts only the 'pure hue' from the RGB
hexadecimal and passes the 'remainder' to the lightness and saturation
elements of HSL. For example, pure red in RGB (#ff0000) is H 0 (0º) S
1 (100%) L 0.5 (50%) - we can assume that the 100% saturation and 50%
lightness are the passed on remainders.

Add to the above mix the fact that even the 'pure hue' number is a
degree ~away~ from google's existing colour scheme for that element,
and we've got a... mess.

I still don't know what to conclude from yesterday's 'discovery':

0xF0F03600
0xFFF00000 == #FF0000
0xF0FF0000

...because 0xF0F000010 (one degree to the right of 0xF0F03600) renders
a completely different colour. Actually I think the leading four
characters set the 'zero point' on the wheel ('FOFO' indicates that
zero is pure green), and '360' is the degrees away from that point.
But the '360' doesn't make any sense at first glance - that's a full
rotation! Yet '0xF0F0720' - 720º away from the 'green point zero' -
renders... pure blue. Yet '0xF0F01080' renders #00FF88 (greenish
blue). Wwwhat?

[William]

On Aug 23, 5:31 pm, Sefu <the.promena...@gmail.com> wrote:
> What is most frustrating is that I have no access to iPhone, carrier
> nor Google logs... I want to see exactly what Url Google is getting.

I'm gonna try to make a diagnostic page for this which should be
useful for debugging tile access problems.

...

[William]

Using Chrome, I saved the doco example HipHop Styled maps page, then
edited the bootstrap javascript file to change the map tile urls to
point to another server. This server has a tile generator which
writes the URL onto a yellow background and this way we can see the
urls at the server. Try this on the iPhone:

http://www.william-map.com/20100825/1/yellow.htm

...

[Sefu]

Again, thanks a million, William! Going to try that now...

http://www.paris-promenades.com/pp_tp/iPhone_badurl_scrsht.png

http://www.paris-promenades.com/pp_tp/iPhone_goodurl_scrsht.png

!!! Whoah, totally unexpected results! All the '|' are encoded (%7C),
and the first '#' ~doesn't~ get encoded (or is 'encoded back'). I
wonder what happens on one of our 'iPhone fixed' pages...

That must have taken a lot of work - Thanks! You're getting a
developer credit on my new site for sure ; )

[Sefu]

Sorry if I was a bit brief this morning - to clarify:

http://www.paris-promenades.com/pp_tp/index_onenumsign.html
http://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=s.t:40|p.h:%2523ff0000|p.s:100|p.g:0.48&x=4145&y=2817&z=13&s=Gali

...the above urls point to a page using '%23' instead of '#' in a
single style - full page, and a single tile - it seems that the %23
becomes %2523 ... but the page loads! Now let's try multiple styles...

http://www.paris-promenades.com/pp_tp/index_pertwothree.html
http://mt0.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=s.t:5|p.h:%2523ff8000|p.s:49|p.l:60,s.t:82|p.s:-30|p.h:%25236eff00|p.l:-5,s.t:82|s.e:l|p.s:-30|p.h:%25236eff00|p.l:-20,s.t:3|s.e:g|p.h:%2523ff8800|p.s:-69,s.t:3|s.e:l|p.h:%2523ff8800|p.s:-69,s.t:2|s.e:g|p.h:%2523ff8800,s.t:33|p.h:%2523ff3c00|p.l:-17|p.s:9,s.t:40|s.e:g|p.h:%252333ff00|p.l:30,s.t:65|s.e:g|p.s:80|p.h:%2523ff9100,s.t:6|p.h:%25230099ff|p.l:40|p.s:25,s.t:1|p.h:%2523ff2200|p.s:50&x=4150&y=2820&z=13&s=Galile

...loads the tiles, but the hue is broken. I don't think the Maps API
server can handle multiple instances of '%2523'... the case is the
same in both iPhone 3g and wifi LAN.

On Aug 25, 1:15 am, "Thor Mitchell (Google Employee)"
<t...@google.com> wrote:

[William]

On Aug 25, 11:29 pm, Sefu <the.promena...@gmail.com> wrote:
>
> !!! Whoah, totally unexpected results! All the '|' are encoded (%7C),
> and the first '#' ~doesn't~ get encoded (or is 'encoded back').
>

that's interesting because it means that the entire url is getting to
the server, with some encoding changes along the way. Ben and Thor
were right to point out the # symbol as the problem, but the
"fragment" following the # isn't being discarded. Google's tile
servers don't like the mix of encoded and unencoded content on "bad
request" urls like this:

http://mt1.google.com/vt/lyrs=m@130&src=api&hl=en-US&apistyle=s.t:1%7Cp.h:#ff2200%7Cp.s:50&x=4145&y=2819&z=13&s=Galile

...

[William]

On Aug 25, 11:29 pm, Sefu <the.promena...@gmail.com> wrote:

> I wonder what happens on one of our 'iPhone fixed' pages

I took the style out of that Paris map which used { hue: "225" }
styles, and put it into the "yellow map" template:

http://www.william-map.com/20100825/1/paris.htm

...

[Sefu]

Thanks, tried it... all the vertical pipes ('|') are encoded into
'%7C', but this doesn't seem to be causing problems for Google - I
think it was the un-(or re-)encoded '#' in your earlier example that
caused the problem - but what triggered that behaviour? I don't see
any patterns in your earlier link (msg #26)... all the pipes are
encoded correctly, but only the ~first~ '#' is un-(re-)encoded... the
'#' (urlEncoded or not) is preceded by '%7Cs.e:g%7Cp.h:' ('|s.e:g|
p.h.:')and followed by an alphanumeric character all through the
URL... (scratching head).

[William]

On Aug 26, 1:06 am, Sefu <the.promena...@gmail.com> wrote:
> it was the un-(or re-)encoded '#' in your earlier example that
> caused the problem - but what triggered that behaviour?

I think it's the 3G network that is unencoding the first #, because
you've tested the iPhone on wireless and it's ok. Someone could try
android and verify but I don't think it's an iPhone problem.

The next step is to use a proxy tile server, and make it change the
first # into a %23, and then request the image from google servers.
The following url uses the hiphop Styled map from the doco, where the
tile requests are being served through a proxy:

http://www.william-map.com/20100825/1/proxy.htm

...

[Sefu]

One last look into this 'colour puzzle' and then I'm going to play
KISS and adopt your system, William - it's the simplest thing we found
thus far. In any case, my trying to determine what an undocumented hex
literal input option does on a server that we can't see is a bit of a
fool's errand ; P

The simplest pattern I could determine was:

0xF0FF0000 = Red
0xF0F00000 = Green
0xFFFF0000 = Blue

Unfortunately I found that:

0xFFFFFF00 = red
0xF0F0F000 = red
0xF0F00000 = red

Why the extra '00'? Because '0xF0F000' breaks:

0xFFFFFF = 255 blue, 33 green
0xF0F0F0 = breaks
0xF0FF00 = breaks
0xFFFFFF(00~77) = red
0xFFFFFF(88~FF) = any same-character 88~FF combination = Blue with red
(#4400FF)
0xFFFFFF(88~FF)(88~FF) = any same-character combination = shifts all
to the right (#FF4400)
0xFFFFFF(88~FF)(88~FF)(88~FF) = any same-character combination =
shifts all to the right again (#00FF44)

What the...

[William .]

On Wed, Aug 25, 2010 at 6:59 PM, Sefu <the.pro...@gmail.com> wrote:

... yet '225' renders magenta, '#225' renders blue, and '0x225'
renders purple

 

Obviously these are undocumented properties and cannot be relied upon in a production system, but I believe that:

1. '225' and '0x225' are relative hues, specified in decimal degrees, applied as an adjustment to the existing color in ROADMAP, and

2. '#225' is an absolute rgb hue, which replaces the existing color in ROADMAP

 

RELATIVE HUES

 

225 is decimal already, and

0x225 hex = 549 decimal, which is 360 + 189

 

so on an example with roads where the shaded color is yellow, 60 degrees, then the expected hues are calculated by adding the shift to 60:

 

(a) 225 + 60 = 285

(b) 189 + 60 = 249

 

when I tried it (with saturation 100) and then selected the resulting colors with photoshop it said 284 and 248 respectively, very close to the predicted hue.

 

ABSOLUTE HUES

 

I think '#225' is interpreted with leading zeros to pad to 6 hex digits = '#000225'

photoshop says this is a hue of 237 degrees.  This is confirmed when trying hue: '#225' on roads (with saturation: 100)

 

...

 

[Sefu]

If you want to play with hues precisely, go to the maps API style
wizard and select an element, select a 'pure' hue, (say, FF0000) in
the hue bar using a colormetre to click the right colour (mac's OS-
native 'DigitalColor Meter' is cool for this - set it to a 1px
aperture), set the saturation bar to 100 (this makes damn sure that,
no matter what the map's original setting was, the result will always
be 100 (it can't be more). Then, testing with the colour metre, play
with the gamma bar until the colour of the element you are modifying
is the same as the pure hue you chose. This seems to create testing
conditions that are constant across the board.

hex '0xff0000' = dec '16711680' ... doh! Gives the same results when
submitted as a hue.

#225 = #000225 : yep, always the case - 'missing' hex characters (out
of the mandatory six) are automatically appended after the '#' (#FF ==
#0000FF) - but you know this ; )

0x225 = 0x000225 gives the same results as well, for the record.

But why the different results between '#255' and '0x255'? They behave
in the same way... I think Google is expecting something different. I
tried prepending 'FF' (the oft-appearing Google 'gamma factor'
mentioned elsewhere in this thread), but no go... is google perhaps
expecting a 16-bit hex number?

On Aug 26, 10:12 am, "William ." <william.g...@gmail.com> wrote:

[Sefu]

Okay, I think I've got it.

I was playing with the '0x' input, and noticed that I would not get
consistant results unless I used at least eight characters. In all
cases without exception, I would only get a targeted 'pure' colour if
there were 8 characters (I think that anything short of eight digits
results in 'missing' digits prepended as '0's to the beginning of the
8-char hex string). After a bit of playing around, I finally managed
to get a few combinatons that resulted in the '#FF0000' pure red I was
looking for, and also did the decimal conversions:

0xFFFFFF00 = 4042321920
0xF0FF0000 = 4043243520
0xF0F0F000 = 4294967040
0xFFF00000 = 4293918720

...I then entered the decimal value in the styledMap 'hue' option, and
got a pure red in all cases.

I was at first persuaded that the last two characters had to be '00',
but I am certain that, to get a pure red, the hex can be any
hexidecimal combination that computes to a decimal number that results
in a pure red.

Now all I have to do is convert a 6-character RGB hexidecimal color
code to an 8-character hexidecimal string.

Still wondering about that '9-character switch' that makes Google
override its default colours - but that can wait for later.

[William]

On Aug 27, 12:08 am, Sefu <the.promena...@gmail.com> wrote:
> After a bit of playing around, I finally managed
> to get a few combinatons that resulted in the '#FF0000' pure red I was
> looking for, and also did the decimal conversions:
>
> 0xFFFFFF00 = 4042321920
> 0xF0FF0000 = 4043243520
> 0xF0F0F000 = 4294967040
> 0xFFF00000 = 4293918720
>
> ...I then entered the decimal value in the styledMap 'hue' option, and
> got a pure red in all cases.
>

as a hue of pure red, all these numbers are multiples of 360 degrees

if the numbers are of the form Fxxxxx00, we can factorise this as
15*X*16*16, and since 360 = 15x3x8, then the number is divisible by
360 if X is divisible by 3.

A number is divisible by 3 if the sum of its digits is divisible by 3,
and if the only digits are F or 0, that means there can be either 3 or
6 Fs in the number Fxxxxx00 for the following pure reds:

0xFFFFFF00
0xFF000F00
0xFF00F000
0xFF0F0000
0xFFF00000
0xF0F00F00
0xF0F0F000
0xF0FF0000
0xF00F0F00
0xF00FF000
0xF000FF00

...

[Sefu]

I saw that pattern too! Green is either 5 or 2 'F's, and Blue is
either 1 or 4.

Writing from my iPhone (connection problems) - back to you later.

[William]

On Aug 27, 12:08 am, Sefu <the.promena...@gmail.com> 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

...

[Sefu]

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

[Sefu]

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.

[William]

On Aug 27, 7:58 pm, Sefu <the.promena...@gmail.com> wrote:
> I'm increasingly persuaded that we're dealing with three behaviours
> here: 'pure hue' behaviour ('360'), RGB behaviour ('#FF0000') and
> hexadecimal behaviour ('0xFFFFF000').

I think RGB and 8-digit hexadecimal behave the same as absolute hue
references, but not all hues are possible with the 8 digit
hexadecimal.

I've added the rgb --> hue conversion function to the previous version
of the map which converted hues to 8-digit hexadecimal, resulting in
the following hue calculations:

{ hue: hexHue(rgbToHue("#ff9100")) }

http://www.william-map.com/20100827/1/paris_hex.htm

...

[Sefu]

Thanks again for all your investigative work.

I think you're right - with '0x' Google just expects an 8-digit
hexidecimal. I'm not so sure that all hues are not possible though -
the characters between the initial 'F' and the trailing '00' can be
anything... and since the number expected is a 'pure hue', any number
combination between 0~360 is possible. yet how to formulate this into
code... a lost cause really, might as well just use 'pure hue' input
(number between 0~360) right off the bat.

As for the 'switch' detected earlier... I think google is expecting a
hexidecimal mix that, when converted to a decimal number, ~results~ in
a number nine digits or more - this is always the case when using the
'0xFxxxxx00' formula. If there are less, then some part of their code
'breaks', namely the part that applies the colour chosen to labels.
Consider the difference between, for the 'road' element (option
'all'), '0xF00000' and '0xF0000000': the first colour, magenta, is
applied to roads, but the signs are of different colours, while the
second colours all 'road' elements in the same tone of blue with only
differences in lightness and/or saturation.

I think we have taken this far enough - the google code will evolve
eventually, and the 'pure hue' input, a major discovery, will suffice
to style tiles for all systems and supports.

Thank you so much for your help in this - If we don't speak again
before, I'll let you know when everything is ready to go. Cheers!

[Sefu]

Okay one last example - consider the difference between 'road' & 'all'
set to hue '182', then hue '0xF0000000' - roads are the exact same
colour (eq. #0404FF), but the signs only take the indicated colour in
the second case.

On Aug 27, 1:38 pm, William <william.g...@gmail.com> wrote: