Why use a grid of characters and not a grid of pixels (with indexed values that can be linked to the properties just like UTFGrid links chars to properties) ?

I use this kind of pixel grid which brings those advantages, especially for very large maps :

- use of the image (with carefully chosen colors) as a direct preview of the map (depending on the resolution)

- efficient (bidirectional) PNG compression

- use of already present image manipulation libraries for all kind of manipulation (like layers addition)

What's the benefit of using UTF characters ?

Basically the answer to all of these questions is that it's easier to decode in the browser. A UTFGrid is just plain JSON, so we can just run it through JSON.parse(). PNG uses zlib compression, so we can get that benefit for free when sending gzip over HTTP. Here's some more design rationale: http://developmentseed.org/blog/2011/09/21/how-interactivity...

OK, I understand.

As a side note, I send my PNG when needed in JSON (larger, with base64 encoding, I didn't try to make a comparison with ASCII art format) and I find that with getImageData getting the indexed colors is fast and easy. I was referring to bidirectional compression because PNG filter (applied before the deflate) uses the fact that pixels are often similar on both axes.

Of course, without a few tests and comparisons, I can't be sure I really gain in size, but I like to use the fact that my map is an image (faster to draw on the screen at some resolutions and image manipulation server side - my zero indexes are simply mapped to the transparent "color" as is common in most color palettes).

I have different constraints trough, as my map contains 3200x1600 pixels and not 64x64, so that I really need those compressions for instant display.