Programación SIG

Google Maps + ASP.NET en Firefox

2008-06-23T16:39:00.003+02:00

Estoy utilizando Google Maps y ASP.NET en un proyecto. Aunque existen controles ASP.NET que encapsulan la funcionalidad de Google Maps, no quiero utilizarlos porque luego necesito integrar funcionalidad de ArcGIS Server encima del mapa de Google Maps (con la nueva API de Javascript, version 9.3). Por lo tanto estoy utilizando el API de Google Maps por defecto.

Ademas, estoy utilizando controles AJAX del AJAX Control Toolkit, y he descubierto que en Firefox no conviene poner un control de Google Maps dentro de un TabContainer, porque el comportamiento de algo tan sencillo como hacer un "Pan" se vuelve aleatorio y poco controlable. La solucion ha sido sacarlo del TabContainer, y todo ha funcionado correctamente. Curiosamente este problema no existe en IE 7.

La verdad es que mi aplicacion no tiene como requisito ser multinavegador, pero en estos casos creo que conviene cubrirse las espaldas, porque estara expuesta a varios usuarios, y a saber los navegadores que utilizan.

Nuevo sistema operativo - Ubuntu 8.0.4 Hardy Heron

2008-04-26T01:29:00.004+02:00

No directamente relacionado con desarrollo de sistemas SIG, ¿o si?. Me acabo de instalar la última versión de la distribución Ubuntu 8.04, con nombre en clave ¨Hardy Heron" (realmente me encantaría conocer a la persona que se inventa estos nombres, son geniales). Hasta ahora las impresiones son muy positivas. En la imagen que pongo ahí arriba se puede ver un pantallazo de mi sistema, recién instalado.

Este es mi ordenador principal en casa, lo utilizaré para uso personal y si hay algún proyecto de desarrollo GIS con tecnologías open source (tengo uno en el tintero, aunque hay otras cosas antes), también verá uso en ese campo. En ese caso es posible que actualice la máquina, y justifique doblar la RAM (actualmente tengo 2 Gb, para el uso que le doy me sobra). Me sigo resistiendo a instalar Vista o XP, además ya tengo este último en el portátil del trabajo.

La verdad es que esta versión va como un tiro, llevo sólo unas horas con ella y estoy encantado, es más rápida que la anterior y esa no iba nada mal. Se nota que han pulido pequeñas cosas, no hay avances espectaculares pero está más refinada, y tiene algunos detalles que se agradecen (la configuración de redes, por ejemplo, o el Policy Kit para restringir la ejecución de partes de un programa).

Instalarla ha sido, como nos tiene acostumbrados esta distribución, hacer 5 o 6 clicks en un asistente, y ya está. Muchísimo más fácil que Windows XP, bajo mi punto de vista. Viene con Firefox 3 Beta 5 de serie, se me ha colgado una vez hoy, así que todavía no es la versión más estable de este navegador, pero es de esperar que a medida que salgan las actualizaciones se vayan instalando. En este sentido, me ha sorprendido lo rápido que es Firefox 3, esto lo digo basándome en una sensación subjetiva, no he medido tiempos ni nada, pero se siente sensiblemente más rápido que la versión anterior.

Ya me he instalado un entorno de desarrollo Java completo, con Eclipse y Netbeans (el cual, no sé muy bien por qué, cada vez uso menos, pero que sigo instalando por si acaso), y sin ningún problema. Normalmente uso este entorno para estudiar, hacer pequeños proyectos personales y si sale algún proyecto con tecnología open source, pues también.

Esta versión de Ubuntu es LTS (Long Term Support) lo que significa que tendrá soporte durante 3 años para escritorio y 5 para servidores. Aunque en mi caso, en octubre me actualizaré a la siguiente, sin duda. En definitiva, una distro muy recomendable si quieres algo diferente a Windows o Mac, y te atrae la libertad que te proporciona un sistema de estas características (en el más amplio sentido del término).

GIS en USA

2008-03-09T18:25:00.002+01:00

Como publico en mi otro blog, he empezado a colaborar en una empresa americana de temas GIS. Recién aterrizado en este país (llevo menos de dos meses en Washington), se abre la posibilidad de participar en proyectos GIS de envergadura, en una empresa joven, pero con una trayectoria importante en la zona. Espero contribuir a su crecimiento, y aprender todo lo que pueda por el camino.

Así que ya me he empezado a hacer una idea de cómo se mueven las cosas del GIS aquí en USA. Sólo algunos comentarios, en los que lógicamente iré profundizando a medida que vaya adquiriendo más experiencia.

1. Este país nos lleva, a España, unos 20 años de adelanto. No vale con importar la tecnología, que es la misma prácticamente. Los procesos, el nivel de calidad de los datos, la innovación que generan (y el valor que le dan a la misma), la investigación y desarrollo tecnológico son lo que están mucho más avanzados. El GIS no es algo raro y exótico y sale hasta en los episodios de CSI.

2. ESRI domina el mercado de forma apabullante. Es algo que ya sabía, pero lo he comprobado empíricamente. Aún así, asoman alternativas basadas en open source (las menos) o en otras tecnologías, estando muy presentes las propuestas de Google Maps o Virtual Earth como alternativas para muchas soluciones y aplicaciones, incluso empresariales.

3. La plataforma de desarrollo empresarial GIS dominante, para mi desesperación, es .NET. Java es claramente secundaria en este sector, al contrario de lo que pasa en el resto del mundo informático.
No tengo claro cómo evolucionará esto en el futuro, habrá que estar atentos. Se ven bastantes ofertas de trabajo para entornos GIS con JEE, eso si. Quizás son puestos en los que el GIS es una parte de un todo (bases de datos, otros sistemas....), lo cual es cada vez más habitual. En cualquier caso hoy en día estar limitado sólo a un lenguaje o una plataforma es cada vez más raro.

4. No obstante lo anterior, parece que en el 2008 se consolidará Javascript como lenguaje de desarrollo de aplicaciones SIG en web. Viendo este panorama, lo de .NET parece casi una bendición, en fin. Sigo pensando que para aplicaciones grandes, corporativas, que tendrá que mantener alguien dentro de tres años, no es la opción ideal. Pero hay tanto "hype" con los lenguajes dinámicos...

Bueno, ya iré poniendo alguna cosilla más según vayan ocurriendo, me sigo dedicando a esto y este blog no ha muerto (¿alguien lo dudaba?).

ESRI Federal User Conference

2008-02-26T19:39:00.002+01:00

Los días 20, 21 y 22 de Febrero se ha celabrado la "ESRI Federal User Conference" en Washington, D.C. Esta conferencia tiene como misión atender los aspectos que interesan al gobierno federal de Estados Unidos, muchos de los cuales son extrapolables a otros gobiernos. Yo acudía con la intención de hacer "networking" y ver alguna de las novedades de las nuevas versiones de los productos de ESRI, sobre todo en el lado del servidor que es el que más me interesa.

Aún siendo una conferencia sectorial con un contenido y público muy concreto, me sorprendió el número de asistentes. Es unas dos o tres veces más grande que una Conferencia de Usuarios de ESRI en España, en la sesión inaugural había muchísima gente (no llega a ser lo de San Diego, desde luego, pero yo vi muchas filas de sillas y todas llenas).

La sesión inaugural estuvo bastante bien, con demos y ejemplos bastante trabajados, algunos de ellos dando respuesta a flujos de trabajo realmente complejos. Siempre me ha llamado la atención lo "fácil" que parecen estas cosas que se cuentan en tres minutos, pero habiéndome dedicado a ello durante una etapa de mi vida profesional, aprecio la cantidad de trabajo que hay detrás.

En el escenario había 10 portátiles, cada orador iba al suyo según iban saliendo.
Todo un despliegue de medios, del que lamentablemente no tengo fotos decentes para subir aquí (la única que tengo la hice con el iPhone y la cámara que lleva no es precisamente su fuerte).

Además de la inaugural, me gustó mucho la exposición de partners y empresas, había un poco de todo, desde empresas locales (que me venían al pelo en mi búsqueda de contactos en el mercado local) y grandes de la industria como IBM, Google o Microsoft.

En cuanto a las novedades tecnológicas, y centrándome en
la versión 9.3 de ArcGIS Server, lo más reseñable es la nueva API Javascript, que permitirá, mediante llamadas a servicios web con interfaz REST, integrar servicios de ArcGIS Server con servicios de mapas de cartografía base como Google Maps o Virtual Earth. La integración con este último es bastante espectacular, eso sí, sólo se saca toda la potencia de visualización con Internet Explorer (esta limitación es de Microsoft), con una vista "3D" bastante espectacular.
Todo esto, con poquísimas líneas de código, es un verdadero "scripting para el servidor".Para montar estas aplicaciones casi no hay que saber programar, lo que es un avance (o no, según se mire).

No es algo que no se esté haciendo ya, existen otros proyectos (algunos open source) que implementan visores de estas características, lo que me llama la atención es la posibilidad de integrar toda la potencia de análisis de ArcGIS Server con cualquier servicio de mapas ya existente, y mostrar los resultados, todo ello de forma bastante sencilla y rápida. Para hacer prototipos o comunicar ideas, o simplemente sacar un resultado que tiene que salir a la luz de forma casi inmediata es una muy buena opción. Sin haberle hincado el diente (es decir, tirado código) todavía a esta versión, no puedo asegurarlo, pero además me daba la sensación de que estos visores Javascript son mucho más ligeros que los construidos con el ADF.

Evidentemente, se pierde funcionalidad, pero es una opción más muy interesante para mostrar resultados rápidos, y si no me equivoco me pareció entender que no hace falta licencia para ejecutarlos en el servidor web, al contrario de lo que pasa con el ADF.

Esta API fue lo que más me llamó la atención, evidentemente hay más novedades pero no me ha dado la sensación de que haya tanto cambio como el que supuso la 9.2, lo cual será agradecido por los usuarios (¡y por los programadores!). Eso sí, en el ADF de .NET hay nuevos controles y nuevo framework de AJAX en la 9.3 (ahora ESRI usa la tecnología Atlas de Microsoft, que no estaba disponible cuando salió la 9.2), lo que significa que habrá que adaptar las aplicaciones que ya tengamos desarrolladas. Ignoro si pasa algo parecido en el ADF de Java, pues en las charlas en las que estuve no se mencionó nada, pero es posible que pase algo parecido. En cualquier caso los controles de la 9.2 también están soportados.

Dejando un poco más a un lado la tecnología, me gustaron algunas de las charlas de alguna de las agencias norteamericanas, especialmente en temas relativos a uso del suelo o medioambientales, y cómo la tecnología está ayudando a gestionar volúmenes de datos increíbles, sólo hay que pensar en el tamaño que tiene este país. Evidentemente, la administración pública estadounidense están avanzadísima en temas SIG (con mucha ventaja sobre España, desde luego), aunque curiosamente algunos de los retos y problemas planteados me resultaron muy familiares.

