Comparing OpenLayers and MapBuilder

I have been doing some research into comparing OpenLayers and MapBuilder to determine which will be more suitable for one our projects. I also wanted to get more familiar with the two technologies. I had played around with OpenLayers before but didn’t attempt any customizations to the existing functionalities that are available by default. There are a lot more of similar AJAX-enabled open-source web mapping applications that are available but OpenLayers and MapBuilder were the most promising ones. So, here you go…

OpenLayers – OpenLayers is a pure JavaScript library for displaying map data in most modern web browsers, with no server-side dependencies. OpenLayers implements industry-standard methods for geographic data access, such as the OpenGIS Consortium’s Web Mapping Service (WMS) and Web Feature Service (WFS) protocols and other standard vector layers for the web like GeoRSS, GML etc. OpenLayers tries to separate map tools from map data so that all the tools can operate on all the data sources. The supported layers in OpenLayers are:

WMS, WFS, TMS, GeoRSS, GML, Google Layers, Geo-referenced Image Layer, MapServer Layers, VirtualEarth Layers, Yahoo Layers, WorldWind Layer, TileCache Layer.

The data layers supported by OpenLayers is extensible and support can be added for other custom data sources. A lot of ESRI users will be excited to know that there is an example showing OpenLayers using the MapCache of ArcGIS server 9.2 that can be seen here.

MapBuilder – MapBuilder is an open source project allowing you to easily add dynamic maps and information from many other sources to your web site. The interesting thing here is that the MapBuilder development team is playing smart and are in the process of integrating OpenLayers into MapBuilder. This integration will eventually lead to OpenLayers to be the rendering engine behind the MapBuilder web applications. MapBuilder makes it easier to build new map widgets to enhance map interaction and to enable custom map functionalities. Building new map widgets is available through a well designed and easily configurable MVC framework at the client-side. Here are the key features of MapBuilder as listed on their website.

• Browser based mapping client
• Standards compliant, supports the Open Geospatial consortium(OGC) standards
• Renders maps from Web Map Services (WMS), Web Feature Services (WFS), GeoRSS, Google Maps
• Supports editing map features to Transactional Web Feature Services (WFS-T)
• Allows users to build their own maps, then save and share them, using Web Map Context (WMC) and Open Web Services Context
• Easy to use
• Fast and interactive – built using AJAX
• Works with most modern browsers (Firefox 1.0+, Internet Explorer 6.0+, Mozilla 1.3+, Navigator 6+)
• Customisable and easy to extend
• Open source under the LGPL licence
• No plugins required

The feature matrix for MapBuilder can be found here.

After reading through the documentation available on both OpenLayers and MapBuilder, I still didn’t think that I had enough technical information on the implementation of the two technologies to make an informed and intelligent decision on which technology would be ideal for us. So, I set forth asking questions on the forums for both the technologies. Emanuel Schütze responded and forwarded me his thesis work where he had done an extensive comparison of the latest web mapping technologies. His thesis work is a must read to delve more into the details of the above two and other web mapping technologies. His thesis work can be downloaded from here. Here is a feature comparison chart from his chart.

The chart above compares the various usability features among the various web mapping applications. Well, that’s great, but friendly is OpenLayers for custom feature development. Well, I set out trying to simple little customizations to the OpenLayers controls etc. After, fumbling my way around quite a bit and spending a whole lot of time in FireBug I was able to accomplish what I setout to do. What I learnt from that experience was that the customizations that might be required can be accomplished if got your CSS and JavaScript Kung-fu on. Given, that OpenLayers does not come with a whole suite of tools that regular map users are used to, more custom navigation and other tools need to be developed for a feature rich web mapping application. Developing those new tools can be overwhelming if you are not as comfortable in the JavaScript web environment as you are with the windows environment and have been pampered and spoiled by Visual Studio. If you set out to create a custom control for OpenLayers, you need to study the existing controls and use them as the starting point to create our own as there no documentation or example on the subject. The documentation that is available to help and guide you through the framework is sparse at best. But once you get comfortable with the framework, OpenLayers provides a real powerful web mapping application development platform. Examples using OpenLayers in various scenarios can be found here. The class diagram for the OpenLayers framework is shown below.

MapBuilder brings additional feature sets to the table. It allows for things like allowing users to build their own maps, then save and share them, using Web Map Context (WMC) and Open Web Services Context. These contexts are an XML representation of the LayerList, AreaOfInterest and some metadata. Most MapBuilder widgets perform client-side XSL transformation of the context documents to determine the display. Other MapBuilder widgets also transform the following 1) GML – e.g. to produce a list of feature attributes 2) A Context Collection 3) A Capabilities document 4) A response from a Catalog query etc. OpenLayers is currently working on their support for using WMC. MapBuilder supports SLD and is a SLD editor. SLD describes how to render features. It also supports editing map features to Transactional Web Feature Services (WFS-T). But there is a word of caution there because some server-side(Apache-PHP stack) features are required to accomplish that functionality. This I learnt from Cameron Shorter, “There is one security limitation using HTML faced by both Mapbuilder and Openlayers. You can only POST a request to the server that the HTML comes from. This is an issue when trying to access a service like a WFS from another server. Both Mapbuilder and Openlayers have a server side proxy to address this. All the rest of Mapbuilder and Openlayers code is client side.“.

MapBuilder does come with a lot more of the basic map navigation features that GIS users are used to. Unlike OpenLayers whose Navigation toolbar comes with just two controls (zoom and pan). MapBuilder also has more documentation for creating new functionalities compared to OpenLayers. But that is not to say that it is easier to learn. The OpenLayers framework could be a lot easier to learn given some good documentation rather than reading existing code. The framework for creating new widgets is also pretty well designed with a configurable MVC pattern that developers can relate to more easily.

