Don’t you love it how websites claim to have an API that can be used via GET requests, only to find that they don’t recognize the Access-Control-Allow-Origin header, nor do they support CORS requests. Ironic.

Basically you are presented a sandbox, and you have to program the AI (etcetera) in Javascript. And the better you are at programming, the better you will do in this game. Can’t wait until it’s available.

Started working on a web application with jqGrid as a grid object. Very powerful, and reasonably simple to start with. One thing I found missing, is that it does not understand just a data-array or json string to automatically fill the grid. One *must* give it the colModel parameter as well, basically destroying the dynamic nature of jqGrid. Not a big problem, just a quirk.

The solution I’m creating for the client is based on Google Maps, so when I showed them some results, they joked that they wouldn’t be able to sell their product to Microsoft, since it’s not based on Bing Maps.

Replacing the basis with Bing Maps is no problem however. But since the map in this solution is used as an entry to filter the data (you draw the region you want to query), I need a (free form) drawing library of some sort. There is no drawing support in Bing Maps what so ever. The only thing present is the Shape Toolbox module someone created back in 2012, and never maintained/updated. Why is there no support for drawing on the map?

To make things worse, if I wanted to create something myself (I learned a thing or two playing with Google Maps) the mouse event returns X and Y values of the screen, not the coordinates on the map where the mouse event took place, so if I want to create something myself, I need to be recalculate the X and Y values to mapcoordinates every single time. There’s a function for it, but it’s a stupid decision to implement it this way. It should be the other way around, because how often would you really need the X and Y values of the screen?

I found a script to simplify polygons in Google Maps, basically to reduce the number of nodes the polygon is build up from. It does that by some sort of smoothing algorithm, with a distance parameter. Anything under that distance is smoothed out (read: deleted). It’s a Google Maps V2 script, but I modified it to work with V3.

When I set the tolerance (kink as it’s called in the script) to 10 (meter), my polygons have a node drop from almost 600 to about 30, and still look about the same as what was drawn. I can still optimize the query a little to only use 7 decimal digits on the lats/longs, but for now that’s not needed.

Come to think of it, the amount of smoothing should be linked to the zoomlevel the map is at when drawing the polygon.

I created a routine (Javascript) to do some free form drawing of a polygon in Google Maps, as opposed to the standard point-per-click polygon that comes with the standard library. Everything works great. The polygon is used to query a database (you’re drawing your filter, so to speak). A simple polygon around Amsterdam however results in a 900+ points polygon, making the query-string over 45K. Wow. That needs some optimization!

The Google Maps API introduces styling of maps, like most people know when using OpenLayers (via SLDs) or OpenStreetMap (where you can create your own style, and share it with others). Google Maps styling is done in Javascript, as an extra option when creating the map. So there is no sharing option, and it’s not based on the SLD-standard, but I still think it’s a nice addition. Sometimes you don’t need the full color map, since it can distract from what you are showing.