Etiquetado: Sistemas de Información Geográfica RSS Mostrar/ocultar comentarios | Atajos de teclado

  • Andrés 8:00 el 8 November, 2011 Enlace permanente | Responder
    Etiquetas: , , icarto, Sistemas de Información Geográfica   

    JIDEE 2011 

    Mañana estaré volando a Barcelona para asistir a las JIDEE 2011. El jueves 10 tendré el honor de presentar IDEPo, el nodo IDE de la Diputación de Pontevedra con datos EIEL, un proyecto financiado por la Diputación de Pontevedra y la Xunta de Galicia. Un proyecto que hemos liderado desde iCarto con la colaboración de Cartolab.

    No se me ocurre mejor acompañamiento para un proyecto como éste donde el conocimiento de los datos es crucial. Poca gente en España conoce los datos y procesos EIEL tan bien como ellos, una pequeña muestra es el gran trabajo que han liderado con gvSIG-EIEL. Si queréis saber más de IDEPo o simplemente hablar de iCarto, estaré disponible en el WTC al menos todo el día del jueves.

     
  • Andrés 12:27 el 7 October, 2011 Enlace permanente | Responder
    Etiquetas: , , , , Sistemas de Información Geográfica,   

    Analysis of free software communities (III): activity and manpower 

    • Images: on the left, the number of changes to the codebase (commits) agregated by year. On the right, the number of developers with at least 1 commit that year.
    • Data: trunk from project repositories during the period 1999-2010.

    Is it something we could extrapolate from the data there?

    Certainly, not the number of features developed or bug fixes. It is even barely possible to compare activity between projects, as there are a high variability in terms of changesets: some people could send several little changesets and others just 1 big change, some project could have a special policy which affect the results (i.e.: make a commit formatting the code accoring to the style rules and other with the changes), etc. Some people could even argue that the language they are written in affects the number of changes (GRASS is written in C, gvSIG in Java and QGIS in C++) due to the libraries available or the semantics of every language. So, is it possible to find out something? Well, in my opinion, we can trace at least the following:

    • the internal evolution of a project.
    • how a project is doing in terms of adding new blood.

     So, let’s make again the exercise of finding out what’s happening here:

    GRASS

    • It calls the atention the curve of activity in the project: growth by periods (2001-2004 and 2005-2007) with local maximums in 2004 and 2007. Our hypothesis was that it was due to the way the project works: the developers here make changes both in the trunk and in the branch of the product to release (be it 6.4 or 6.5) at the same time, with a lot of changesets moved between both the trunk and the branches (so doing heavy backporting). In a recently conversation with Markus Neteler, he has explained me better how they work and I guess the rhythm we see in the graphics is due to that.
    • In terms of number of developers, GRASS has showed a continuous growth until 2008; since then, the number of regular developers stabilizes.

    gvSIG

    • gvSIG shows an incredible high period of activity during 2006-2008 (4500 changesets by year and most that 30 people involved!). To understand the Gauss bell of activity, is needed to know the background of the project: gvSIG development has been led by contract, which means that all activities (planning, development, testing, etc) were led by the client needs who pay for it. Only recently, these processes have been opened to a broader community (firms and volunteers collaborating in the project within the gvSIG association). So, it makes sense that the beginnings had seen less activity (high phases of planing) and afterwards they got to agregate so many people in such a short period of time.
    • But, in 2010 it suffered a sudden stop in development (only 233 changes to the codebase were made, while a pace of 4500 changes were made during previous years). This decreasing in activity is highly correlated to the number of developers involved. It’s hard to say why it happens: could it be due to the efforts were directed to gvSIG 2.0 development? could it be due to the reorganization in the project and the creation of gvSIG asociation? Well, few can we said at this respect with the data available, further research is required to determine that.

    QGIS

    • Steady grow both in terms of contributions and contributors. 2004 and 2008 years determine two peaks of activity and people participating in the development. Our preliminar hypothesys was that it was due to the release of the first stable version and the release of 1.0, as well as become an oficial project of OSGEO. Gary Sherman has confirmed that in a recent post (history of QGIS commiters) and an interview (part1 and part2). Besides, he pointed out that in 2007 the project added python support for plugin development, which possibly was one of the reasons of the growth in 2008 and afterwards.
    • An interesting finding is that, every 4 years the project has doubled the amount of developers involved with a slower but steady growth in activity.
    Well, hope these graphics have helped us to understand better how is the project activity and the manpower every project is able to aggregate around it. Next posts in the serie, will focus on the developers involved and the culture surrounding them. Looking forward to your feedback!
     
    • cesare 18:33 el 7 octubre, 2011 Enlace permanente | Responder

      Hi, very interesting post! Only a question: where do you foind the data taht you’ve used in the charts?

      • amaneiro 17:29 el 8 octubre, 2011 Enlace permanente | Responder

        Hello Cesare, the data comes from the code repository of every project. We parsed it and generated the stats. If you are interested in playing with them, find them here.

    • Jorge 6:15 el 10 octubre, 2011 Enlace permanente | Responder

      Regarding gvSIG I guess you were looking at gvSIG main repo, I don’t know. Just for the records, I want to note that gvSIG 2.0 development has been exploded to several OSOR projects and because of maven modularity there are many different locations where activity happens. César Ordiñana has been maintaining the list of repos at gvSIG Desktop 2.0 entry at Ohloh http://www.ohloh.net/p/gvsig-desktop-2/enlistments

      I agree that gvSIG development has decreased in activity by “main contracts” but it’s increasing the contributions my small contracts that public administrations make to improve some specific parts of the products. I like a lot this way, as it demonstrates the maturity of understanding of public bodies decision makers regarding what free software is (pay for improvements and maintenance, not just for new ultra-cool features).

      There are more to discuss here but well, it’s enough for a blog comment :-)

      Nice reports!!

  • Andrés 20:00 el 5 October, 2011 Enlace permanente | Responder
    Etiquetas: , , , , Sistemas de Información Geográfica,   

    Analysis of free software communities (II): adoption trends 

    Find below the statistics for mailinglist activity in GRASS, gvSIG and QGIS during the period 2008-2010. The first one shows data from the general user mailinglists for each project. Take into account that data for gvSIG agregated both international and spanish mailinglist due the reasons stated here.

    The next one shows the same data (number of people writing and number of messages by month) for the developers mailinglists.

    Is it something we could extrapolate from the data there?

    Well, certainly not the user base. The data shyly introduce us the trends, not the real user base. The model we adopted to study the projects reflects just a part of the community -which is arguably the engine of project- but don’t take the data as the number of users for each project. For sure, each one of our favorite projects has more users than those participating in (these) mailinglists!

    Anyway, here some food for thought:

    • GRASS: it smoothly decreases in terms of number of messages as well as people writing, which happen within users and developers. The tendency is not clear though.
    • gvSIG: the data shows a steadly increasing number of users participating in the mailinglists. On the other hand, although it is the project with more people suscribed to developer mailinglist, it shows the less activity of the three projects (in terms of # of messages in developer lists): few technical conversations seemed to happen through the mailinglists during that period.
    • QGIS: according to the data, a clear growth exists in the community. In the period in study (3 years) the number of users and developers participating in mailinglists has been doubled!
    Few more can be said, hope the graphics are explicative enough! Looking forward to your feedback.
     
  • Andrés 19:26 el 28 September, 2011 Enlace permanente | Responder
    Etiquetas: , , , Sistemas de Información Geográfica   

    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 com.iver.cit.gvsig.fmap.tools.Events 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)
            currentMapTool.mouseReleased(e);
        } catch (BehaviorException t) {
            throwException(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);
            listener.move(event);
        }
        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
        vp.setExtent(r);
    }

    Coda

    Some useful resources about MapControl in gvSIG wiki:

    Links to code:
     
  • Andrés 9:49 el 24 September, 2011 Enlace permanente | Responder
    Etiquetas: , , , , Sistemas de Información Geográfica,   

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

    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).
      • Status: still to be published.
    • Generational analysis: based on code contributions (commits).
      • Status: still to be published.

    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!

    Coda

    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.
     
    • Markus Neteler 16:36 el 25 septiembre, 2011 Enlace permanente | Responder

      Hi,

      a quick feedback: in table “Tabla 3: Top 10 desarrolladores – GRASS” the committers “markus” and “neteler” are the same person… that’s me. In a future version of the document, maybe put it together
      into one line as “markus|neteler”.

      cheers
      Markus Neteler

      • amaneiro 17:33 el 25 septiembre, 2011 Enlace permanente | Responder

        Yep, we supposed it. Your case is not the only one, though, but we couldn’t find the time to research this in more depth (for example: asking the own users, matching the mails, …).

    • Markus Neteler 16:45 el 25 septiembre, 2011 Enlace permanente | Responder

      A comment concerning the GRASS GIS repository. Of course it is a fact that the first version was published in 1984. But since no civil internet existed nor any distributed versioning system, it is only traceable back till 1999. We decided to put GRASS into CVS the day before the famour “year 2000″ bug… So slide 4 of your presentation should be corrected (likewise the document). See also http://wiki.osgeo.org/wiki/Open_Source_GIS_History

    • Markus Neteler 16:59 el 25 septiembre, 2011 Enlace permanente | Responder

      The “user trends” of just 2.x years (2008-2011) are too short for multi-year projects. Find the mailing list statistics since 1999 (note that the GRASS lists were started in 1992!) here:

      http://markmail.org/search/?q=qgis

      http://markmail.org/search/?q=grass%20gis

      http://markmail.org/search/?q=gvsig

      • amaneiro 17:55 el 25 septiembre, 2011 Enlace permanente | Responder

        Oh, what an amount of data for a research-junkie as me :) I’ll compare that to ours findings. Thanks!

    • Cameron Shorter 3:58 el 2 octubre, 2011 Enlace permanente | Responder

      Hi,
      I’m fascinated by studies such as you have described, as users are regularly asking us at LISAsoft about recommendations on which Open Source project they should use, and I’d love to be able to base my response upon some solid metrics.

      In particular, I’d love to be able to point people at metric results for all the 50 odd projects which have been included on the OSGeoLive DVD. http://live.osgeo.org

      On a related note, I’ve written a more subjective description about the keys to success building the OSGeoLive community here: http://cameronshorter.blogspot.com/2011/06/memoirs-of-cat-herder-coordinating.html

      Cameron Shorter

    • Barend Köbben 7:07 el 6 octubre, 2011 Enlace permanente | Responder

      Putting the Spanish and English lists of gvSIG together is basically cheating… You should have included all non-english lists for all the softwares.

      • amaneiro 8:26 el 6 octubre, 2011 Enlace permanente | Responder

        Barend, I don’t think so. The indicator try to measure the trend, not the exact number. It’s very wrong to see it as it was the user base, which I suppose was your point. If we tried to do the later, summing both lists will be very inappropiate, as you suggest. But if you try the former I think it makes sense, as the community is splitted in both spanish-speaking and english-speaking (which no happens in the other projects). Basically, the project has 2 hearts with activity, and the tendendy in one place can affect to the other.

        Although measuring all mailinglists would be the ideal situation, we couldn’t afford that.

        Nevertheless, the tendency agregating both or taking into account the lists separately is the same, so it supports our initial guesses.

  • Andrés 19:03 el 7 September, 2011 Enlace permanente | Responder
    Etiquetas: , , , Sistemas de Información Geográfica   

    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!

     
  • Andrés 2:26 el 8 August, 2011 Enlace permanente | Responder
    Etiquetas: , , , Sistemas de Información Geográfica   

    How gvsig manages the snappers 

    Last week I paired together with Francisco Puga to review the status of opencadtools. As Fran is doing a great work in preparing the integration of opencadtools as default CAD tools in gvSIG, I wanted to know first hand how it was going. iCarto and Cartolab were kind enough to sponsor this pairing session. One of the results, apart from working with Fran -which is always motivating and enjoyable, per se-, was a deeper understanding on how snappers work in gvSIG, which is something I had asked myself sometimes. And, as one of the improvements of opencadtools is a followgeometry snapper, it seems a good goal to review that part of the project. Find below the summary:

    CADToolAdapter class in extCAD extension maintains a list of snappers and layers to snap to from the editing layer. When the mouse is moved, the snappers are recalculated following this algorithm (note that the code below is the core of the method, some other parts/casts and boilerplate code is missing):

    ArrayList snappers = SnapConfigPage.getActivesSnappers();
    ILayerEdited layerInEdition =
        CADExtension.getEditionManager().getActiveLayerEdited();
    ArrayList layersToSnap = layerInEdition.getLayersToSnap();

    for (FLyrVect layer : layersToSnap) {

        // Getting the set of geometries within the envelope
        // The envelope is calculated based on the tolerance the user wants
        SpatialCache cache = layer.getSpatialCache();
        List geometries = cache.query(envelope);

        // Updating the nearest point
        for (Feature geomToSnap : geometries){
            for (int i=0; i<snappers.size(); i++){
                Point2D pointToSnap = snappers[i].getSnapPoint(queryPoint,
                                                    geomToSnap,
                                                    tolerance,
                                                    lastPointEntered);
            }
            double distance = pointToSnap.distance(queryPoint);
            if(minimunDistance > distance){
                    minimunDistance = distance;
            }
        }
    }

    This algorithm is executed every time the user move the mouse and is very quick if you have few layers to snap to. But, as the number of layer to check increases, the editing process becomes very slow. Besides, as a comment of software design, after reviewing this part of code, I like the way the snappers fit in gvsig cad tools. If you want to add a new snapper, just need to implement ISnapperVectorial interface and make getSnapToPoint method to return the nearest point to the position of the mouse. So, designing your own snappers is very easy!

    By the way, if you feel like replying how other GIS applications (QGIS, uDig, …) manage the snappers, I’d be more than happy to hear and learn that!

     
  • Andrés 15:05 el 22 July, 2011 Enlace permanente | Responder
    Etiquetas: , , Sistemas de Información Geográfica   

    ¿Usuarios habituales de gvSIG? No os perdáis esta extensión que añade nuevas funcionalidades al TOC estándar que acaba de liberar Cartolab.

     
  • Andrés 6:37 el 20 July, 2011 Enlace permanente | Responder
    Etiquetas: , , , , Sistemas de Información Geográfica   

    gvSIG codesprint in A Coruña: a personal summary 

    As you may know, iCarto and Cartolab have hosted a gvSIG codesprint at the nice city of A Coruña. iCarto was kind enough to support my attendance to the event to work on gvsig, navtable & navtableforms. Find below some comments on my personal experience.

    Some general impressions on the event

    • It’s great to see codesprints are becoming usual in gvsig project. It’s still a new practice to be fully embraced for most members of the community but taking into account that the the first codesprint I proposed was almost 1 year ago, we have good rithm (this was the 4th codesprint!). It feels good to see such an amount of people and energy during the codesprint. It is encouraging and talks about their commitment to the project.
    • This codesprint was the 2nd in number of participants after the one in Valencia! That confirms that Galicia matters :) That was the good news. The bad ones: I’ve missed developers from England (do you know London is directly connected to A Coruña by flight?), Portugal (don’t you know that we speak the same language?!) and more people, shops and gvSIG members & collaborators from Spain, though. We should try harder to bring people to codesprints.
    • That kind of events are great to grow relationships and trust. Also they are great to communicate diffuse information and transfer knowledge: we had some good conversations with Joaquín del Cierro (gvSIG development manager) about the technological background of the project, how some decissions are made and the direction of the development theses days.

    NavTable and NavTableForms: what we have done

    In the hacking side, I’m pretty happy with the results. Most of the time, Jorge López and me paired together to resolve the priority things on NavTable and NavTableForms. Here the results:

    NavTable

    • Flavio Pompermaier had talked us about the differences between layer.getSource().getRecordset() and layer.getRecordset() methods. Roughly: the second returns the features directly from the source, which seems to reflect changes (schema modifications, add new registers, etc) in real time. I spent a time to reproduce the bugs he showed us but I couldn’t. The last work on listeners done by Javier Estévez and to be integrated in gvSIG 1.12 had solved it.
    • Having some good conversations with Nacho regarding past conversations and improvements on NavTable UI. Some of the proposals will appear soon on your favorite mailinglist!
    • Having some good conversations with Joaquín on metadata and filtering in gvSIG, which resulted on:
      • metadata: the better way to integrate metadata into gvSIG sources is by doing your own custom mechanism, as we already have (for example: to associate to the data domain-values or validation). There is no such a thing of a broad standard on the matter (although there are some attempts).
      • pre-filtering from datasource (definitionExpression in other GIS applications): I had asked that in the mailinglist (and even got a only-read solution). Lately, it appeared again in gvsig-international a thread talking about that. The short answer: it’s not possible to do it now.
    • Refactoring to actions. I work on this during Friday morning. It was more difficult that I thought as our codebase is very coupled at some key part, which required an aditional work to do this. What I got is an initial prototype working (uploaded to a temporal branch on our repo) only with the moving actions (go-next, go-last, go-previous, go-first). Although still a prototype I think is very promising as a base to work on.

    NavTableForms

    • Landing into trunk, the big rewriting done in NavTableForms. Jorge and I spent thursday morning reading code, updating the example for it to work with the new code and with integrating issues. It was easier that I thought, and we had the example working in less than 3 hours. I even write down our mini-guide to migrate the example, as it could be interesting for other people.
    • Add support for reading domain values from a text file. One of the news on NavTableForms is that it’s able to read domain values from a database (say postgress). Jorge worked to add support for textfiles in a similar way than we do for alias.
    • Adding support for multiple validation rules. Jorge worked and integrated this very nice feature.
    • A new validation rule: mandatory field. I commited this to repo. By the way, It’s nice to see how easy is to add a new rule.

    Summing up: as you may see, they were two intense days! A lot of work done and the hacktivation energy at full again. Looking forward to next one!

     
  • Andrés 18:42 el 9 July, 2011 Enlace permanente | Responder
    Etiquetas: , , Sistemas de Información Geográfica,   

    Poco a poco el wiki toma más contenido. En los últimos días he estado añadiendo técnicas, conceptos, personajes y eventos del mundo SIG que almacenaba en local. Está muy en pañales todavía y, debido a la actividad de la última semana, contiene principalmente conceptos e ideas relacionados con el análisis geográfico. Pero crecerá!

     
c
crear nuevo post
j
siguiente post/siguiente comentario
k
anterior post/anterior comentario
r
responder
e
editar
o
mostrar/ocultar comentarios
t
ir al principio
l
ir a la página de ingreso
h
mostrar/ocultar ayuda
shift + esc
cancelar