martes, octubre 07, 2008

Más del FOSS4G

Además de las cosas que puse en la última entrada, hay algunos otros asuntos que merecen ser mencionados sobre la conferencia de Sudáfrica, y que pongo a continuación:

Nuevos algoritmos: Una de las cosas que me han entusiasmado más de ver cómo la gente responde a la nueva situación de SEXTANTE es el hecho de que empieza a considerarse como una plataforma para estandarizar el acceso a algoritmos geoespaciales, y que empiezan a darse cuenta de que no existe en este momento algo similar y de que la importancia que puede cobrar de aquí en adelante es grande (esperemos que así sea...). Esto hace que haya ya ciertos grupos que se interesen en migrar sus algoritmos de análisis para beneficio propio y de todas aquellas otras aplicaciones que actualmente usen SEXTANTE, así como de todas las que en un futuro puedan emplearlo. Las propuestas mas interesantes son:
  • pgRouting. Con Anton Patrushev(que como buen ruso es hospitalario y me ha invitado a ir a verle en Enero a Novosibirsk cuando pase por alli, cosa que haré), tienen intención de migrar código en C++ de sus rutinas de análisis de rutas.
  • uDig. Recientemente se ha publicado una extensión para triangulación y calculo de curvas de nivel directamente desde una capa de puntos, que se ha desarrollado dentro del Google Summer of Code. Quieren adaptarla a SEXTANTE para que pueda seguir corriendo en uDig, pero también en otras aplicaciones.
  • JGrass. Tengo que echarle un vistazo con más detalle, pero creo que puede haber mucha colaboración aquí, ya que los algoritmos cuadran bien, algunos de ellos no están en SEXTANTE, y además JGrass está basado en uDig, que es una plataforma en la que ahora SEXTANTE corre y sobre la que se está haciendo bastante trabajo. Andrea Antonello parece interesado, aunque es cierto que durante el congreso no hablamos mucho del tema a pesar de pasar bastante tiempo juntos (hay que hablar de otras cosas, no solo de SIG vive el hombre...)
Todo esto enlaza además con la decisión que la gente de gvSIG tomó en una reunión que tuvimos hace algunas semanas, y según la cual a partir de ahora tratarán de implementar todos los algoritmos de análisis de gvSIG sobre la base de SEXTANTE, incluyendo los ya existentes (geoprocesos, etc.)

Code sprint: la mayoría de los presentes hicimos un intenso "beer sprint" la noche anterior(había que despedirse del congreso y de los otros participantes que ya se iban...), así que la resaca no nos permitió ser muy productivos, pero aun así creo que saqué un par de cosas en claro. Ayude a solucionar algunos problemas en uDig, y el funcionamiento es cada vez mejor, acercándonos poco a poco a algo suficientemente estable como para publicarse. Ademas, hice un poco de wiki sprint y añadí mas información al wiki del programa, en la parte de desarrolladores y en otras secciones, que retoqué o amplié.

Nuevas ideas para mejoras: Entre lo que he visto y las vueltas que le he dado a la cabeza en los pocos ratos libres, me he traído algunas ideas nuevas para seguir mejorando SEXTANTE de forma progresiva. Hablar con alguna gente a la vuelta también me ha dado nuevas perspectivas sobre hacia donde llevar SEXTANTE. Éstas son algunas de ellas en orden prioritario de inteŕes, las cuales definen más o menos mis lineas de trabajo durante los próximos meses:
  • Rellenar huecos básicos: SEXTANTE tiene cosas muy raras y poco comunes, pero le faltan otras muy básicas. Herramientas de análisis vectorial como la intersección o la unión no están aún, en general por pereza mía al ver que gvSIG ya las trae. Pero ahora ya gvSIG no va a estar siempre detrás, así que es prioritario implementar estos algoritmos, ya que el gran público los usa a diario. Entre ayer y hoy ya he añadido la diferencia, la diferencia simétrica, la unión y la intersección. La operación "disolver" tengo que pensarla un poco más, porque los parámetros de configuración son algo diferentes, y quizás sea bueno hacerles una interfaz especifica.
  • Permitir el uso de interfaces de usuario específicas en el modelizador. Por ejemplo, para que pueda utilizarse la calculadora de mapas con sus botones y todo dentro del modelizador.
  • Mejorar la gramática del modelizador. Añadir mas elementos a las descripciones de las salidas, como el numero de bandas que van a tener (cuando pueda saberse de antemano, claro está), el tipo de capa vectorial, etc. Esto hará el modelizador más robusto.

No hay comentarios: