unicolet.org

Sometimes it is useful to abstract away the repetitive layer creation code with a configuration-based approach. For example consider this very simple map taken from the OpenLayers examples : How could we avoid repeating invoking the layer contructor and instead provde a framework that allows us to instantiate any layer with just configuration? The solution is quite simple.

To improve the quality of both my sleep and Mappu development I have started using Selenium IDE for automated testing of Mappu's UI. It was kind of hard at the beginning, being the UI based on Sproutcore which has the annoying habit of changing the controls ids with every page load, but after a while I was able to get it rolling quite nicely. Then I hit a major roadblock: the OpenLayers-based map control wouldn't react to clicks, mousedown, mouseup, fireEvent or anything else I threw at it.

I have been playing with TileDrawer recently. After a first rapid successful test on a throw-away EC2 instance I decided to deploy one on a vm for intranet use. The installation process is pretty straightforward, just run the script copied from the TileDrawer page as root. FYI make sure you have installed curl and python-cssutils before launching the script. After the script completed I started browsing the map and noticed that tiles took a looong time to render. A look at top from the server console showed that postgres was hogging the cpu. Memory was fine with no signs of swapping (it is a 1GB instance which I promptly upgraded to 2, running on server class hardware with Xeon CPU). Even after the memory upgrade tile rendering was so slow that the browser would sometime give up and show a white tile. I decided to look into it a little further and started by using the technique I have already described in another article . The database cache looked fine though as mo...

It happened to me recently that I needed OpenLayers (version 2.11) to parse a GetCapabilities response from Geoserver to present the user a list of layers to pick from. The capabilites request is made through a Sproutcore request, which is basically a jQuery ajax object in disguise. This of course works beautifully in every browser with the notable execption of ... IE (IE9 included). The cause is that IE will helpfully xml-parse a response whose content-type is text/xml , but will refuse to parse a document whose content-type is  application/vnd.ogc.request+xml . To add comedy to the drama the responseXML attribute of response is not null, as one would expect, but is instead set to reference an empty dom. The workaround is to put a giant browser-sniffing if in your javascript to handle IE differently. The code is like the following and please note that it is Sproutcore code, so browser sniffing and other amenities are peculiar to Sproutcore: // God mess IE if(SC.$.bro...

In one app I needed to allow the user to CTRL-click on an OpenLayers map to popup a tool menu. Since all the rest of the app is Sproutcore based I also wanted the menu to have the same look&feel. Sproutcore already has a menu view which is called SC.MenuPane . Unfortunately SC.MenuPane can be positioned only relatively to another SC.View, but what if I want to position the menu exactly where I clicked on the map? The solution turns out to be pretty simple and requires us to override only one MenuPane method. The method is positionPane and can be overridden at definition time by adding it to the mixin as done below (gotta love javascript, huh?): Maps.openLayersController.menuPane: SC.MenuPane.create({ layout: {width: 120}, itemHeight: 25, items: [ { title: '_geocode'.loc(), icon: 'http://maps.gstatic.com/favicon.ico', action: "geocode" }, { title: '_streetview'.loc(), icon: 'icon-streetview-16', action: "streetview...

When using OpenLayers embedded in a Sproutcore app you will want to set the following option on the OpenLayers.Map constructor: fallThrough  : false to avoid double handling events (once in OpenLayers and once in Sproutcore). Map dragging should improve and feel much smoother. Although deprecated this wiki page explains very clearly Sproutcore event handling.

I have showed in the previous post how to add KVO to OpenLayers objects and then connect these objects to inputs, etc. The approach was unfortunately troublesome because each OpenLayers object had to be programmatically augmented through a SC.mixin call. In this post I will show how the OpenLayers source can be patched to make the augmentation process built-in. The only modification that needs be done is in Class.js where the OpenLayers.Class function must be modified as follows: OpenLayers.Class = function() {     var len = arguments.length;     var P = arguments[0];     var F = arguments[len-1];     var C=null;     if(typeof F.initialize == "function") {         if (!F.__my_init) {             F.__my_init = F.initialize             F.initialize = function() {                       ...

You can also  Read Part 1   or   Read Part 3 In the previous post of this series I have showed how easily an OpenLayers object can be extended with Sproutcore KVO . The main driver behind integrating KVO into OL is that of beauty and simplicity. When KVO is available texfields, checkboxes, layers, features, you name it can all have their state transparently and continuosly synchronized without writing any code at all. The first post was more of a proof of concept. In this post instead I am going to show a more practical use and rewrite one the OpenLayers examples (from the dev examples). The original example shows how to create and add features to a map from javascript. With the help of KVO I am going to expand the original and also make the features editable. As we will see the changes will propagate immediately into the map. The full source is available on github . To run the example simply download/clone/fetch the repo and open index.html with a browser. The...

The truth is that after you start using Sproutcore KVO you become addicted to its beauty and simplicity. Where in other frameworks you spent most time keeping each part of the app in sync, in Sproutcore you get it for free. Sure Sproutcore isn't perfect and is not for all, but KVO is simply automagical! In this post I will show how easy it is to implement KVO on top of OpenLayers and take advantage of KVO to bind features, wfs queries and UI controls to otherwise stubborn Openlayers objects. In this example we will create a Vector layer, add KVo to it and then verify KVO bindings by manually adding an observer. I have run all this code from Google Chrome console and you can do it too. First thing to do is to create a scratch SC project: sc-init kvool then let's edit the Buildfile and add the following lines at the end so that the OpenLayers library is loaded with the app: config :all do |c| c[:javascript_libs] = ['http://www.openlayers.org/api/OpenLaye...