How gvSIG MapControl works: flow of control

Within gvSIG design, MapControl is one of the core components. Its main responsibility is to allow users to interact with a map of layers (zoom in/out, edit geometries, …). That goal is achieved through two concrete tasks:

  • Route the user actions to the proper tool which will execute it.
  • Manage the drawing of the layers.

This post covers the first of above tasks in an introductory way.

Flow of control

MapControl is a java component, which uses the idea of Chain of Responsibility to delegate work on others. Let’s see how it works in this case with a good old graphic:

  1. MapControl listen MouseEvents through the MapToolListener. In response to an event, the MapToolListener will call the active tool (let’s say this class is named Behaviour).
  2. The active Behaviour processes the info from the mouse, put together the contextual information needed (let’s call that an Event) and calls the next step in the chain (let’s call it the ToolListener).
  3. Finally, the ToolListener will execute the actions needed to carry on the task an user have asked for.
Some notes before digging into code:
  • MapControl can have only 1 tool (Behaviour) active at any time. It holds the current selection in a private variable: Behaviour currentMapTool
  • MapControl wraps MouseEvents in 4 basic canonical events (see within libFMap project): MeasureEvent, PointEvent, MoveEvent and RectangleEvent. Any other event will inherit from and extend one of these canonical forms.

A concrete example: how a move event is processed

1 – MapToolListener: listen the mouse event and proxy it to the current selected behaviour (currentMapTool variable).