The releases for OpenLayers are very well managed and are frequent to address issues quickly but on the other hand the release management for MapBuilder is not as good. It has been a year and a half since the last stable release for MapBuilder. OpenLayers has graduated incubation from OSGEO.

So in conclusion, If you just want a map and a few common widgets on the display, OpenLayers might be for you. If you want to design and develop new custom widgets to work with data sources from a number of sources then MapBuilder may be better.

Advertisement

XACML – A standard that I wish I had known about earlier

In the past, I have had to provide some sort of security and access control mechanisms for various sorts of resources in various projects. In all those cases, I had created security components that handled the respective requirements adequately but were slightly different in each case. I knew that they all shared the same core idea of access control based on authentication and authorization but just didn’t get to the point of building a generic framework that handle all those cases with little customization. But I got curious and scoured the web for previous work on the subject which is when I came across XACML. XACML which stands for eXtensible Access Control Markup Language provides a policy language which allows administrators to define the access control requirements for their users to application resources. XACML was approved and became an OASIS standard in February 2003. It is an initiative to develop a standard for access control and authorization systems. The XACML 2.0 specification document can be found here.

A typical access control and authorization scenario includes three main entities — a subject, a resource, and an action — and their attributes. A subject creates and initiates a request to perform an action on a resource. For example, in the access request, “Allow the District Manager to create features in the District Layer” the subject is the “District Manager” the resource is the “District Layer” and the action is “create features”. Proprietary access control systems store information about these entities in their own schema in the repository which are typically referred to as the “Access Control Lists (ACLs)”. XACML serves to standardize the repository schema and can help with sharing access control information across diverse systems running on different platforms.

The main components that comprise a system implementing XACML is shown below.

PEP (Policy Enforcement Point) – This component receives the request from the subject(s) for permission to perform an action on a resource. It forwards the request along to the PDP (Policy Decision Point) and passes back the response from the PDP.

PDP (Policy Decision Point) – This components studies the request and evaluates all the policies that are applicable to the action and resource in the request. The result of the evaluation is sent back as the response to the request.

PAP (Policy Access Point) – This component makes available all the policies and rules that are applicable in context to the PDP.

PIP (Policy Information Point) – This component retrieves information about the subject, the resource, or the environment

XACML sub-components –

• Target – The target helps in determining whether the policy is relevant for the request.
• Rules – Multiple rules can be associated to a policy. Each rule is composed of a condition, an effect, and a target.
• Condition – are statements about attributes that upon evaluation return either True, False, or Indeterminate.
• Effect – is the intended consequence of the satisfied rule. It can either take the value Permit or Deny.
• Target – helps in determining whether or not a rule is relevant for a request.
• Rule-combining algorithm – are responsible for resolving such conflicts that can arise due to different results from different rules that are being combined to arrive at one outcome per policy per request.
• Obligations – provides much finer-level access control than mere permit and deny decisions. Obligations are the actions that must be performed by the PEP in conjunction with the enforcement of an authorization decision.

If you are really excited about using the standard and are chomping at the bits to make use of it in your projects, but don’t really want to do all the work to convert the specification into a reusable .NET library. Then you are in lucky, a .NET implementation for XACML is already available in the form of XACML.NET and can be downloaded from here.

Implementing an indexer and an ‘Item’ property on a class

This is more a quick tip than anything else. Today I was trying to create a class with both an indexer and a property named ‘Item’ like below. But I was unable to compile the class with an error message saying “The type ‘Test’ already contains a definition for ‘Item'”.

    public class Test

    {

        public string this[string name]

        {

            get { return null; }

        }

 

        string _item;

        public string Item

        {

            get { return _item; }

            set { _item = value; }

        }

    }

This was due to the fact that the indexer in C# gets converted to a property name ‘Item’ internally in order to support other languages that don’t support indexers. And the ‘Item’ property I was trying to create had a conflict the ‘Item’ property that was getting created internally. However, a quick google search revealed that the problem could be easily circumvented by decorating the indexer with the ‘IndexerNameAttribute’. This forces the compiler to assign a custom name to the auto-created property for the indexer as shown below.

   [System.Runtime.CompilerServices.IndexerName(“MyItem”)]

   public string this[string name]

   {

       get { return null; }

   }

 This post will also serve as a reminder to me because I know I will run across this again in the future … 🙂

OpenSource GIS Notes

I thought I would pass along some interesting information about recent happenings in OpenSource GIS. The annual Free and Open Source Software for Geospatial (FOSS4G) conference took place in September in Victoria, Canada. This would have been a really good conference to attend with a lot of cool sessions on the latest developments in the rapidly changing world of open source GIS. The FOSS4G group has posted the presentations from the 2007 conference online. It is really good read if you are interested. It might not be as good as being able to attend the conference but it is great for developers who couldn’t afford the time off or the travel. Off the presentation I was able to read till now, I found the presentation titled “Using the Atom Publishing Protocol for Web GIS” really cool. The author talks about why the WFS standard could soon be replaced by the “Atom Syndication Format” and the “Atom Publishing Protocol“.

OSGEO announces that OpenLayers gradutes incubation. Not entirely sure what to make of it but OpenLayers does have a stable 2.5 release out. Even though their documentation has come a long way from where it used to be, I still wish they had a better design overview document and more samples that serve to illustrate the length and breadth of the currently existing functionalities. It will be of enormous help for any developer trying to get up to speed with the SDK and perhaps even enable wider adoption of the truly awesome technology.

Also, I am publishing this post using ScribeFire from within FireFox. Pretty cool.

My favorite graphs from Kathy Sierra

Here are some of my favorite graphs from Kathy Sierra. Kathy is the co-creator of the “Head First” books which I love. If you are interested in more graphs like the ones below, check out this post from Kathy.