Map Styles and Usability: Please Help

I've been away for a couple of weeks, and I'm now catching up with what's been going in the Geo blogging community. I saw a couple of posts on the Google Maps API new styling features:

Thoughts about Google’s Styled Maps announcement

Google Map Styles

There were more of course, but Steven Romalewski and Richard Treves raise some good points about usability. We've basically provided no guidance on usability of the new styles. The examples that we provide are designed to show extremes of styling to get the point across.

The truth is, we're mostly engineers, not cartographers. I'd love to see some great guides to how to style your map. Anyone want to give it a go? Anything good out there, I will make sure we link to it and talk about it.

To be fair, Steven is also concerned that it'll actually drive more people to use Google Maps API. His concern, our hope of course :-). He is concerned that this will reduce the commitment to other mapping platforms and perpetuate a mono-culture of maps. I don't see any danger of that right now, but I do appreciate that concern. Competition is good for us, it does help drive us to better things. So Cloudmade, Bing, OSM, everyone else, please make your mapping better. It helps us too.

Techniques for protecting your data

I was asked in the comments in this post: Maps to KML?, to talk about techniques for protecting your data in Google Maps applications. I'm finally getting around to that.

First off, let's just say that like any part of the web, it is probably impossible to totally protect your data that is published on a Google Map. People can always get access to it at very least by just viewing the data, which you want, and making notes. Screenshots, viewing source, intercepts, and other techniques can be used by the truly ambitious. True data privacy in a completely public page is an oxymoron. Note, I'm not saying privacy on the web is bad or not possible, but we're talking here about displaying data. As long as it's displayed, someone can get at it.

That being said, there are steps you can take to make it harder to get at, to make people work at it.

The most important thing you can do is avoid hard coding any information into the page. That should be fairly obvious, but many people fall into the trap. That means:

1. Don't have any code in your JavaScript that uses a specific Latitude/Longitude pair, an address, or anything of that nature.
2. Use calls to server resources to plot only the data necessary to display at that moment. Try to verify the origin of the requests to prevent people from scraping. Generating your data on the fly prevents someone from getting all your data at once.
3. Obfuscate/compile your Javascript code to make it harder to read.

You can also rasterize your data, or turn it into image overlays. There's a lot of techniques for doing this. This talk by John Coryat is a couple of years old, and was oriented to Maps API V2. However, in it he discusses many techniques that are applicable to V3.

Rasterization makes it difficult to extract the data directly. It can also increase your performance in some cases where you have lots of data.

If you're working with KML, you can distribute the KML to only trusted people to load in their Google Earth instances, but this is subject to trusting them. Any KML used in a Maps API application will be easily findable by someone who can get passed any obfuscation you have.

That's all I've got. Feel free to post any additional techniques in the comments.

My slides from iHub Nairobi's Mobile Monday

Slides from BarCamp Nairobi/ WhereCampAfrica

So, it was pretty free-form, and I didn't stick to the slides, but there's still good links and resources here.

And, I hate this, but OpenOffice on the Mac corrupts PowerPoint export somehow. This prevented me from converting to Google Presentations, so I created both a PDF version and an OpenOffice version.

The images in the Eye Candy section are clickable.

BarCamp/WhereCamp Nairobi

Over the weekend, I attended BarCamp Nairobi, which was combined with WhereCampAfrica. It was a great event, which filled both the iHub and Nailab spaces. Despite a fist fight that developed between myself, Stefan Magdalinski, and Mikel Marron, the event was otherwise very friendly and cooperative.

I went to great talks on:

• Shika (a local ICT4D organization working in the slums in Kenya. If anyone has a link, please pass it on in comments)
  
  
• AkiraChix
  
  
• OSM
  
  
• Seven Seas Technologies and entrepreneurship
  
  
• Map Kibera
  
  

And too much more to post on. But like all Barcamps, the most interesting stuff is in the halls. I learned a lot about the emerging tech community here, and the difficulties of getting work in the face of a small percentage of the population being online. Like most of the developing world, they are jumping straight to mobile, largely skipping a large scale computer market. And mobile devices are where most people get their net access.

Of course, the event had to break each day for World Cup games, which were put up on the projection screen at the iHub.

It looks like the iHub is the place to be. My only regret on this trip is that I won't be here on the 26th, when the iHub hosts a big LAN party for gamers.

For those of you in Nairobi, I'll be presenting tonight at the iHub for Mobile Monday, about 20 minutes on using Google Mapping technologies on mobile devices.