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

  • 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á!

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

    Hi osgeoers! 

    That’s my first post going to Planet OSGEO. Just want to say hello people! :)

    Well, as for someone who is new in the community, I think it feels right to introduce myself. My name is Andrés Maneiro and I work as a GIS programmer for iCarto, a firm specialized in GIS based in A Coruña (see nice pictures here). As a training background I’ve got a Master on Free software at UJRC and a Master on Geographical Information Systems at UdG, one of the members of UNIGIS international network (well, still hard-studying to become an unigis graduate).

    My day to day with FOSS4G involves hacking with desktop and web technologies. I am one of the core developers of NavTable (a gvSIG extension which has changed totally how we visualize and manage gis data! :D ) and I’m the leader of NavTableForms (a library to easily build your own personalized survey forms for gvSIG). I usually send patches and collaborate with gvSIG development. Lately, I have been involved in projects related to European SDI for spanish administrations using the usual suspects at FOSS4G webstack and poking around the mailinglists and bugtrackers.

    My community involvevement ranges from participating in the osgeo local group activities, collaborating with Engineering Withouth Borders (mainly in the past, though) or being part of the GHANDALF founders (a volunteer-based asociation to spread the use and word of free software in my region). Also in my free time, I have led a group of 12 people to translate in a collaborative way a book by Karl Fogel about how to manage free software projects (reflections on that, in spanish: I, II and III) and a study about Free Software GIS communities (article in spanish, slides) collaborating with Cartolab.

    Wow, that’s a bit of a context, doesn’t it? :) Well, from time to time, you can expect some post from me going to the planet osgeo (RSS feed of the tag). Some of them will be in english (RSS feed); others in spanish (RSS feed). Osgeoers, keep the conversation going!

     
  • Andrés 15:59 el 16 April, 2011 Enlace permanente | Responder
    Etiquetas: , , , , , Sistemas de Información Geográfica,   

    Análisis de comunidades de Software Libre (I): resultados de un estudio sobre GRASS, gvSIG y QGIS 

    A la hora de seleccionar una aplicación se valoran habitualmente factores tecnológicos -qué nos permite hacer la aplicación- y económicos -cuánto nos cuesta lo que necesitamos. Y se nos olvida un tercer factor muy a tener en cuenta: los aspectos sociales del proyecto, la comunidad de usuarios y desarrolladores que lo mantienen vivo.

    A lo largo de una serie de post que inicio hoy voy a presentar un análisis de las comunidades de 3 proyectos de referencia en el mundo SIG: GRASS, gvSIG y QGIS. Durante el proceso de selección nos hemos quedado con estos 3 porque consideramos que son los más importantes y maduros SIG de escritorio, están además bajo el paraguas de la Fundación OSGEO y presentan diferencias en los actores que los gestionan.

    ¿Qué hemos hecho?

    En los más de 25 años que tiene el movimiento del software libre, se ha demostrado la gran capacidad de creación que tiene un modelo centrado en la comunidad. Un modelo que, además, ha mostrado su viabilidad expandiéndose a otras áreas: creación de contenidos (wikipedia), creación de datos cartográficos (openstreetmaps), traducción de libros, etc. Pero si bien conocemos su potencia, poco sabemos sobre “cómo crear y gestionar una comunidad“. Lo único que podemos hacer es observar qué han hecho los demás y cómo les ha ido. Probar. Tratar de extrapolar heurísticos de la experiencia de otros.

    Para contribruir al entendimiento de cómo funcionan las comunidades de software libre -Francisco Puga, otra gente del Cartolab y yo- hemos realizado un análisis de las comunidades en base a la información pública que generan. Los actores de una comunidad interactúan entre sí, y, cuando eso ocurre a través de internet, las interacciones dejan rastro:

    • Listas de correo: los mensajes contienen la fecha, el autor, etc.
    • Wiki: es posible obtener información sobre el autor, la fecha de creación, el número de ediciones de una página, etc.
    • Sistemas de control de errores: información sobre quién y cuándo se reportó, si está resuelto o no, etc.
    • Sistemas de control del código: podemos obtener la actividad sobre la aplicación basándonos en el número de cambios (commits), conocer quién los hizo, la fecha, etc.

    Con la base de esta información pública disponible, lo que hemos hecho ha sido un estudio cuantitativo sobre las comunidades que rodean y sostienen a estos proyectos.

    ¿Cómo lo hemos hecho?

    Gracias a la disponibilidad de ciertas herramientas que nos facilitaron el proceso de obtención de información, además de tener en cuenta la calidad de los datos para poder hacer comparativas entre los proyectos, lo que finalmente logramos hacer fue lo siguiente:

    • Sistemas de control de código: hemos volcado toda la información disponible al sistema de control de versiones git para luego parsear su histórico. Esto nos ha permitido estudiar toda la historia de desarrollo de los proyectos hasta diciembre del 2010. Datos para grassgvsigqgis
    • Listas de correo: hemos usado para ellos la herramienta mailingliststats -que construyó principalmente Israel Herráiz, thanks bro!- con datos desde marzo de 2008 hasta diciembre de 2010, en base a:

    Algunas aclaraciones sobre el estudio de las listas de correo:

    • Los 3 proyectos tienen muchas más listas para diversos aspectos (traducciones, dirección del proyecto, listas locales, etc). Nos hemos centrado en éstas porque creemos que son suficientes para marcar la tendencia, que realmente es lo que nos interesa; no los números gordos que serían engañosos.
    • En el caso de las listas de usuarios, para gvsig hemos estudiado además de la lista internacional, también la española. Ésta última es donde nació el proyecto y muestra todavía la actividad principal. No hacerlo introduciría sesgos.
    • Por desgracia, la calidad de los datos nos ha limitado el período de estudio: hemos conseguido analizar desde Marzo de 2008 hasta diciembre del 2010.

    ¿Para qué nos vale?

    El estudio de una comunidad tiene diferentes enfoques. El nuestro se basa en el modelo que divide a la comunidad en 3 niveles de participación e implicación:

    • Leaders: aquellos que construyen el producto.
    • Power users: aquellos que lo adaptan a sus necesidades y lo usan intensivamente.
    • Casual users: aquellos que lo usan para una tarea concreta.

    Esta aproximación facilita la comprensión de cómo funciona realmente la comunidad, ya que no es lo mismo la aportación de una persona a través de un único mensaje en una lista de correo a la de alguien que se ha pasado 6 meses creando la aplicación. Nos aporta además, información sobre la adopción de las herramientas así como patrones de participación y actividad entre los distintos actores.


    Con este enfoque y metodología hemos conseguido realizar los siguientes indicadores:

    • Tendencias de adopción entre usuarios: basado en las listas de correo.
    • Tendencias de adopción entre desarrolladores: basado en las listas de correo.
    • Actividad y fuerza de trabajo: basado en contribuciones de código (commits).
    • Análisis de composición de la comunidad: basado en contribuciones de código.
    • Análisis generacional: basado en contribuciones de código.

    En las siguiente semanas iremos publicando los resultados del estudio, de cara a comprender mejor cómo funciona una comunidad de software libre. Stay tunned!

     
  • Andrés 21:58 el 8 February, 2011 Enlace permanente | Responder
    Etiquetas: , , , Sistemas de Información Geográfica   

    Arqueología y SIG desde Galicia: el proyecto arqueoponte 

    La arqueología ha sido hasta hace bien poco una ciencia olvidada y cuasi-desconocida para mí, más allá de algunos estudios antropológicos que he leído (soy fan declarado de Marvin Harris) y que creo que son útiles para explicar ciertos patrones de comportamiento en la era internet. A partir de mi aproximación al mundo de los Sistemas de Información Geográfica de los últimos años, la he ido redescubriendo. Porque el mundo SIG y la arqueología caminan de la mano, al fin y al cabo…

    la arqueología consiste en la determinación del comportamiento humano, a partir de la localización de objetos materiales

    Recuerdo aún el día que llegamos de una reunión con el equipo arqueólogo que había tenido lugar en campo, en la excavación misma. Posteriormente a la reunión, participamos en una gira donde un miembro del equipo explicaba las teorías que barajaban para el enclave y la importancia que tuvo en su tiempo. Así descubrí cómo A Lanzada, durante 15 siglos, fue uno de los puertos francos de Galicia con el mundo. Y así también, consolidé la idea de que el soporte SIG, para cualquier excavación arqueológica, es imprescindible.

    Una de las cosas buenas de ganarte la vida como programador, es que ganas conocimiento del dominio en que estás trabajando. Y el proyecto ArqueoPonte me permitió reconciliarme con la arqueología. Bueno, pues me entero hoy mismo de que han salido publicados los videos de unas jornadas donde he ido a hablar sobre el proyecto y las tareas que hemos desarrollado a nivel SIG. Aunque debido a mis nuevas ocupaciones ya no estoy participando en los últimos flecos del proyecto (que llevan otros compañeros desde Cartolab) creo que merece la pena publicar el video aquí:

    Nota de contexto: el proyecto arqueoponte consiste en el desarrollo de una aplicación a medida sobre gvSIG, que permita gestionar el inventariado de excavaciones arqueológicas -como las llevadas a cabo en A Lanzada y Besomaño- para su posterior explotación.

     
  • Andrés 9:29 el 24 January, 2011 Enlace permanente | Responder
    Etiquetas: , , Sistemas de Información Geográfica   

    Información geográfica: creación de contenidos en comunidad 

    Cómo se produce información geográfica?

    Venimos de una época donde la costumbre era que los productores de información fuesen el gobierno o grandes empresas. La producción de información geográfica requiere en general grandes recursos y formación y sólo agentes de grandes dimensiones podían tener lo que hacía falta para abordar una inversión similar: recoger información en campo, validarla, introducirla en un Sistema de Información Geográfica. Todo ello cuesta mucho tiempo y dinero.

    Sin embargo, la primera década del siglo XXI nos ha mostrado una manera muy diferente de enfrentarse al problema: el community mapping, contenidos generado por el usuario o volunteering geographic information. Si bien este movimiento hacia la producción en comunidad, ha explotado antes en otros lugares -el mundo del software libre, proyectos como la wikipedia, etc- el mundo de la información geográfica tiene ya un claro referente: Open Street Map, un proyecto que nació para crear y compartir datos libres, la wikipedia de los mapas. Creado en 2004 por Steve Coast -por aquel entonces un estudiante de informática- tiene hoy millones de usuarios y una amplia cobertura mundial.

    En palabras del propio Coast:

    si yo creo el mapa de mi zona, tú el de tu zona, etc … juntos creamos el mapa del mundo completo

    (Disculpad el sonido horrible, el video lo grabamos en la cafetería. Gracias Iván por trabajar luego con los subtítulos!)

    Pero … puede OSM competir con las grandes instituciones?

    Pues en eso está. A nivel cobertura, se puede decir que en las grandes ciudades hace ya competencia a un gigante como Google. Superándolo en ciertas capitales, como se puede ver en este mapa de cobertura mundial (los círculos rojos son de Google Maps, los amarillos de OSM):

     

    Más info sobre cobertura:

    El siguiente reto es verificar la calidad de los datos. Construyendo la analogía con otros proyectos similares de comunidad, se podría sugerir que la calidad dependerá del número de voluntarios que trabaje en un mismo área. La ley de Linus. Pero, ¿es esto cierto? Recientemente, ha sido publicado un interesante paper sobre el tema. La serie de investigaciones realizadas tratan de responder a la pregunta… ¿cuántos voluntarios hacen falta para mapear con calidad un área?, es decir, tratan de cotejar la Ley de Linus en el ámbito de los mapas. Los resultados: para un área de cobertura de 15 voluntarios por kilómetro cuadrado, el error posicional es menor a 6 metros. Lo que nos sugiere que a medida que se una más gente al proyecto y se democratice, OSM se consolidará como alternativa a Google Maps en cobertura y calidad.

    Lo que es claro es que la producción en comunidad se consolida cada vez más como un sistema de producción más allá de la empresa o el mercado. Software, contenidos enciclopédicos, redes sociales, información geográfica, … es sólo el principio!

     
  • Andrés 20:32 el 12 January, 2011 Enlace permanente | Responder
    Etiquetas: , , Sistemas de Información Geográfica   

    De los Sistemas de Información Geográfica: 2 videos imprescindibles 

    El primero de ellos es el famoso “Data for decision” de Roger Tomlinson -comunmente conocido como el padre de los SIG. Durante 7 minutos, el mini-documental presenta qué es un SIG y para qué vale.

    Data for decision fue realizado en 1967 con el objetivo de conseguir financiación estatal para el primer SIG de Canadá. Me sorprendió ver cómo 40 años después se mantenía igual de didáctico, fresco… y, bueno, es cierto que tiene su puntito retro ver los efectos con que adornaron el video en los 60 :D El documental se ha publicado en 3 partes, aunque la primera es sin duda la mejor.

    El segundo, un poco más avanzado, es una charla de Michael Goodchild en la National Science Foundation. El video es útil para comprender cosas como Open Street Maps -la producción de información geográfica en comunidad- y las bases del análisis geográfico con una de las personas que más ha impulsado su desarrollo.

    • Durante los primeros 15 minutos Goodchild presenta las bases de la generación de información geográfica por la comunidad (también conocido community-mapping, volunteered geographic information, …). Lo explica de un modo sencillo, claro, sin pretensiones ni rodeos.
    • Del minuto 15 al 25, explica varios ejemplos de casos de emergencia donde esta aproximación tiene grandes beneficios.
    • Termina el video centrándose en explicar conceptos clave de análisis geográfico con casos de ejemplo muy claros.

    Tanto Tomlinson como Goodchild son muy buenos comunicadores y eso se nota en los videos. Y bueno, sobra decir que tienen un gran conocimiento de los SIG!

     
  • Andrés 0:35 el 27 December, 2010 Enlace permanente | Responder
    Etiquetas: , , , , Sistemas de Información Geográfica,   

    Participación empresarial en software libre: el curioso caso de QGIS y KCube Consulting 

    QGIS es una de las aplicaciones de software libre más populares en el mundo de los Sistemas de Información Geográfica. Como buen proyecto de software libre gente de diversa índole participa en él llevada por diferentes motivaciones. La historia que me gustaría contar hoy es la de la empresa KCube Consulting, que ha ofrecido a la comunidad QGIS un desarrollador a tiempo completo durante 6 meses.

    Cesión de tiempo: directa e indirecta

    Hoy en día, es más bien habitual que las empresas participen en proyectos de software libre. Si bien, en general, lo que nos encontramos es que una empresa participa en el proyecto centrándose en aquellas partes que más le interesan. Por ejemplo, si eres una empresa que vende tarjetas de video es probable que participes en el desarrollo del kernel de linux dando soporte a tu tarjeta gráfica, de cara a que los usuarios puedan usarla en plataformas Linux. Ese tipo de “cesión de tiempo indirecta” es ya muy común.

    La oferta de KCube Consulting, que podríamos llamar “cesión de tiempo directa“, es también una ruta ya explorada en el mundo del software libre, aunque menos habitual que la anterior. Sin embargo, como bien resume Tim Sutton en el post de presentación de la oferta, esta aproximación tiene grandes ventajas:

    • A nivel técnico: la organización va a colaborar codo con codo con los core developers del proyecto. Además de forjar relaciones sociales con la comunidad, desarrollará un conocimiento profundo a nivel técnico de cómo funciona QGIS. Esto, a medio plazo, le permitirá ofrecer a sus clientes mejores servicios sobre QGIS.
    • A nivel marca: la empresa KCube Consulting se asocia al producto QGIS. Cualquiera que visite el blog y vaya en busca de empresas que provean servicios para QGIS verá a KCube Consulting como una buena opción. A falta de valorar otros aspectos, KCube tiene ya una buena primera impresión. A nivel márketing y comunicación pocas acciones podrían tener tan buen retorno.

    El proceso para gestionar su participación

    Una vez planteada la oferta, toca pensar: ¿y cómo gestionarla? ¿Tiene la comunidad QGIS recursos para dar soporte a esta petición? ¿Tiene una dirección técnica que permita priorizar las tareas y sacarle rendimiento? Veamos cómo lo ha hecho.

    1. El primer paso ha sido que, Tim Sutton, uno de los principales mantenedores del proyecto, posteó en su blog la oferta de KCube Consulting abriendo el proceso a la comunidad.
    2. A través de una página wiki del propio proyecto, cualquier persona participante del proyecto podía enviar propuestas sobre el trabajo a realizar por el desarrollador de KCube durante los 6 meses.
    3. Con esas ideas y una encuesta posterior en la página del proyecto se están sacando las líneas generales sobre las que trabajar estos 6 meses.

    Este es un proceso que aún no ha terminado y en 6 meses veremos los resultados. Pero lo que está claro es que abrir el proceso de toma de deciciones a la comunidad que participa en el proyecto, es muestra de una madurez grande. Esta anécdota habla de que la dirección técnica es compartida y las decisiones pueden (y son) realizadas de un modo abierto y transparente, conjuntamente con la comunidad. Son, además, realizadas a través de los medios virtuales de los que se dota el proyecto, para garantizar que cualquiera pueda participar.

    Conclusiones

    • La cesión de tiempo directa a un proyecto de software libre no sólo favorece la formación de técnicos en la empresa. Si no que, a primera vista, la posiciona ante los ojos del mercado como uno de los proveedores a valorar.
    • En proyectos de software libre, tener una dirección técnica del proyecto abierta a la comunidad no sólo es posible, sino que enriquece la toma de decisiones y lanza un mensaje claro a todo a el mundo: esto se contruye entre todos.
     
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