public void mouseReleased(MouseEvent e) {
    try {
        if (currentMapTool != null)
    } catch (BehaviorException t) {

2 – Behaviour (MoveBehaviour in this case): takes the event, put together the context (MoveEvent) and redirects the petition to the proper ToolListener (listener variable).

public void mouseReleased(MouseEvent e) throws BehaviorException {
    if (e.getButton() == MouseEvent.BUTTON1 && m_FirstPoint!=null) {
        MoveEvent event = new MoveEvent(m_FirstPoint, e.getPoint(), e);
    m_FirstPoint = null;

3 – ToolListener: carry on the task. In this case, the listener (a PanListener) make the viewport to update the extent with the new contents.

public void move(MoveEvent event) {

    ViewPort vp = mapControl.getMapContext().getViewPort();
    Point2D from = vp.toMapPoint(event.getFrom());
    Point2D to = vp.toMapPoint(event.getTo());

    //build the new extent
    Rectangle2D.Double r = new Rectangle2D.Double();
    Rectangle2D extent = vp.getExtent();
    r.x = extent.getX() - (to.getX() - from.getX());
    r.y = extent.getY() - (to.getY() - from.getY());
    r.width = extent.getWidth();
    r.height = extent.getHeight();

    //update the ViewPort


Some useful resources about MapControl in gvSIG wiki:

Links to code:

Analysis on free software communities (I): a quantitative study on GRASS, gvSIG and QGIS

Disclaimer – this post is part of a serie: I (this one), IIIIIIV and V.

When selecting an aplication, it’s very common to weight tecnological factors -what the aplication enable us to do?- and economic ones -how money do we need?. And yet, there is a third factor to take into account, the social aspects of the project: the community of users and developers who support it and make it be alive.

During a serie of posts begin with this, I’m going to show a quantitative analysis of communities from 3 reference projects in GIS arena: GRASSgvSIG y QGIS. We selected those, as they are viewed as the more mature projects in desktop GIS, they are under OSGEO Fundation umbrella and show some differences on the actors who bootstrapped and manage today.

What we have done?

During the more than 25 years of free software movement, it has delighted us with the high capacity for fostering creation and innovation a community-based model has. Along last years, that model proved its viability in other areas too: content creation (wikipedia), cartographic data creation (openstreetmaps)translating books, etc. Yet, few is known on “how to bootstrap and grow a community”. The only thing we can do is observing what others have done and learn from their experience.

In order to contribute to the understanding on how a community-based project works I’ve work with Francisco Puga and other people from Cartolab to put together some of the public information the projects generate and make some sense from that. The actors in a community interact with each other, and, when that happen through internet, a trail is left (messages to mailinglists have author information and date, code version systems log information about the authors too, …). Basing our work on this available and public information -and standing on the shoulder on giants –i.e: reviewing a lot of research works similar to what we like to build- we have developed a quantitative analysis on the communities supporting GRASS, gvSIG and QGIS.

How did we make it?

The first step was to evaluate and gather all the public information a project, for what we like to do it in automated way. But, as we had to compare the 3 projects, the data had to be homogeneous: at least exists in both 3 and be in a comparable format. Taking these constraints into account (and the limited time we had for this!) we have collected information from 2 different systems:

  • Code versions control systems: from every project, we cloned all information available in their repositories to a local git repo, in order to parse the log of changes. This allowed us to study all the history of projects, from the very begining to December 2010.
  • Mailinglists: by means of mailingliststats tool -built mainly by our friend Israel Herráizthanks bro!– we gather data from March 2008 to December 2010.

Some disclaimers:

  • Projects have a number of branches, plugins and so. We focused the study on the main product, what an user get when she downloads it. Further study on the plugins ecosystem is needed, and it will give us more fine-tuning information.
  • Projects have a number of mailinglists more than we have studied (translators, steering committee, other local/regional mailinglists, etc), varying on each case. The analysis was focused on developers and users ones due to we think they are representative enough to mark the trend. We are not interested in giving an exact number (which may be impossible to measure!) but in drawing the long-term fluctuation of participation. Our intuition and past experiences, says that those mailinglists will follow a correlation of participation with the larger community surrounding the projects.
  • In the particular case of gvSIG users mailinglists, we have studied spanish and english mailinglist jointly. It makes sense doing so as the spanish mailinglist still have the core of contributions from hispanoamerican countries and non-spanish people interacts through international mailinglist. It is like the project have two hearts.
  • Unfortunately, quality of data have limited the period in study: the range is from March 2008 to December 2010. Prior to that, not all projects have information due to mailinglist migrations.

What is it useful for?

It’s possible to analyze a community from a variety of points of view. Our approach is a quantitative focus by means of a common model which agregate users depending on their level of participation:

  • Leaders: those who build the product and make the decisions.
  • Power users: those who adapt it to their needs and using it intensively.
  • Casual users: those who using it for a concrete task.

This approach allow us to better understand the size of the community and how they interact, as it’s not the same the value provided by someone who in 6 months only sent 1 mail to a mailinglist than other person who spent that time sending more than 100 patches to the code.

With these constraints, we managed to built the following indicators:

  • Adoption trend within users and developers: based on mailinglists data.
  • Activity and manpower: based on code contributions (commits).
  • Composition of the community: based on code contributions (commits).
  • Generational analysis: based on code contributions (commits).

During next weeks, I will be publishing the results of the study, in order to help us to understand how different free software communities work, and what we can learn from that. Stay tunned!


The results shown here are borrowed from a paper I led jointly with Francisco Puga, Alberto Varela and Adrián Eirís from Cartolab, a GIS university research laboratory based on A Coruña. The results were shown on the V Jornadas de SIG Libre, Girona 2010. If you are fluent in spanish (reading or listening), you can benefit from these resources:

From those who can’t, I’ll summarize the main points through small posts on each topic’s paper. The original authors have not reviewed the text as published in my blog, so consider any opinion expressed here as my own (have them to review my texts is a boring and time-consuming task I’m sure they prefer to skip). Please, beg my english.

Wiki update

Done some reorganization on wiki contents and wrote a bit on refactoring and code smells. I’m proud on the pace and themes the wiki is evolving: I have grown quite a bit of software development topics, which is a reflection on my readings and focus last years. Although could evolve later, the topics on software development are organized in 3 subcategories:

Automattic Creed

«I will never stop learning. I won’t just work on things that are assigned to me. I know there’s no such thing as a status quo. I will build our business sustainably through passionate and loyal customers. I will never pass up an opportunity to help out a colleague, and I’ll remember the days before I knew everything. I am more motivated by impact than money, and I know that Open Source is one of the most powerful ideas of our generation. I will communicate as much as possible, because it’s the oxygen of a distributed company. I am in a marathon, not a sprint, and no matter how far away the goal is, the only way to get there is by putting one foot in front of another every day. Given time, there is no problem that’s insurmountable.»

— Automattic Creed

The values on which Automattic bases its roots on.

Growing a community: some texts

I’m a longer passionate on community-oriented products: I’ve researched on how they workhave led one to their goal and participate in some. It’s not a new story what they are considered a powerful way to build your products (sometimes, a better one than doing in through the market or internally in a firm/closed-group-of-people). Nevertheless, I’m still looking for some good resources to learn more. For those who like the topic, find here someones I found useful (and I’d like hearing your recommendations!):

  • Producing Open Source Software: the best book I’ve read on how to manage free software projects. Not only a good review on several tools, but also take into account the policies, what gives sense and glue together the community. Very practical.
  • Coase’s Penguin, or Linux and the nature of the firm, by Yochai Benkler. The best academic text I’ve ever red on the matter. Benkler tries to explain why in S-XXI communities emerge as a new way to build products. You will find parallelism to the text where Coase explained why firms emerged in the S-XIX and replace local markets as preferred option. I think some more work is needed to formalized this concept in the academic arena, but the paper is clear, understandable and put the basis to further research. It’s a pioneer.
  • Community antipatterns: a good talk by Dave Neary. Although it’s also focused on software development, I think it has lessons for broad communities. Sometimes, and much more in recently discovered fields, we have no idea what have worked, but know what have no worked.
  • Other’s experiences. Particulary, I’ve found very useful these texts:
In the road to understand how a community fully works, you will review topics as economics, group interaction and even antropology! I find it very intructive. As broad as the theme is, it has plenty of room to learn more of other sciences. So, being involved in a community, study or just read about it’s a good oportunity to learn.

Los costes de no trabajar upstream

Imagina el siguiente caso: deseas usar una aplicación que es software libre para construir tu propia solución ad-hoc sobre ella. Y lo harás muchas veces para diferentes clientes/productos. ¿Cómo enfocarlo? ¿Construyes tu solución con tus mejoras para ti modificando lo necesario o integras tus mejoras en la versión upstream, en el proyecto original?

Si ése es tu caso, te recomiendo que leas estos 2 artículos. El primero se centra en los aspectos económicos y sociales, el segundo en los técnicos y sociales:

  • The cost of going it alone, de Dave Neary. Un buen repaso histórico con casos como el de  Softway con GCC (cambios relacionados con Windows NT), Nokia con GNOME (cambios relacionados con Maemo) o Google e IBM con el kernel (el primero por cambios en Android, el segundo por cambios relacionados con drivers para manejar discos virtuales).
  • Working with upstream: an interview with Laszlo Peter, by Stormy Peters. Laszlo Peter era release engineer en Sun, es decir, quien se tenía que preocupar de que en cada nueva release de Solaris todo fuese bien.
Luego de leerlos, tendrás una visión más clara de si te compensa o no trabajar con upstream. Si lo que deseas es construir una aplicación vertical con una buena integración (y menos costes de mantenimiento) para sucesivas versiones del software base, la respuesta será .

gvsig vs qgis

I’m not such a fan of comparatives to rank things. But I find them useful to know your pros and cons, or at least to know how the surrounding community perceive your product. While having a coffee today I found this article on gis @ stackexchange: QGIS and gvSIG comparison. Made me happy than 2 out of 6 gvSIG pros are tools where I’m engaged: NavTable and OpenCADTools. Keep rocking cartolab and iCarto!