Ah, en el precio estaba incluida la comida, superlativa el primer día y bastante peor el segundo, típica comida rápida americana para no perder el tiempo. Hubo "encuentro social" el jueves por la tarde/noche pero no acudí porque tenía otros planes, aunque de haber ido los comentarios pertinentes tendrían mejor cabida en mi otro blog

Que callado he estado

2008-01-09T19:19:00.000+01:00

Si, este blog ha estado suspendido por demasiado tiempo, espero remediar esto en breve. No es que no haya tenido temas sobre los que escribir, de hecho he tenido varios en los últimos meses. El "problema" es que hay un gran cambio en mi vida, y es que me voy a vivir a los Estados Unidos, con todo lo que ello supone.

Así que por razones obvias dejo mi actividad profesional aquí en España, la cual me ha tenido además muy ocupado los últimos meses, pero espero retomar en breve el pulso de publicar algunas cosillas.

Quizás pueda publicar en breve la perspectiva de los SIG desde el otro lado del charco, en castellano, y aportar esa visión, o quizás me canse de este blog y empiece otro en inglés, no lo sé. Pero seguiré publicando y lo que pase lo anunciaré aquí, así que "stay tuned".

¿Funciona el soporte de la comunidad?

2007-04-21T12:04:00.000+02:00

Bueno, pues según mi experiencia si, y muy bien además. Ayer estuve probando la última versión de uDIG, con la que estamos empezando a trabajar para incoroporarlo como cliente de escritorio en algunos proyectos. Quise conectarme a un repositorio de ArcSDE, pero no funcionaba. Así que puse un mensaje a la lista de desarrolladores. ¿Cómo acabó todo?. Pues que efectivamente se descubrió un "bug" en el proceso de generación del plugin necesario, que se identificó y que se corregirá en la siguiente versión disponible. Pero además, el desarrollador encargado de esta tarea envió a toda la lista de correo el plugin corregido, que efectivamente funciona sin ningún problema. Hasta aquí, todo bastante normal, pero lo que no he dicho es CUANTO TIEMPO transcurrió en todo el proceso. En España eran las 7 de la tarde más o menos, con lo que en Norteamérica ya están levantados y al tajo. Vamos, resumiendo, que tenía en mi poder la solución en CINCUENTA MINUTOS.

Con Geoserver he tenido experiencias similares, incluso me han llegado a enviar un WAR a mi correo que solucionaba algún problemilla que tuve, y que me compilaron especialmente a mi (y que suelen hacer a todo aquel que lo necesite, siempre que esté justificado claro).

Y ahora una reflexión. Evidentemente, este tipo de soporte no es posible encontrarlo en casi ningún fabricante de software SIG en la actualidad. Aunque parezca una afirmación un poco fuerte, la reflexión viene más bien por otro lado. Creo que todo el mundo ve las ventajas que tiene un proceso abierto, en el que se tiene acceso directo a los creadores de la herramienta, a las mejoras en las que están trabajando en este preciso instante, y a la corrección de errores que pueden estar afectando nuestro trabajo diario.

Evidentemente, la respuesta de los fabricantes puede seguir siendo crear call centers con becarios poco formados (nada contra ellos, muchos han empezado así) y poco preparados para dar respuestas de calidad, con unos sueldos ínfimos que les invitan a volar en cuanto se han formado y tienen una oportunidad mejor, lo que obliga a reconstruir y volver a formar al equipo de trabajo. Pero está demostrado que el usuario exigente de hoy en día (cada vez hay más) no acepta esto. La prueba está en que la mayoría de las veces funciona mejor lo que uno encuentra en los foros. Aquí, también es la comunidad de usuarios la que aporta y soluciona problemas.

Esto, que puede parecer un ahorro de costes estupendo, puede ser una trampa en mi opinión. En un modelo de negocio que evoluciona hacia los servicios más que a la venta de licencias (y esto no hay quien lo pare ya), más vale que el soporte sea bueno. Siempre podemos pensar si es mejor atender volumen con poca calidad o atender adecuadamente cada nicho de mercado, el equilibrio evidentemente es difícil, pero cuando el software falla el estropicio se nota mucho, esto en Sistemas de Información Geográfica dedicados a la gestión o publicación de información es especialmente relevante y visible.

Además, hay que tener en cuenta otra cosa. Hay toda una generación que se está incorporando ahora al mercado de trabajo, y que tiene como característica principal el dominio de este entorno colaborativo y participativo, lo han incorporado como forma natural de interacción en todos los ámbitos, y no van a entender las viejas formas de interacción con un departamento de soporte técnico ("estimado cliente, se ha recibido su incidencia blah, blah,blah....."). Cuando esta generación lleve la batuta de los negocios, muchas cosas cambiarán, de hecho ya lo están haciendo, o al menos deberían estar cambiando si el software en cuestión y los servicios asociados pretenden mantener su cuota de competitividad.

Y esto es válido para software gratuito, de pago, con código abierto o cerrado.

Bueno al menos es así como yo lo veo.

ArcGIS Server code challenge

2007-04-03T09:02:00.000+02:00

Ya se han fallado los premios para el ArcGIS Server Code Challenge, que ha tenido lugar en la Conferencia de Desarrolladores de ESRI (ESRI Developer Summit).

Se pueden ver los scripts / programas que han sido enviados, así como los ganadores, en la siguiente URL:

http://esricodechallenge.wordpress.com/

Viendo lo que ha enviado la gente, me asalta una duda.

¿Nadie desarrolla en Java por allí?. Sabía que .NET era mayoritario, pero no me imaginaba que no iba a encontrar ninguna entrada desarrollada en la plataforma de desarrollo empresarial más extendida.

Desde luego, desarrollar con ArcGIS Server en Java es una aventura no apta para cobardes. Por fin está empezando a aparecer documentación en la web, después de llevar el producto varios meses en el mercado. Y ahora resulta que se hace todo con AJAX, como no podía ser de otra forma, está bastante bien a nivel técnico, la verdad.

Aún así, faltan por pulir muchos aspectos, hay zonas de la API que no están documentadas, por ejemplo el tema del manejo de Geodatos, imposible encontrar un ejemplito en Java (si en .NET), y hasta que han empezado a aparecer los ejemplos en la web (http://edn.esri.com/index.cfm?fa=java.gateway), es difícil imaginarse que alguien "adivine" todo el tinglado de los PhaseListener de JSF y su integración con AJAX así como por arte de magia. Escribiré otro post sobre este tipo de desarrollos más adelante, pues tienen su miga.

En el caso de ArcGIS Server, y en igualdad de circunstancias, es mejor optar por .NET pues es un producto mucho más acabado y completo a todos los niveles, y se nota que ESRI va de la mano de Microsoft.

Sin entran a valorar esto, pues daría para un largo y encendido post, lo que tengo claro es que cada día me gusta menos la arquitectura de bajo nivel de este producto precisamente por este motivo, demasiado objeto COM por ahí debajo haciendo la puñeta. Llamar a estos señores desde Java se hace a través de una librería intermedia que actúa como pasarela o "bridge", y aunque ha mejorado mucho en la versión 9.2, nos sigue obsequiando con unas magníficas excepciones nativas (AutomationException) que me recuerdan a los mejores tiempos del "Segmentation Violation" de ArcView 3.x.

La recomendación que he escuchado alguna vez, "pues hazlo en .NET", desgraciadamente no me sirve. En España y gran parte de Europa se utiliza la plataforma JEE de forma exclusiva, y por unos buenos motivos, en mi opinión. Que te cambias a .NET y descubres que funciona fenomenal, pero que te tienes que apoyar en un servidor Windows con IIS, si o si.

Bufff.

SIG corporativo open source

2007-03-01T22:58:00.000+01:00

A menudo se contempla el fenómeno del software libre en el ámbito de los SIG de forma individual, programas de escritorio por un lado, bases de datos espaciales libres, servidores de mapas por otro, etc.

Pero la gran pregunta es, ¿qué tal un SIG completo, corporativo, basado en software libre?. ¿Es posible?. ¿Se puede desplegar un sistema completo, que cubra las necesidades de un sistema corporativo?. La pregunta no es nueva, pero quizás sea interesante hacer un barrido al "estado del arte", y elegir herramientas, porque no sólo es posible sino que además hay bastantes opciones donde elegir entre diferentes tecnologías.

También habría que definir qué es exactamente un SIG corporativo, por simplificar imaginemos un sistema integral, en el que existen todo tipo de usuarios, expertos en SIG o usuarios ocasionales. Esto da lugar a múltiples flujos de trabajo de lo más variado, por lo que en general es necesario una "suite" de productos que cubran todos los aspectos. Dividiéndolos por entornos, esta es mi elección de software actualmente para realizar integraciones o desarrollos open source en SIG. No significa que no existan otras alternativas tan válidas o incluso mejores, sólo las que a mi personalmente me convencen más.

Bases de datos espaciales

Aquí no hay muchas opciones, pues hay un proyecto que es la referencia en este ámbito, se trata de Postgis, extensión de PostgreSQL para datos espaciales. Lo bueno es que al haberse estandarizado su uso en diferentes proyectos open source de GIS, prácticamente todos tienen capacidad de acceder a los datos almacenados de esta forma. Además de ser un repositorio, proporciona un completo lenguaje SQL con extensiones espaciales, muy potente para gestión de datos y análisis de la información. Como pega no tiene la capacidad de almacenar datos raster, de momento. Ah, y el notición es que ArcGIS 9.3 soportará PostgreSQL como base de datos para la geodatabase y Postgis como implementación del modelo geométrico. Ya veremos si no hay truco, si no lo hay puede dar un empujón mayor a esta base de datos libre.

Servidores de mapas

Aquí hay varias opciones, mi elección es Geoserver, basado en la librería Geotools, por su arquitectura modular, clara vocación en el cumplimiento de estándares OGC (es implementación de referencia de la especificación WFS). La característica que desmarca a este software del resto es la capacidad de gestionar transacciones SIG remotas a través de http, y hacerlo bastante bien por cierto. Además, está construido en Java, con lo que se integra perfectamente con el resto de la arquitectura que estoy repasando brevemente.

Admite arquitecturas en cluster, y se puede extender en la última versión mediante un mecanismo de plugins desarrollados sobre el framework de aplicaciones web Spring. Y además tiene la posibilidad de generar teselas y utilizar AJAX para peticiones asíncronas con una experiencia de usuario estilo Google Maps. Y por supuesto soporta diversas fuentes de datos, entre las que destacan Postgis, shapefiles, Oracle Spatial, ArcSDE, etc.

Infraestructura de Metadatos

No me parece la parte más interesante de un proyecto corporativo, pero en algunos casos puede ser vital tener este módulo para la gestión de metadatos. En este caso elegiría Geonetwork, que también es de las pocas opciones completas para gestionar todos los aspectos de una IDE. No obstante, aquí es donde hay muchas opciones para desarrollar y generar aplicaciones personalizadas en base a los protocolos del OGC (algunos han de desarrollarse más y extenderse su uso).

SIG Desktop o de escritorio

Es quizás donde más se ha avanzado recientemente, y donde queda también más por hacer. Proyectos como gvSIG o UDIG ponen encima de la mesa una propuesta de software que empieza a tener funcionalidad suficiente como para plantearse su uso en trabajos de edición y mantenimiento de datos, así como de análisis. Siguen todavía a años luz del software comercial en muchos aspectos, pero están construidos sobre arquitecturas abiertas y estándar y utilizan formatos abiertos.

Mi elección en este punto es UDIG, por los siguientes motivos:

- Interfaz de usuario más "profesional", aunque esto no es demasiado relevante.
- Basado en el framework de construcción de aplicaciones ricas de Eclipse (RCP o Rich Client Framework), seguramente el framework de construcción de aplicaciones de escritorio más extendido en Java.
- Basado en Geotools, excelente librería de tratamiento de datos espaciales
- Estabilidad y cumplimiento de estándares. UDIG edita bases de datos espaciales remotas a través de WFS-T, un puntazo.

Para operaciones muy complejas de análisis, utilizaría GRASS (dentro de poco, JGRASS se integrará en UDIG).

Con todo esto, y siendo esto un blog de programación SIG, TODOS estos programas dan la posibilidad de descargarse el código fuente, estudiarlo, y aportar cosas. Además lo habitual es retocar o adaptar soluciones basadas en este tipo de tecnologías para responder a necesidades de gestión de información geográfica en todos los ámbitos de un completo Sistema de Información Geográfica Corporativo Libre. Me suena raro este nombre, pero al tiempo, que se hará cada vez más común a medida que los proyectos vayan convergiendo.

Un año de programación GIS - repaso 2006

2006-12-31T13:08:00.000+01:00

Bueno, ahí va el tradicional repaso al año 2006, que ha sido muy movidito en el sector de la información espacial y el desarrollo de aplicaciones SIG, aunque quizás no tanto como el año 2005. Aún así, parece que se consolida con fuerza el despegue del sector dentro de las TI, gracias al interés de muchos de los "grandes".

Ahí va un resumen de lo que a mi juicio han sido los hechos más importantes. Viendo las "predicciones" del año pasado, da un poco de risa pero ahí está la gracia de jugar a las adivinanzas.

1. Interés por la información geográfica creciente en todo el mundo. Crece el número de usuarios de forma vertiginosa, y también el número de desarrolladores. Gracias a Google, Yahoo o Microsoft cualquier desarrollador que no se haya metido en una cueva este último año sabe de qué va eso de "los mapas".

2. Crecimiento espectacular del número de usuarios de software libre. Generalmente ocupando nichos de los cuales los grandes proveedores de software o bien se han retirado o bien no prestan suficiente atención. En cuanto a las herramientas en general, se ven avances importantes en la mayoría, al menos los proyectos más modernos y con más tirón. A estas alturas cubren desde el punto de vista tecnológico muchas necesidades, no llegan a todos los sitios ni son la panacea pues hay muchísimos aspectos a considerar a la hora de elegir una herramienta, sobre todo en entornos corporativos, y el que sea open source puede ser un plus pero nunca debería ser el argumento único y excluyente.

3. La apuesta radical del año pasado de que el SIG de escritorio desaparecería no ha tenido lugar. Por algo era radical. De hecho, hay un visitante que aunque no nuevo, si ha tenido un despegue espectacular en el 2006: gvSIG. No sé exactamente cuánto se usa pero se habla mucho de este software. Un SIG de escritorio con una funcionalidad próxima a la del ArcView 3.x de toda la vida, pero basado en plataforma Java y con licencia GPL. Con gran apoyo financiero y bastantes usuarios, desde luego rellena un hueco, y abre nuevas oportunidades de negocio también. Sin embargo, no me parece la tendencia tecnológica del futuro, viendo el interés que hay en todo el mundo por las aplicaciones web. Los SIG llegarán (están llegando) a esa "moda" también. Sigo pensando que la chicha está en el servidor.

4. Relacionado con lo anterior, se respira un ambiente en muchas administraciones y usuarios.......diferente. No se sienten prisioneras de nadie, de ningún fabricante ni de ninguna consultora. Muchos han madurado a base de equivocaciones, ensayos y años de experiencia. Algunas se lían la manta a la cabeza y sacan fondos para construirse su propio SIG. Evidentemente las generalizaciones son malas, y no está claro que todas acierten o que todas se equivoquen, habrá un poco de todo. Pero si es una tendencia relativamente nueva, y los casos de éxito que se van teniendo animan a otros a subirse al carro, porque si sale bien se obtienen muchos beneficios desde el punto de vista del promotor (políticos, económicos, tributarios, etc.). Vamos a ver muchas más iniciativas de estas en el 2007, que darán la espalda a los fabricantes de toda la vida, y es que es cada vez más difícil vender licencias de software sin un valor añadido. Esto es algo que viene ocurriendo en el mercado del software empresarial desde hace unos años, en el SIG hemos llegado un poquito más tarde. La competencia es buena.

5. No obstante lo anterior, y debido al crecimiento del sector, las compañías fabricantes de software y sobre todo las consultoras han disfrutado de un año de crecimiento importante, y es previsible que el 2007 también sea un buen año. Como antídoto ante la saturación del mercado y las vacas flacas que vendrán antes o después, se hace necesario diversificar y tener una oferta especializada y de alto valor añadido.

6. El año que viene espero que si sea el año de las SOA (Service Oriented Architecture, arquitecturas orientadas a servicios), aunque la verdad, veo el panorama un poco verde todavía, en España y en el mundillo de los SIG en general. Es un cambio muy grande de planteamiento y de concepto, que es lo más grave, pues la parte técnica al final no hay más que ponerse con ella (que no es poco). En cualquier caso, ya existen proyectos de SIG que desarrollan sistemas basados en esta estructura o al menos introduciendo esta filosofía, y sentarán las bases de los sistemas corporativos del futuro. Conceptos como el de los servicios web no son nuevos, pero no todo el mundo entiende lo mismo, para mi un WMS no es un servicio web en sentido estricto, y desde luego está muy alejado del planteamiento de una SOA en una gran organización. Existe un nicho por llenar en este aspecto, que dará muchas oportunidades de negocio si los SIG siguen creciendo al ritmo actual y se demanda cada vez más el acceso a información y procesos geoespaciales.
La clave de la importancia de los SIG en este ámbito va a ser la capacidad que tengan de integrarse con otras tecnologías para complementar los procesos de negocio de una gran organización.

Problemas para ESRI con el ADF de ArcGIS Server

2006-12-10T00:31:00.000+01:00

Ha surgido en internet una corriente bastante "cañera" en contra de ciertos aspectos de la nueva licencia de ArcGIS Server 9.2, los cuales se pueden reflejar por ejemplo en este blog

Resumiendo: se paga por todos los componentes desplegados de ArcGIS Server. Es decir, por SOC / SOM, tecnología ArcSDE (ArcSDE ha desaparecido como producto), y el ADF, a razón de una licencia por socket con hasta dos CPU.

O sea, un sistema hasta ahora "lógico", con un servidor de ArcSDE + RDBMS, ArcGIS Server y un servidor web con el ADF (3 máquinas) consume un mínimo de tres licencias, donde antes eran dos (el ADF no se cobraba). Lo más gracioso es que se recomienda la "conexión directa" a partir de la 9.2.

¿Confundido?.

Si, yo también, tantos años convenciendo a todo el mundo de que SDE era necesario como componente intermedio y resulta que no, que ahora es mejor incluirlo en otra capa "cliente" (aunque esta capa sea otro servidor). Voy a desear mucho ver comparativas de rendimiento entre ambas opciones....(con hardware idéntico, claro). Espero que no sea una estrategia de marketing para dejar de cobrar en un sitio para hacerlo en otro.

¿Mi opinión?. Pues que efectivamente y como se comenta en el enlace anterior, ESRI ha construido el ADF más caro de la historia, no tiene justificación cobrar una licencia adicional por este componente (no se cobraba en la 9.1). No sé en qué estarían pensando, la verdad.

Técnicamente ArcGIS Server (AGS) es un paso adelante en la programación de aplicaciones SIG en web, pero si se confirma este modelo de licencia (y por los comentarios de nuestros amigos del otro lado del atlántico, parece que será así), no veo mucho mercado para este software. O al menos no todo el que podría tener. Y la verdad es que yo lo voy a usar en al menos un proyecto de envergadura, pero visto lo visto no sé si habrá más.

Es demasiado caro.

¿Lo peor?. Que ArcIMS 9.2 comparte ADF con ArcGIS Server. Lo que técnicamente es una ventaja, ahora se puede convertir en un gran inconveniente, puesto que para servir mapas pago dos licencias, una por los componentes SIG y otra por los componentes del ADF que instalo en el servidor web.

Ridículo.

El argumento de "lo instalo todo en una máquina" no se sostiene por muchos motivos (seguridad, escalabilidad, rendimiento, etc.) que no es ni siquiera necesario explicar.

Yo predigo que muchos usuarios optarán por soluciones open source para la publicación de información, tan sólo por este motivo. Echando un vistazo a Mapguide Open Source se adivina por qué. Una interfaz AJAX moderna parecida a la que ofrece el ADF, y GRATIS. No lo he probado todavía, pero lo haré.

Creo que se han equivocado con este modelo de licencia, como proveedor de servicios me veo muy limitado por la licencia de un software que es vital en mi actividad pero que no es el único, y que se va a "tragar" gran parte del presupuesto de mis licitaciones. Es decir, que en bastantes ocasiones me veo obligado a buscar alternativas para poder ofrecer a mis usuarios lo que me piden. Porque está claro que el nuevo ADF es la caña, pero hay alternativas para las cosas más sencillas, y para las más complejas igual sale a cuenta desarrollarse algo a medida.

Sinceramente, de confirmarse este modelo de licencia, ESRI lo habrá hecho muy mal en su unificación de productos de servidor. Al menos, en mi humilde conocimiento de las necesidades del mercado español. Seguirán los clientes de siempre, las grandes administraciones. Pero veo complicado que se suban al carro nuevos clientes, sobre todo los que están acostumbrados a lidiar con grandes proveedores de software.

También puedo estar totalmente equivocado y no acertar en nada, y ArcGIS Server 9.2 puede ser un bombazo. Yo estaría encantado por la inversión de tiempo y conocimiento que he hecho en esta tecnología en el último año, me daría de comer mucho mejor.

Cambio de trabajo

2006-11-02T10:45:00.000+01:00

Pues si, después de dos años en ESRI España, he aceptado cambiar de aires y volver a realizar proyectos de SIG, algo que empezaba a echar de menos. Así que desde el día 30 de Octubre formo parte de ACT Sistemas del Grupo Ayesa, como Responsable del área GIS de la compañía. Esto me va a permitir estar más en contacto diario con el uso real de la tecnología, el impacto para este blog creo que será positivo, espero escribir más a menudo. Atrás dejo sobre todo muchos amigos, y una experiencia muy interesante desde el punto de vista profesional.

Conferencia de Usuarios ESRI 2006

2006-10-09T15:56:00.000+02:00

Bueno, con la resaca de esta Conferencia, la verdad es que las sensaciones son muy positivas. Mucha gente, mucho trabajo, y muchos proyectos interesantes para el futuro.

Para mi ha sido una buena Conferencia de Usuarios, he tenido la ocasión de hablar con mucha gente y ha sido muy positivo.

Realmente tengo la sensación de que, en la mayoría de los casos, las novedades han resultado de interés para la mayor parte de los usuarios.

Para mi también lo han sido. Destacaría las siguientes, son mi "top ten" particular, que no suele coincidir plenamente con el de otros, pero que es mi particular visión de la tecnología, más centrada en los aspectos que para mi son técnicamente interesantes porque resuelven un problema.

1. ArcGIS Server es el núcleo de la tecnología ArcGIS, y lo será mucho más en el futuro. Van a salir muchos proyectos con ArcGIS Server en el año 2007, sin duda ayudados por las nuevas licencias, que facilitarán su acceso con versiones más "asequibles" (si se puede decir así). Esto abre numerosas posibilidades de cara al futuro de los SIG, y la verdad es que ESRI no tiene competencia en este campo. Echo de menos por ejemplo una implementación open source con un concepto siquiera similar, aunque en funcionalidad se quede atrás. Los servidores OGC no me sirven, porque estas especificaciones son muy útiles, pero muy pobres funcionalmente hablando. Soy pesadísimo y me harto de escucharme a mi mismo, pero la clave son, efectivamente, los servicios web y las Arquitecturas Orientadas a Servicios (SOA).

2. Interoperabilidad. Realmente en ArcGIS 9.2 hay multitud de pequeños detalles, desde las extensiones de interoperabilidad hasta el soporte a estándares OGC, que hacen de esta plataforma mucho más abierta que nunca.

3. SQL para Oracle. Esto se suele pasar por alto, quizás no es muy vistoso, pero para mi abre un camino enorme en cuanto a la integración con otros sistemas. Si, ya existen otros sistemas parecidos, pero este sigue estándares ISO y aprovecha el mejor rendimiento de la geodatabase comparado con otros formatos.

4. ArcGIS Explorer. Bueno, me ha tocado sufrir a este bicho porque preparar lo que enseñamos en la Confe ha llevado muchísimo trabajo. ¿Es la respuesta de ESRI al efecto Google?. Bueno, en parte, aunque su ecosistema me parece algo distinto, no pretende exactamente que se acabe instalando en todos los PC del mundo. ¿O si?. Uno nunca sabe cómo acaban estos experimentos. Es una aplicación bonita y se podría haber quedado en eso, en ese caso jamás la hubiese considerado para un "top ten". Pero esa transparencia y facilidad con la que consume servicios web geográficos generados con ArcGIS Server............

5. Mejor soporte para Java. Como desarrollador, veo con satisfacción que ESRI apuesta por esta plataforma en su nueva línea de software. Si, ahora funcionan mejor y van más rápido, están mejor documentados y se está creando "comunidad". En España casi todo el mundo que desarrolla en el servidor con SIG lo hace con J2EE, así que la satisfacción me imagino que no sólo será mía.

6. Productividad. En ArcGIS Desktop hay miles de pequeñas chorraditas que hacen el trabajo más productivo. Algunas de estas cosas se desarrollaban antes, a alguno le va a dar rabia comprobar cómo su flamante dll no necesita ya tantos menús porque vienen por defecto. A mi me ha pasado con una de las extensiones que tenía, que ha quedado totalmente obsoleta, pero lo prefiero, habrá que inventarse herramientas más imaginativas y útiles.

7. Replicación distribuida en la geodatabase. Esto es difícil de enseñar en una demo, porque no resulta "vistoso", pero las consecuencias de este avance son enormes. Se da salida a flujos de trabajo que se estaban empezando a dar y que resultaban complicados con la tecnología anterior. Será posible mantener repositorios distribuidos de información geográfica, en distintos DBMS, con toda la inteligencia de la geodatabase de forma transparente. Tenemos replicaciones parciales, en un sentido, en ambos, por red, mediante protocolo http, a través de CD.......

8. ArcGIS Image Server. La verdad es que no he encontrado a mucha gente que asimile lo que significa el avance de Image Server. No, no es un servidor de imágenes más, de esos ya hay en el mercado y mejores que los de ESRI. Pero se abre una ventana de posibilidades en forma de servicios de procesamiento dinámico de imágenes ráster. Creo que las posibilidades de futuras versiones y su integración con el resto de la tecnología ArcGIS Server proporcionan una serie de posibilidades muy interesantes.

9. Representaciones cartográficas. Hace tiempo que dejé de hacer mapas. Gracias a dios, porque no me gusta demasiado, no me divierte. Para aquellos que produzcan cartografía y necesiten de acabados con calidad o simplemente contar con un entorno tremendamente flexible en cuanto a la simbolización de entidades, que además pueda ser almacenada en la geodatabase con el resto de elementos, existe la que para mi es la mayor y más impactante novedad de Desktop, las representaciones cartográficas.

10. Esto es un blog de desarrollo. También en cuestión de desarrollo hay muchas novedades.Integración de todos los productos con la última línea de Microsoft (Visual Studio .NET 2005), y con Eclipse para Java, con asistentes que serán muy bienvenidos por la comunidad de desarrolladores Java. Por cierto, mi visión es que con ArcGIS 9.2 (Engine, Server) ya podemos hablar de productividad con ArcObjects, los tiempos de desarrollo se acortarán, lo que permitirá hacer más en menos tiempo, sobre todo en Server.

En realidad, lo que me gustaría es que la gente que lee este blog (poquitos, pero alguno hay) comentase si estuvo en la Conferencia sus impresiones, pues las mías están tremendamente sesgadas por haber formado parte del "show".

No más ArcObjects por ahora

2006-09-12T22:30:00.000+02:00

Sé que debo terminar esa serie interminable sobre ArcObjects, por lo menos hay un par de personas que me lo han comentado y tienen razón. No es por poner excusas, pero prefiero esperar a que la versión 9.2 de ArcGIS esté en el mercado. Sin entrar en detalles, la considero lo suficientemente importante como para esperar a su lanzamiento, porque algunos planteamientos que tenía pensado contar sobre ArcGIS Engine y sobre todo sobre ArcGIS Server cambian bastante.

Enlazando con un post anterior sobre la gran cantidad de novedades, más de uno puede pensar "oh, no, esto vuelve a cambiar". Realmente pienso que en este caso para bien. A nadie que se haya enfrentado a ArcGIS Server se le escapa que es un sistema muy potente, pero que había que desarrollar mucho. Si, si, lo he dicho en pasado, porque a partir de ahora muchas cosas serán más sencillas y más potentes.

En el caso de ArcGIS Server, hay muchas novedades que sin duda es necesario conocer y estudiar, pero que una vez asimiladas hacen el trabajo más productivo por un lado, y con muchas más posibilidades de integración además. Este software quizás no ha sido entendido bien todavía por todo el mundo, porque mucha gente lo ha identificado con un "ArcMap en la web", cuando bajo mi punto de vista su filosofía es otra: ofrecer servicios de forma estándar, e integrarse con otros sistemas de información gracias al despliegue de SOA (Service Oriented Architecture o Arquitecturas Orientadas a Servicios). Es decir, integrar la inteligencia geográfica en las organizaciones, complementando la toma de decisiones y aportando el estudio de la variable espacial a los Sistemas de Información.

Ah, por el camino sigue ofreciendo muy vistosos visores de mapas y toda la funcionalidad de un SIG, en esta ocasión en la web. Cuando salga a la calle la 9.2, publicaré en este blog algunos truquillos relacionados con las novedades más interesantes.

Para aquellos que estén interesados en las primicias, en la Conferencia de Usuarios ESRI España 2006 hay dos charlas previstas monográficas de ArcGIS Server, se puede consultar la agenda en http://www.esri-es.com/esri2006/conferencia/agenda.htm. Los abstract de las dos charlas a las que me refiero se encuentran en las siguientes URL:

Despliegue de aplicaciones y servicios con ArcGIS Server
http://www.esri-es.com/esri2006/conferencia/agenda4/esri_2a2.htm

Desarrollo con ArcGIS Server
http://www.esri-es.com/esri2006/conferencia/agenda5/esri_5b2.htm

Para los que quieran ver algo más bonito y divertido, pero también de gran potencia, pueden probar con la charla de ArcGIS Explorer

http://www.esri-es.com/esri2006/conferencia/agenda5/esri_3b2.htm

Además de estas, hay otras charlas muy interesantes, por supuesto, el asistir a unas u otras ya depende de los intereses de cada uno.

Instalación Mapserver en Linux

2006-09-08T00:05:00.000+02:00

Rebuscando en el disco duro, he dado con este documento que generé hace un par de años. No contempla las últimas versiones, pero puede servir de guía para alguien.

INSTALACIÓN DE UN SERVIDOR DE MAPAS OPEN SOURCE BASADO EN MAPSERVER EN SISTEMAS LINUX

1. Requisitos previos
Para instalar Mapserver en Linux, necesitaremos compilar los fuentes del programa, así como las librerías necesarias para su funcionamiento. Por lo tanto, el sistema ha de tener instalado el compilador de C GNUCompiler (gcc), se recomienda una versión actual, y también el programa MAKE para generar el script de instalación. Estos programas son bastante estándar y vienen incluídos en todas las distribuciones actuales de Linux. Por otro lado, ya que vamos a servir mapas por internet, será necesario tener un servidor web, la opción lógica y más recomendable es Apache. Mapserver se compilará como un script CGI que Apache utilizará para procesar las peticiones de mapas.

2. librerías necesarias
Las librerías necesarias para que funcione Mapserver son GD (librería de gráficos) y poco más, puesto que el resto son opcionales. Sin embargo, la funcionalidad queda muy pobre si no instalamos al menos las de uso más común. Nosostros hemos instalado las siguientes:

- GD : instalada con el sistema operativo (opción recomendada), en nuestro caso SUSE 9.1 Professional
- PROJ4: librería que permitirá la reproyección de datos al vuelo, si los datos que se le solicitan a Mapserver no están en el mismo Sistema de Proyección. Evidentemente se produce una penalización en el rendimiento, pero es una opción interesante debido a su flexibilidad, sobre todo si pensamos en servicios OGC Web Map Service en "cascada".
- GDAL & OGR : permite manejar multitud de formatos tanto vectoriales como ráster, es una librería estándar de uso muy común.
- PostGIS: necesaria si queremos tener un servidor con este formato espacial. En teoría sólo es necesario tener instaladas las librerias cliente de PostgreSQL para poder acceder a un servidor de datos Postgis, pero hemos preferido instalar la base de datos en el mismo servidor que atiende las peticiones de mapas.
- CURL : librería de utilidades de transferencia de información a través de la web.

3. Instalación de librerías

GD.
En este caso, simplemente hemos instalado el paquete binario que venía con nuestra distribución. Esto puede variar de una distribución de Linux a otra, en SUSE es muy sencillo realizarla mediante el uso de YAST2.

PROJ4.
Esta librería la descargamos de internet (http://proj.maptools.org/) y la compilamos e instalamos a mano. Para ello ejecutamos los comandos estándar de instalación de programas en Linux

tar -zxvf proj-4.4.8.tar.gz
cd proj-4.4.8
./configure
make
make install (como root)

Para comprobar que hemos instalado correctamente la librería, escribimos en un terminal proj, deberíamos obtener una respuesta similar a la siguiente:

Rel. 4.4.8, 3 May 2004
usage: proj [ -beEfiIlormsStTvVwW [args] ] [ +opts[=arg] ] [ files ]

GDAL & OGR.
Descargaremos la librería GDAL de internet (http://gdal.org/dl/) y realizaremos una instalación estándar :

tar -zxvf gdal-1.2.3.tar.gz
cd gdal-1.2.3
./configure
make
make install (como root)

POSTGIS.

Esta es la instalación más larga y compleja, porque vamos a instalar un servidor de datos PostGIS completo. Para ello lo mejor es leer el manual de instalación de PostGIS, presentamos aquí un resumen del proceso de instalación, dividido en tres partes:

1)Instalación de librerías necesarias
PostGIS puede hacer uso de la librería PROJ4 para proyectar datos almacendados en la base de datos y de la librería GEOS para implementar funciones de SIG (Buffer, Union, etc.) según el estándar OGC Simple Features for SQL.
La librería PROJ4 ya la hemos instalado en un paso anterior. Procederemos a instalar la libreria GEOS (http://geos.refractions.net/) . Primero la descomprimimos, viene en formato bz2. Para esto, hemos utilizado el navegador de arcvhivos konqueror, instalado con nuestra distribución de linux. Posteriormente realizamos una instalación estándar:

./configure
make
make install (como root)

2) Instalación del servidor de base de datos PostgreSQL (http://www.postgresql.org/)
Aunque nuestra distribución de Linux incorpora esta base de datos, la tenemos que instalar desde código fuente porque es necesario tener el árbol de instalación para parchear posteriormente la base de datos con la extensión espacial PostGIS.

Para instalar la base de datos con soporte para GEOS, realizaremos un link explícito entre PostgreSQL y la librería estándar de C++, para evitar problemas. El procedimiento de instalación será el siguiente:

LDFLAGS=-lstdc++ ./configure --enable-debug
gmake check (opcional, realiza test de regresión de la instalación y del funcionamiento del servidor de base de datos)
gmake
gmake install (como root)

Además, tendremos que poner la siguiente variable de entorno en el fichero .bashrc (o equivalente):

LD_LIBRARY_PATH=/usr/local/pgsql/lib
export LD_LIBRARY_PATH

También podemos ejecutar el siguiente comando (como root):
/sbin/ldconfig /usr/local/pgsql/lib

Por último, hay que añadir la ruta de los ejecutables a la variable de entorno PATH. Esto último no es imprescindible para el funcionamiento del servidor de base de datos pero resulta más cómodo, para poder acceder desde cualquier directorio

PATH=/usr/local/pgsql/bin:$PATH
export PATH

Creamos una cuenta de usuario que maneje el servidor postgres (usualmente postgres)

mkdir /usr/local/pgsql/data (directorio donde se almacenarán los datos)

Como root:

mkdir /home/postgres
adduser postgres -d /home/postgres
chown postgres /usr/local/pgsql/data

Como postgres:

initdb -D /usr/local/pgsql/data
postmaster -i -D /usr/local/pgsql/data
createdb (creamos base de datos sig
psql (conectamos a la base de datos de prueba)

3) Instalación de la extensión espacial PostGIS.

Descargamos la librería postgis de internet (http://postgis.refractions.net/) y la descomprimimos:

tar -zxvf postgis-0.9.0.tar.gz

A continuación movemos el directorio postgis-0.9.0 al directorio contrib del árbol de código fuente de PostgreSQL. Una vez dentro de este directorio, ejecutamos como root:

make
make install

Como usuario postgres, desde el directorio de postgis:

psql -f postgis.sql -d
psql -f spatial_ref_sys.sql -d

CURL
Hemos instalado la librería que venía con nuestra distribución.

4. Instalación de mapserver (http://mapserver.gis.umn.edu/)
Una vez descargado de internet, lo descomprimimos:

tar -zxvf mapserver-4.2.4.tar.gz
cd mapserver-4.2.4

Existen varias opciones de configuración para la compilación de mapserver. Todas ellas vienen explicadas en el archivo README.CONFIGURE que se encuentra en el directorio de configuración e instalación. Nosotros hemos utilizado el siguiente comando:

./configure --with-proj --with-gdal --with-ogr --with-postgis=/usr/local/pgsql/bin/pg_config --with-wfs --with-wmsclient --with-wfsclient --with-curl-config
make

Para realizar la instalación en Apache, copiamos el archivo mapserv en el directorio cgi-bin del servidor web. Con esto queda instalado y configurado mapserver con las opciones que hemos elegido. Para servir mapas a través de la web tan sólo necesitaremos crear un fichero .map que configure las capas a servir, formatos, etc.

¿Muchas novedades = demasiadas novedades?

2006-08-22T08:36:00.000+02:00

Me ha surgido este dilema mientras preparaba un trabajo para dentro de un mes y pico (http://www.esri-es.com/esri2006/intro.htm), en el que se expondrán muchas novedades de software.

Independientemente de este caso concreto, me he preguntado si a veces las novedades de nuevas versiones resultan "excesivas" para el usuario. Cuesta mucho aprender a manejar un SIG (o, para el caso, cualquier otro programa), y parece que justo cuando le empezamos a coger el punto llega una nueva versión cargada de novedades que tenemos que volver a estudiar. ¡Vaya lata!.

Para el desarrollador, es todavía peor. Que te marquen una librería de uso común como "deprecated", y como mínimo hacemos una mueca de disgusto, al menos al principio (hasta que las ventajas de la nueva son evidentes, cosa que no siempre ocurre).

Aquí podemos distinguir dos tipos de personas. Las que detestan este hecho (comprensiblemente) porque su software hace lo que necesitan, y no necesitan nada más. O al menos creen no necesitarlo (otra cosa es optimizar lo que ya hacen). Y los entusiastas, que no pueden dormir tranquilos si no están trabajando con la última versión de todo (aunque sea un poquito inestable).

Yo me encuentro en el segundo grupo, evidentemente.

Salvo Windows (tampoco hay que arriesgarse tanto), suelo tener las últimas versiones de todo, muchas veces incluso versiones Beta de mi software favorito.

¿Qué tiene que ver esto con programación y con SIG?. Bueno, viendo lo rápido que están evolucionando las distintas opciones open source y la cantidad de novedades de ArcGIS 9.2 por poner dos ejemplos, es inevitable hacerse esta pregunta.

A los "remolones" cuesta convencerlos, quizás la industria camina más rápido que ellos, es una maquinaria que no para y saca versiones cada vez más rápido. ¿Es esto bueno?. No tengo ni idea, pero viendo cómo ha cambiado este mundillo en tan solo unos pocos años, yo deseo que no se pare el ritmo.

Como quien dice, anteayer estaba aprendiendo avenue. Increíble, ¿verdad?.

Cómo programar con ArcObjects y no morir en el intento - 3ª Parte

2006-06-25T20:35:00.000+02:00

A partir de la versión 9 de ArcGIS Desktop, se incluye un nuevo entorno de geoprocesamiento, que incluye un objeto de alto nivel, llamado Geoprocessor, que permite automatización ActiveX. ¿Qué significa esto?. Pues que podemos utilizar TODA la funcionalidad proporcionada por ArcToolBox desde un lenguaje de script compatible con ActiveX. El más completo y potente es Python (http://www.python.org), que además es open source y multiplataforma. Python es un lenguaje interpretado orientado a objetos, lo cual nos dará mucha flexibilidad a la hora de programar macros complejas o incluso programas completos, orientados a la resolución de tareas repetitivas y procesos SIG.

Además, al no ser necesario abrir las aplicaciones de ArcGIS Desktop, el rendimiento de nuestras macros es muy superior.

Veamos un ejemplo.

Este ejemplo importa archivos .e00 de ArcInfo workstation a formato cobertura. Para ello busca todos los ficheros .e00 en un directorio (primer parámetro) y guarda el resultado en otro directorio (segundo parámetro).

Como se puede apreciar, es un lenguaje de tipado dinámico, por lo que no es necesario decirle a cada variable de qué tipo es, simplemente las declaramos. La declaración del objeto Geoprocessor siempre se hace de la misma forma (en la línea GP = win32com.client.Dispatch("esriGeoprocessing.GPDispatch.1"). En python además es muy importante el sangrado de código, para ello conviene utilizar alguno de los editores que existen para este lenguaje. IDLE, incluido con Python, puede ser suficiente para empezar, aunque conviene utilizar PythonWin si estamos en plataforma Windows, dadas sus características más completas.

Este tipo de archivos pueden ejecutarse directamente desde una consola, sin necesidad de abrir ArcGIS Desktop.

Cómo programar con ArcObjects y no morir en el intento - 2ª Parte

2006-06-25T19:30:00.000+02:00

Algunos compañeros me preguntaban si escribiendo este tutorial de ArcObjects había muerto en el intento como sugiere el título. Ja, ja, ja, no, en realidad es por otros motivos por los que he estado alejado del blog, pero ahora tengo intención de retomarlo.

Así que continúo la entrega, en esta ocasión hablando de la opción más sencilla y que utilizan casi todos los que empiezan a trabajar con ArcObjects. Me refiero a las macros VBA en ArcGIS.

La primera pregunta es ¿por dónde empezar?. Un buen punto de partida puede ser la ayuda, los foros de internet (en http://edn.esri.com), ArcScripts (http://arcscripts.esri.com), etc. El siguiente ejemplo está extraído directamente de la ayuda de ArcGIS.

Para hacer funcionar una macro, simplemente abrimos el editor de Macros de Visual Basic para Aplicaciones (atajo de teclado: Alt+F11) y pegamos el código. Para escoger la macro que queremos ejecutar, podemos acceder al diálogo de macros con el atajo de teclado Alt+F8.

Este ejemplo añade, en una vista layout, elementos auxiliares de mapa como la leyenda o el simbolo de norte. Mas detalles en los comentarios del código.

Public Sub AddMapSurrounds()

Dim pMxDoc As IMxDocument
Dim pActiveView As IActiveView
Dim pEnv As IEnvelope
Dim pID As New UID
Dim pMapSurround As IMapSurround
Dim pMarkerNorthArrow As IMarkerNorthArrow
Dim pCharacterMarkerSymbol As ICharacterMarkerSymbol

Set pMxDoc = Application.Document
Set pActiveView = pMxDoc.PageLayout
Set pEnv = New Envelope

'Añade símbolo de norte
pEnv.PutCoords 0.2, 0.2, 1, 1
pID.Value = "esriCore.MarkerNorthArrow"
Set pMapSurround = CreateSurround(pID, pEnv, "North Arrow", pMxDoc.FocusMap, pMxDoc.PageLayout)

'Cambia el símbolo de norte por defecto
Set pMarkerNorthArrow = pMapSurround 'QI
Set pCharacterMarkerSymbol = pMarkerNorthArrow.MarkerSymbol 'clona el símbolo
pCharacterMarkerSymbol.CharacterIndex = 200 'cambia el símbolo
pMarkerNorthArrow.MarkerSymbol = pCharacterMarkerSymbol

'Añade una leyenda
pEnv.PutCoords 7.5, 0.2, 8.5, 4
pID.Value = "esriCore.Legend"
Set pMapSurround = CreateSurround(pID, pEnv, "Legend", pMxDoc.FocusMap, pMxDoc.PageLayout)

'Refresca el display gráfico
pActiveView.PartialRefresh esriViewGraphics, Nothing, Nothing
End Sub

Private Function CreateSurround(pID As UID, pEnv As IEnvelope, strName As String, _
pMap As IMap, pPageLayout As IPageLayout) As IMapSurround

Dim pGraphicsContainer As IGraphicsContainer
Dim pActiveView As IActiveView
Dim pMapSurroundFrame As IMapSurroundFrame
Dim pMapSurround As IMapSurround
Dim pMapFrame As IMapFrame
Dim pElement As IElement

Set pGraphicsContainer = pPageLayout
Set pMapFrame = pGraphicsContainer.FindFrame(pMap)
Set pMapSurroundFrame = pMapFrame.CreateSurroundFrame(pID, Nothing)
pMapSurroundFrame.MapSurround.Name = strName

'Asignar la geometría a un MapSurroundFrame
'para darle una localización,
'activarlo y añadirlo al PageLayout

Set pElement = pMapSurroundFrame
Set pActiveView = pPageLayout
pElement.Geometry = pEnv
pElement.Activate pActiveView.ScreenDisplay
pGraphicsContainer.AddElement pElement, 0

Set CreateSurround = pMapSurroundFrame.MapSurround
End Function

En general, podemos extraer muchos ejemplos ya hechos y adaptarlos a nuestras necesidades. La principal ventaja es que esta forma de programar con ArcObjects es relativamente sencilla. También es su principal inconveniente, pues se puede acabar haciendo programación "copy&paste" sin saber muy bien qué estamos haciendo. Una recomendación que se suele dar es no olvidar lo que está pasando por debajo, documentarse bien y echarle un vistazo al "Exploring ArcObjects", libro muy útil si se va a programar en serio con esta tecnología.

El ámbito de aplicación de este tipo de macros está restringido al uso de aplicaciones cliente de ArcGIS Desktop (ArcMap, ArcCatalog, etc.). En la siguiente entrega daremos un paso más para ver cómo se pueden hacer macros para tareas repetitivas que no dependan necesariamente de estas aplicaciones de usuario final.

Cómo programar con ArcObjects y no morir en el intento - 1ª Parte

2006-01-28T00:55:00.000+01:00

Bueno empiezo un pequeño tutorial por partes sobre cómo empezar a programar con ArcObjects. En esta primera parte simplemente enumero las opciones de programación con ArcObjects, en cuanto a lenguajes de programación y plataformas, junto con una pequeña explicación de cada una de ellas. En sucesivas entregas entraré en materia, con algunos ejemplos de código

La librería ArcObjects es un conjunto de componentes software construidos con tecnología COM de Microsoft, con la que se han construido productos como ArcGIS Desktop, ArcGIS Engine y ArcGIS Server. Por lo tanto, para programar con alguno de estos paquetes de software, necesitaremos programar utilizando la librería ArcObjects.

Hay muchas y diversas posibilidades, que dan mucha flexibilidad pero al mismo tiempo "asustan" al novato. Veamos cuáles son algunas de esas posibilidades, empezando por las más sencillas.

1. Utilizar VBA en las aplicaciones de escritorio de ArcGIS Desktop (ArcMap, ArcCatalog...). Es, quizás, la forma más rápida y sencilla de iniciarse, y existen muchos ejemplos. Disponible en ArcGIS Desktop
- Ventajas: fácil de probar, muy flexible, es la forma natural de empezar con ArcObjects
- Inconvenientes: no es POO (Programación Orientada a Objetos), es difícil reutilizar código. Necesitamos estar dentro de las aplicaciones de ArcGIS Desktop. Y además no está muy claro qué va a hacer Microsoft con esta tecnología

2. Utilizar python como lenguaje de script. Con python accedemos al objeto de alto nivel Geoprocessor, lo que nos permite utilizar en scripts o macros cualquiera de las herremientas que tenemos en ArcToolBox o en Model Builder. Disponible en ArcGIS Desktop
- Ventajas: fácil de aprender, muy útil para crear procesos batch
- Inconvenientes: sólo se expone una parte de la librería en la versión actual. No es adecuado para crear grandes programas, falta de integración con interfaces gráficas.

3. Utilizar un lenguaje compatible COM. Hay dos vías actualmente, en primer lugar compilar a código nativo con un lenguaje como puede ser C++ o Visual Basic, o utilizar la plataforma .NET de Microsoft (cualquier lenguaje) para crear ensamblados interoperables con la librería COM ArcObjects. Disponible en ArcGIS Desktop, ArcGIS Engine y ArcGIS Server para plataformas Windows
- Ventajas: muy amplias posibilidades de desarrollo, incluyendo la capacidad de construir un SIG completo, con necesidades a medida, en cualquier entorno. Código con alta reutilización
- Inconvenientes: más difícil (VB < .NET < C++), sólo para plataformas Windows

4. Utilizar Java, a través de la interoperabilidad con objetos COM que proporciona JIntegra (http://j-integra.intrinsyc.com/). Aunque no parece "natural" unir Java y COM, en realidad el concepto es análogo a la interoperabilidad proporcionada por Microsoft entre componentes COM y ensamblados .NET. Disponible para ArcGIS Engine y ArcGIS Server.
- Ventajas: multiplataforma (Windows, Linux, Solaris), integración muy buena con infraestructuras empresariales de todo tipo y alta reutilización del código
- Inconvenientes: ligera pérdida de rendimiento (puede ser importante en algunas aplicaciones), más difícil de programar.

5. Usar C++ multiplataforma. Disponible en ArcGIS Engine
- Ventajas: posibilidad de crear aplicaciones multiplataforma con código nativo
- Inconvenientes: mucho más difícil de programar

En sucesivas entregas iremos viendo ejemplos de algunas de estas tecnologías, aplicadas en un ámbito concreto.

Un año de programación SIG - Parte 2

2005-12-31T18:51:00.000+01:00

En esta segunda parte, me la voy a jugar con 5 predicciones de desarrollo GIS para el año que viene, bueno, y un poco más allá, ya que me pongo......

1. Empiezo con un comentario radical: el SIG de escritorio, tal y como lo conocemos, morirá. De hecho, desde hace tiempo es un enfermo terminal. Me explico. Hace años los únicos que manejaban estas aplicaciones eran "especialistas", hoy en día esto ha desaparecido prácticamente, los SIG de escritorio tienen interfaces visuales y son más potentes que nunca, pero los puede utilizar cualquiera. De hecho, son tan potentes que empiezan a no servir para las necesidades específicas que requiere cada sector. De hecho, cada vez es más frecuente la comercialización/utilización de librerías de componentes para personalizar nuestro propio SIG, en cualquier entorno (web, escritorio, móvil).

Bueno, es un poco exagerado, siempre hay un sitio para una buena aplicación de uso general, que usa el 20% de la funcionalidad y que sirve para el 80% de los usuarios. Al final, son buenas noticias para los desarrolladores, cada vez hay más necesidad de adaptación y personalización, no hay más que ver lo que piden en infojobs.

2. Veremos una evolución de los sistemas distribuidos, con todo lo que ello implica. Un SIG distribuido contará con funcionalidad SIG en todos los ámbitos, web, escritorio y móvil. De hecho, se perderá la "singularidad" de los SIG. No dejan de ser una serie de componentes y aplicaciones que aportan el análisis y consulta de información espacial. Hemos dejado de ser un sector "raro", y esta tendencia se acentuará en el 2006. Cada vez será más fácil para un desarrollador no especializado el programar con componentes SIG, como si lo hiciese con bases de datos relacionales.

Es un camino de no retorno, que está provocando la masiva aceptación y conocimiento de aplicaciones SIG, fuera de los ámbitos tradicionales. Asociado a esto, creo que en los próximos años este sector va a crecer muy por encima de la media, es algo que llevamos escuchando tiempo, pero ahora se empieza a notar. Y gran parte del trabajo por hacer tiene que ver con el desarrollo, así que habrá que estar a la altura del resto de la industria informática, como poco.

3. Esta predicción habla de tecnologías, y es quizás la más arriesgada, pero también la más divertida. Creo que seguiremos sin ver un SIG completamente programado en .NET, al menos uno que se use masivamente. La transición desde aplicaciones basadas en COM no está siendo todo lo rápida que a Microsoft le gustaría. Aún así, será una de las tecnologías de elección para programar en el escritorio (extensiones, aplicaciones personalizadas, etc) y en dispositivos móviles, algo menos en la web.

Java seguirá siendo el lenguaje para programación web y de dispositivos móviles, y cogerá un buen trozo del escritorio. Si estás empezando en esto y tienes que elegir plataforma de desarrollo, elige Java.

Seguiremos viendo proyectos con otras tecnologías (PHP,C,etc.), pero serán minoritarios. Está por ver cuánto tiempo tarda alguien en sacar algo con Ruby On Rails (si no lo han hecho ya), ahora que está tan de moda.

La menos arriesgada es apostar a caballo ganador. Bueno, caballo no, pingüino. Cada vez será más necesario tener aplicaciones multiplataforma, que se ejecuten con la misma funcionalidad en Windows y Linux, por citar los dos sistemas operativos más importantes en la actualidad. Linux está cogiendo algo de espacio en el escritorio, de forma muy tímida, pero donde ampliará su presencia es en el servidor.

En la industria informática se viene hablando de tecnologías que parecen antagónicas y competidoras pero que persiguen el mismo objetivo: hacer la vida más sencilla al usuario (bueno, y crear aplicaciones más vistosas, que entren por los ojos). Me refiero a todo lo relacionado con Web 2.0 (Ajax, Flex, RIA, etc.) y a los "clientes ricos" conectados parcialmente (Java Web Start, Smart Clients, etc.). En aplicaciones SIG, ambos tienen su lugar, pero mi apuesta es por los segundos. Esta apuesta es muy arriesgada, porque todo el mundo tiene en mente las aplicaciones web (a veces sobrevaloradas) pero en SIG tiene muchísimo sentido tener clientes "pesados" que conectan con un servidor para obtener funcionalidad y datos, con interfaces de usuario que la web nunca tendrá en cuanto a funcionalidad y usabilidad, y capaces de visualizar y analizar datos locales con la misma efectividad. El ejemplo más típico es Google Earth, pero veremos casos más completos, como éste. En cualquier caso es un nuevo tipo de aplicación SIG, más pequeña, más extensible y personalizable, y de uso más general. Por cierto, donde causarán más impacto es en dispositivos móviles.

Mi última predicción tecnológica tiene que ver con los servicios web. Veremos más y mejores servicios, hoy en día todo el mundo conoce los servicios de datos, bien en forma de especificaciones OGC (no siempre muy afortunadas) o ejemplos más concretos como este. Pero los que creo que empezarán a eclosionar son los servicios de funcionalidad, con interfaces estándar como SOAP o REST. Ya existen a día de hoy, pero al menos en España son muy poco utilizados.

4. El mercado de trabajo para desarrolladores SIG seguirá siendo lo más demandado en el sector. Tiene sentido, si quiero ser coherente con lo escrito anteriormente. De hecho, la conversión de sistemas SIG desde aplicaciones más o menos científicas a sistemas de gestión producen este efecto.

5. Para acabar, a nivel personal, confío en que el 2006 sea mejor en lo profesional incluso que el 2005. Para el año que viene espero seguir creciendo profesionalmente, y sobre todo aprendiendo nuevas técnicas y profundizando en el desarrollo de sistemas de información geográfica. Espero tener tiempo para aprender Flash, echarle una ojeada a RoR por pura curiosidad, y tener la oportunidad de desarrollar algo con J2ME. Confío en seguir teniendo la suerte de explorar las últimas novedades, pues aunque esto me hace no quedarme quieto ni un instante (y a veces cansa), es intelectualmente muy estimulante.

Un año de programación SIG - Parte 1

2005-12-31T17:37:00.000+01:00

Bueno, el resumen anual y predicciones del nuevo año son un clásico en toda columna de opinión que se precie, así que me voy a atrever con una versión personal de 5 hitos en el desarrollo de sistemas GIS durante este año (primera parte), y 5 "predicciones" de por dónde van a ir los tiros el año que viene (segunda parte). Es difícil resumir 365 días, así que agarra tu refresco favorito y lee con paciencia.

El mundo del desarrollo ha sido sacudido en el año 2005 por algunas "nuevas" tecnologías y tendencias (o la reinvención de las mismas), y los SIG no han sido ajenos a este fenómeno. Algunos ejemplos se citan a continuación.

1. Asistimos a un avance del software open source en toda la industria en general, y también en los SIG. Sin embargo, los SIG open source están muy atrasados en funcionalidad con respecto al software comercial (hablando en términos relativos y comparándolo con otros sectores). Los que tenían más funcionalidad (GRASS.....) no parecen haber evolucionado tecnológicamente y se han estancado, siendo su uso residual. Está por llegar el "gran" SIG open source y gratuito (pues esta segunda característica es la que importa, no nos engañemos), pero estamos más cerca, de ello no me cabe duda, sin embargo no ocurrirá en mi modesta opinión hasta que uno de los "grandes" done código o colabore con programadores (ya está ocurriendo, ver unas líneas más abajo).

Más que un programa será un conjunto de programas, bien conocidos, fáciles de instalar y de utilizar.

Al hilo de esto, se han producido movimientos interesantes en el mundillo GIS open source. En España existen iniciativas apoyadas por la administración que promocionan software libre por encima del comercial, y han surgido proyectos de creación de sistemas GIS prácticamente desde cero, financiados con dinero público, con la intención de sustituir el software comercial que se venía utilizando. Una apuesta arriesgada que el tiempo dirá si fue acertada o no.

De forma más general, destaca sin duda la toma de poder por parte de Autodesk de la "marca" Mapserver, a golpe de fundación. Se puede leer más aquí.

A muchos miembros de la comunidad Mapserver no les ha hecho mucha gracia esto.

2. Este año ha sido sin duda el año de Google, y nos han regalado dos maravillosas aplicaciones para los giseros: Google Maps y Google Earth. Ambos orientados al usuario final, no especialista en GIS. Gracias a la difusión que tiene Google, todo el mundo los conoce. Lo interesante además es que podemos hacer nuestras pequeñas personalizaciones y adaptaciones, para compartir información geográfica con amigos y compañeros. Esto me lleva a una reflexión: cuando se tiene la mejor tecnología y el producto es gratis, a la gente le importa un bledo si es open source o no. No entro a valorar si esto es bueno o malo, pero la experiencia me demuestra que es así.

Gracias a estas aplicaciones se ha creado lo que se podría llamar una sociedad "sensible a la geografía". Y desde un punto de vista más tecnológico, el que interesa aquí, el caso de Google Earth demuestra que no todo está inventado, y que la web puede ser un mecanismo adecuado para aplicaciones complejas. El streaming de datos que utiliza, simplemente, se sale.

3. Hablando más de desarrollo, específicamente de aplicaciones web, este año han pegado el pelotazo los términos "AJAX" , "Web 2.0", "RIA = Rich Internet Applications", etc. Se han popularizado este tipo de aplicaciones, que nos proporcionan un nivel de interactividad en web que no estábamos acostumbrados a ver. Ya existen ejemplos en GIS, como Google Maps, la librería Ka-Map para UMN MapServer o los componentes que veremos en las siguientes versiones de ArcIMS y ArcGIS Server.

El éxito de este tipo de proyectos pasa, en mi opinión, por no caer en la tentación de usar "AJAX para todo", pues mantener semejante cantidad de código Javascript puede ser un verdadero infierno. Pero es una tecnología que se está asentando, y cuando se estabilice y generalice alguno de los "framework" de reciente aparición, será un arma muy poderosa en el arsenal de todo desarrollador de aplicaciones web, y muy particularmente de aplicaciones GIS, donde la vistosidad y usabilidad cuentan muchísimo.

4. En el año 2005 se ha consolidado la necesidad de contar con sistemas de información geográfica que sean capaces de integrarse con otras aplicaciones. Actualmente un SIG moderno debe ser capaz de integrarse con el resto de sistemas de una gran organización, ejecutarse en múltiples plataformas tecnológicas y sistemas operativos, y funcionar en red de forma colaborativa. Hace años que empezó esta tendencia (GIS corporativo), durante este año he podido asistir de forma personal al nacimiento y diseño de sistemas distribuidos. Conceptos como réplicas, sincronización, servicios web distribuidos, edición desconectada u online ya no nos resultan extraños y forman parte del presente.

5. Bueno, al ser un blog personal, he dejado para el final aspectos más particulares. Para mí el año 2005 ha sido un año de cambios, un año de duro y satisfactorio trabajo. Como años anteriores, un año de mucho aprendizaje, nunca se deja de aprender, un año de retos (y algún que otro marrón inesperado, que aunque desagradables también curten lo suyo), muchas presentaciones en público, pero, sobre todo, un año en el que he conocido a grandes profesionales y amigos, con los que ha sido un auténtico placer compartir la rutina, dentro y fuera de la oficina. Un año de programación SIG, en definitiva, un buen año.

RIA para aplicaciones SIG en web, ¿sólo AJAX?

2005-11-22T08:02:00.000+01:00

RIA= Rich Internet Applications

Todos hemos visto las interfaces de usuario de lo que se ha venido a llamar Web 2.0 (nunca me han gustado esto términos que tienen más de marketing que de fundamento técnico) tipo GMail. Utilizan técnicas que estaban disponibles, pero que sólo recientemente se han generalizado en los navegadores (el famoso HttpXmlRequest), y que alguien ha bautizado como AJAX (Asynchronous Javascript and XML).

¿Cómo se aplicaca esto a aplicaciones SIG distribuidas, y cuáles son las alternativas?.

AJAX ya se utiliza a día de hoy en aplicaciones web con funcionalidad geográfica (Ka-Map en Mapserver, ArcIMS y ArcGIS Server en la próxima versión, Google Maps, etc.). AJAX es la nueva "moda", y parece que un proyecto que no lleve esta tecnología no está a la última, y no es capaz de ofrecer una interfaz de usuario amigable, intuitiva, y lo que es más importante, con rendimientos y experiencias de usuario "adecuados".

Sin embargo, AJAX tiene varios inconvenientes, en los cuales no me voy a extender aquí (recordemos que se programa casi toda la aplicación en cliente, eso significa Javascript, eso significa código mucho más difícil de depurar, mantener y reutilizar).

¿Existen alternativas?. Siempre existen, veamos algunas.

1. SVG. "Estándar" recomendado por el W3C para dibujo vectorial 2D en la web. Es decir, parece ideal para nuestras aplicaciones, y hay cosas muy interesantes. Es parecido a Flash en cuanto a los resultados, pero basado en XML y animable y modificable mediante ECMAScript/Javascript. Sin embargo, plantea varios problemas.
NO tiene soporte nativo en los navegadores todavía. Hay un plugin de Adobe que permite visualizar estos archivos, y Mozilla se puede compilar con soporte SVG. Pero ambos procesos son agresivos desde el punto de vista del usuario (tiene que instalarse cosas), incluso muchos proyectos prohíben la necesidad de instalar nada en cliente. Hasta que tengamos soporte nativo generalizado, es una opción poco generalista, que puede no obstante ser muy buena en entornos intranet con un navegador específico.

2. Clientes pesados. Hablaré de Java (clientes SWING, no applets) pero es también aplicable a .NET u otros. Si realmente deseamos un cliente que mantenga el estado, que pueda incluso trabajar con conexiones intermitentes, con una interfaz rica de usuario y efectos de usabilidad complejos, este es el camino.

Si, nos hemos salido del navegador, y esto no es un sacrilegio, tenemos acceso a los recursos del Sistema Operativo, y podemos hacer muchas más cosas. Hay literalmente miles de efectos que podemos conseguir de una forma más precisa y sencilla sin hacer malabarismos con el código.

Impulsados por accesos remotos a servicios web, este tipo de clientes son el futuro de aplicaciones empresariales complejas, sobre todo en entornos intranet donde podemos asegurar una cierta homogeneidad (por ejemplo la necesidad de una máquina virtual determinada). El inconveniente es la necesidad de descargar el JRE (o runtime .NET) para poder funcionar. Se pueden desplegar con Java Web Start desde una página web (.NET acaba de sacar una tecnología análoga).
El escritorio ha vuelto, según dicen.

3. Macromedia Flex. La dejo para el final porque es la única con la que de momento no tengo experiencia. He visto los resultados que se pueden obtener con esta "suite" y son sorprendentes por la vistosidad. Teniendo en cuenta que el 97% de los navegadores soportan el formato Flash, y que se pueden hacer llamadas remotas a objetos Java (y próximamente a .NET también) y a servicios web SOAP/XML, parece una opción muy potente.

Conclusión: estas tres alternativas a mi juicio son más "limpias" que Javascript + DOM + XML + navegadores incompatibles y no estándares. Pero plantean un problema MUY gordo. Todas requieren instalar algo en cliente.

O sea, que tenemos AJAX para rato (a pesar de la cantidad de proyectos que se van a estrellar por su mal uso).

Configurar JBoss y Java Server Faces para aplicaciones de ArcGIS Server

2005-10-23T01:54:00.000+02:00

La última versión de JBoss (4.0.3) tiene soporte para Java Server Faces (JSF) siguiendo la implementación de Apache MyFaces. Si bien es una implementación excelente, es preferible utilizar la implementación de referencia de Sun Microsystems para trabajar con aplicaciones de ArcGIS Server.

Para ello, no hay más que borrar el directorio jsf-libs que se encuentra en /server/default/deploy/jbossweb-tomcat55.sar e incluir los .jar de JSF 1.0/1.1 en el directorio WEB-INF/lib de nuestra aplicación.

Conferencia Usuarios ESRI España 2005: el día después

2005-09-30T18:53:00.000+02:00

Se me ha pasado volando la Conferencia de Usuarios, supongo que por la actividad frenética de estos dos días, en los cuales tenía 5 participaciones programadas que se convirtieron en 6 gracias a una sorpresa que me tenía preparada una compañera (se la pienso devolver el año que viene, je, je).

Como momentos clave desde el punto de vista personal, he de destacar la participación en la sesión inaugural junto a mis compañeros del Departamento de Preventas, con demos diversas de la tecnologia ArcGIS y algunas de sus novedades en la versión 9.1, que funcionaron tal y como esperábamos. Ese momentillo de incertidumbre delante de cientos de personas (y de todos tus jefes, también) es un subidón de adrenalina difícil de explicar con palabras.

El ambiente en general ha sido muy distendido, había muchísima gente (más de 1000 personas sólo el segundo día), hemos batido récord de asistencia. A mi personalmente el lugar de celebración me ha gustado (Palacio Municipal de Congresos).

He recibido mucho feedback por parte de los usuarios, de una manera más completa y masiva que en los seminarios, y algunos se han acercado a felicitarme, lo cual se agradece sinceramente. También he recibido críticas constructivas interesantes, lo primero que he hecho en la oficina hoy ha sido leer las evaluaciones. En general por lo que he visto la gente ha escuchado lo que teníamos que contarles con mucha atención, y parece haber cubierto las expectativas de la mayoría.

Espero que el año que viene sigamos en esta línea, mejoremos los fallos que sin duda hemos cometido (espero que sepamos identificarlos todos) y que la Conferencia de Usuarios 2006 sea todavía más grande que la de este año.

Vistas las novedades que se avecinan para la versión 9.2, y la ilusión y esfuerzo que pondremos en preparala, no me cabe la menor duda de que así será.

Conferencia de usuarios ESRI España 2005

2005-09-14T21:03:00.000+02:00

Los días 28 y 29 de septiembre se celebrará en el Palacio Municipal de Congresos de Madrid (Campo de las Naciones) la Conferencia de Usuarios de ESRI España (podéis obtener más información en www.esri-es.com). Será mi primera participación como miembro del grupo técnico después de mi incorporación a esta empresa el año pasado (siempre lo he hecho como usuario desde que me dedico a esto), y sólo puedo decir que la experiencia desde dentro está siendo muy motivante (a la par que estresante). Hay miles de detalles que pulir todavía, nunca terminaría de repasar o de intentar mejorar aspectos de diversa índole, ojalá tuviésemos más tiempo para preparar la "demo perfecta" pero el día D ya está muy próximo y hay que ir terminando las cosas. Claro, después de haber asistido a la Conferencia en USA uno quiere estar a la altura, y salvando las distancias desde luego que lo intentaremos, en la medida de nuestras posibilidades y conocimientos.

Evidentemente no voy a estropear las sorpresas y no voy a adelantar detalles, pero ahí van algunos apuntes/reflexiones

Habrá novedades como siempre pero sin apabullar, todo lo que mostremos los técnicos de ESRI España tiene aplicación hoy. Habrá demos nuevas, en la línea de lo que hemos visto en ediciones anteriores pero más evolucionadas, y también enseñaremos herramientas que no se han visto todavía en España (al menos de forma generalizada). Tendremos charlas técnicas y workshops para intentar ayudar a nuestros usuarios a hacer un mejor uso de nuestra tecnología, y por supuesto estaremos en el stand técnico para resolver dudas. Atentos aquellos que os guste la producción cartográfica o trabajéis con redes, y por supuesto los desarrolladores (un poquito de autopublicidad aquí).

Por supuesto, también se hablará del futuro de la tecnología de ESRI, estad atentos porque algo gordo se mueve en este sector, y las novedades de la siguiente versión de la tecnología ArcGIS (en todos sus productos, desde el escritorio al servidor pasando por aplicaciones móviles) son muchas y muy interesantes (tanto para los desarrolladores como para usuarios finales). Creo que algunas darán mucho que hablar.

Espero que este año sea un éxito y superemos incluso la cifra de asistentes que se tuvo el año pasado, yo por mi parte estoy contando los días que quedan (¡por varios motivos, obviamente, pero prometo que dará tiempo a tenerlo todo listo!).

El día después, intentaré hacer un resumen de mi experiencia.

ArcGIS Server en Java: configuración IDE

2005-09-14T20:17:00.000+02:00

Una de las primeras tareas que debemos realizar para desarrollar con ArcGIS Server es configurar nuestro IDE. En esta ocasión, explicaré cómo configurar Netbeans 4.1 para desarrollar con la API de Java de ArcGIS Server. Aunque podemos adoptar varias estrategias, para mi la más fácil es:
1. Instalar ArcGIS Server ADF (kit de desarrollo) para Java. Instalar Netbeans. Aquí hay poco que explicar pues son instalaciones estándar, por defecto
2. Crear variable con las librerías necesarias para programar. Podemos añadir a una librería de Netbeans los jar necesarios, ponerle un nombre significativo (yo uso ArcGISServer) y una vez referenciada en nuestro proyecto, ya podemos empezar a picar código. Los jar que necesito si quiero utilizar toda la potencia del ADF (componentes visuales Java Server Faces incluidos) son los siguientes:
- arcobjects.jar
- jintegra.jar
-standard.jar
- arcgis_jcs.jar
-arcgis_webcontrols.jar

Además hay otros jar que pueden ser necesarios, de uso bastante común (commons*, jsf*, etc). Como estas pueden estar referenciadas en otras librerías, no los incluyo aquí. Todos estos jar se pueden encontrar en \DeveloperKit\Java y algunos de sus subdirectorios

ArcGIS Server: Introducción

2005-06-16T20:44:00.000+02:00

Bueno, tras 6 meses trabajando con este producto, me atrevo a "aconsejar" algunas cosas, siempre desde la perspectiva de mi opinión personal. Pero no hay nada como la propia experiencia. Ahí van:

1. Me parece el producto más revolucionario que existe en la industria del SIG actualmente. No hay nada igual, las cosas que se pueden llegar a hacer son increíbles. Tener toda la librería ArcObjects en el servidor......las posibilidades son enormes, no es un ArcMap en el navegador como entienden (mal) algunos, pero es lo que más se le puede acercar..
2. Para no parecer un mensaje publicitario, diré lo que menos me gusta: es difícil y es nuevo. O sea, facilísimo atascarse en un momento dado, esto es normal con productos "nuevos".
3. Hay que tener en cuenta que muchas aplicaciones no serán viables en internet. No parece lógico tener a 200 usuarios realizando mapas de pendientes a través de un navegador, contra un servidor. Pero geocodificar, calcular rutas, componer mapas, hacer análisis espaciales sencillos o subir ciertos datos al servidor para ser posteriormente publicados......
4. Básicamente, podemos elegir entre .NET o Java. ¿Cuál?. Pues empecé con .NET, es mucho más fácil y rápido, hay más documentación (corregido en parte en la versión 9.1), etc, etc. Pero tras un sondeo empírico (y completamente informal y sin base científica) del mercado me doy cuenta de que este tipo de aplicaciones entran de lleno en las grandes aplicaciones empresariales, como un módulo más con componente geográfica. O sea, J2EE a día de hoy. Yo personalmente me quedo con Java, aunque se ve a la legua que "respira" tecnología COM por los cuatro costados
5. NO ES UN SUSTITUTO DE ARCIMS. Aunque es cierto que hay un solape de funcionalidad. Como desarrollador, se agradece por un lado las enormes posibilidades, por otro abruma un poco. Con ArcIMS tienes una API muy manejable, luego hay que buscar "trucos" para hacer cosas más avanzadas. Aqui sabes que esa funcionalidad está por algún sitio, lo malo es encontrarla, al igual que pasa con Desktop o Engine. Es fundamental tener algo de experiencia con ArcObjects.
6. Se pueden hacer fácilmente servicios web SOAP XML con funcionalidad SIG :-)

En general, es bastante agradecido, gracias a los tutoriales y al kit de desarrollo, sobre todo con el de .NET es muy sencillo programar aplicaciones básicas.

Script para cargar capas en Postgis

2005-04-27T20:50:00.000+02:00

En sistemas UNIX/Linux nos podemos aprovechar de la programación en shell para cargar nuestra información en procesos batch muy sencillos. El siguiente script convierte todos los shapefiles en un directorio a formato Postgis.

db=carto

for i in *.shp
do
x=${i%.shp}
echo 'Importando' $x
shp2pgsql -d $x $x $db | psql -d $db
done

La misma idea puede ser aplicada para cualquier comando de sistema operativo, o para cargar datos en otras bases de datos geográficas, por ejemplo este script es válido para cargar datos en ArcSDE bajo UNIX/Linux, simplemente cambiando el comando que realiza la conversión.

Geotools

2005-04-26T22:04:00.000+02:00

Bueno, he estado trasteando un poco más con esta librería. Podéis echarle un vistazo en http://www.geotools.org. La verdad es que en la versión 2.0 ya tenemos una librería muy usable. Me sigue molestando un poco ver cómo se van "deprecando" continuamente diferentes módulos, como desarrollador quieres algo que funcione y que aporte nueva funcionalidad, pero no que cambie cada dos por tres. Bueno, supongo que con el tiempo adquirirá una mayor madurez.
La librería es bastante extensa y me sorprende lo rápido que avanza últimamente. Gracias a esta librería podemos construir aplicaciones en Java con bastante funcionalidad, sobre todo de visualización.
En un futuro próximo incluiré algún ejemplillo de código, aunque en su web hay muchos tutoriales bastante útiles.

Lenguajes más utilizados

2005-04-26T21:40:00.000+02:00

Hoy en día, Java parece el lenguaje de moda en el mundillo de los SIG, sobre todo a la hora de empezar nuevos desarrollos. Proyectos como Geotools, Degree, JTS, etc en el caso de Open Source y las APIs Java de algunos productos comerciales (ESRI, Mapinfo) nos hacen ver que la plataforma Java se va extendiendo entre las aplicaciones de SIG, y que sigue gozando de buena salud diez años después de su lanzamiento.
Pienso que la plataforma .NET está perdiendo oportunidades en otro nicho que tiene todavía un largo recorrido. Quizás es debido a la falta de madurez de .NET (me han pasado unas cosas curiosísimas últimamente) y a que es un producto nuevo. Pero lo cierto es que me gustaría ver un programa parecido a geoserver (http://geoserver.sourceforge.net) desarrollado con .NET puro.
Sería interesante tal comparación, si alguien se anima.....