geofumadas

Anteriormente vimos como desde Manifold era posible publicar servicios web, desde la plataforma de escritorio; también al crear esto vimos que hay una opción para disponer una página interfase para estándares WFS y WMS.

Justo ahora ha sido anunciado que ya está disponible la extensión de publicación para gvSIG 1.1.x, que permite al usuario publicar información geoespacial y metadatos a través de servicios web estándares OGC, desde la propia interfaz de gvSIG y sin necesidad de hacerlo directamente sobre el software del servidor correspondiente.

De esta forma, sin un conocimiento específico de estas aplicaciones, el usuario de gvSIG será capaz de publicar en internet, con extrema sencillez, la cartografía y los metadatos que genera.
Esta primera versión permite concretamente publicar información geoespacial en los siguientes servidores y a través de los siguientes servicios:

• Mapserver: WMS, WCS y WFS.
• Geoserver: WFS.

Está disponible en el apartado Extensiones de la web de gvSIG (http://www.gvsig.gva.es/index.php?id=2010&L=0).

La construcción de esta extensión ha sido desarrollada gracias a la colaboración de el Ayuntamiento de Munich (Alemania), aparte de las dos instituciones vinculadas directamente a GvSIG (La conselleria de Infraestructuras y Transporte Generalitat e IVER)

Para instalar esta extensión es necesario tener correctamente instalada la versión 1.1.x de gvSIG.

Búsqueda personalizada

Buen día, buena lectura y mejor claridad respecto a como lo hace GvSIG y claro, poderlo comparar con Manifold

Veamos como se comportan estas dos herramientas en los formatos que leen:

GvSIG	Manifold
Manejo de Proyecto: El formato gvp es un manejador de datos, no contiene información dentro.  Parecido al apr de ArcView, o como el mxd de ArcMap.  Puede "linkar" datos externos	Manejo de Proyecto: El formato .map de Manifold es una especie de manejador, pero éste puede contener datos dentro, tanto vectorial, tabular como raster.  También puede almacenar datos en bases de datos externas (como la geodatabase de ArcView) y puede "linkar" datos externos
Documentos: Dentro del proyecto GvSIG maneja tres tipos de documentos: Vistas, Tablas y Mapas.  Parecido a lo que era en ArcView (Views, Tables, Layouts).  Las vistas pueden tener varias capas y se pueden hacer agrupaciones parecido a los layers de ArcMap	Componentes: Dentro de un proyecto Manifold, los componentes equivalentes a lo que maneja GvSIG son "Maps, Tables, y Layouts". El manejo en este entorno es muy diferente entre ambas plataformas, aunque posiblemente hacen lo mismo, Manifold maneja 16 tipos de componentes bajo este mismo nivel incluidos formularios, gráficos, superficies, perfiles, carpetas y comentarios.
Archivos vectoriales: GvSIG puede leer kml/kmz, dxf, dwg 2000, dgn v7. Puede editar shp y dxf	Archivos vectoriales: Manifold requiere importar los archivos vectoriales (no los puede linkar), y reconoce kml/kmz, dwg R13, R14 y R15(2000), también dxf2000 y dngv7.  Manifold no puede editar estos formatos, al importarlos se convierten en drawings dentro de una base de datos que puede ser externa o estar contenida dentro del .map
Otros formatos: GvSIG puede conectarse a datos en formatos OGC compatibles como WFS, WCS y ArcIMS… también a Web Map Context y vía JDBC de MySQL, SQL y PostGIS	Otros formatos: Manifold puede importar (en forma vectorial) de una gran cantidad de formatos, entre ellos e00, csv, tab, txt, gml, html, IDRISI vct, mif, xls incluidos data sources de Oracle, SQL y ODBC A la mayoría de ellos se puede conectar de forma "linkada"
Imágenes: Aparte de los formatos no georeferenciados, se incluyen MrSID, ECW, ENVI y GeoTIFF; también puede conectarse a servicios WMS y servicios de ArcIMS	Imágenes: Aparte de los formatos no georeferenciados, soporta SID, ENVI, SPOT, ECWP y muchas otras fuentes de datos tanto importados o "linkados". Requiere un Plugin para MrSID pero trabaja lento. También se conecta a servicios OGC Adicionalmente puede conectarse a servicios Google Earth, Virtual Earth, Yahoo Maps, Google Street
En general, GvSIG mantiene su razón de creación: ser compatible con estándares OGC y los formatos de software más conocidos	Manifold tiene muchas características en cuanto a reconocimiento de diversos formatos, y aunque soporta estándares OGC, desde la versión 6 no oficializan compatibilidad.  Cuando la gente pregunta salen con la misma ironía de su servicio: "los estándares OGC son obsoletos"

Búsqueda personalizada

Justo ahora que estoy "obligado" a entrarle a GvSIG, aquí mi primera impresión.

Amistoso.

A medida que he estado imprimiendo el manual de 371 páginas, me he formado la impresión que esta herramienta fue hecha para usuarios de AutoCAD y ArcView.  La similitud con ArcView me la esperaba con su simplicidad "vista, tabla, mapa" pero con AutoCAD ni por cerca… empezando por las nomenclaturas de rumbo y distancia usando el símbolo @ al estilo que todos aprendimos con las versiones R12 y que aunque se consideran obsoletas, son prácticas para fines de topografía.  Claro que las capacidades de construcción son mínimas pero me parecen casi suficientes.

Esto lo debería aprender Manifold, con su incómoda forma de "no querer parecerse a ArcView" que si bien no es malo con su manejo de layouts abajo y la barra lateral a la derecha; en el fondo se limita en un concepto pedagógico llamado "aprendizaje por asociación"… pero ni les digas que su respuesta es la misma:

"…el diseño de framework utilizado por algunas herramientas es obsoleto…"

Microstation ha dejado ya por un lado esa manía que traía al no querer parecerse a AutoCAD, aunque mantiene su estilo propio no tiene nada de malo hacer las barras como lo hacen los usuarios de windows.  Aunque hace mucho que debió agregar una nomenclatura más práctica para el ingreso de rumbos y distancias al estilo AutoCAD en su keyin… para poner un ejemplo.

Instalación lenta

Definitivamente la instalación es una maravilla, nada de prerequisitos… al estar sobre Java lo único que pregunta es si quiere instalar la máquina virtual adecuada para la versión a instalarse.

Eso sí, se tarda su rato pero sin trabas.  Una vez instalado está listo para uso… buena pregunta, ¿Se puede instalar sin Internet teniendo el JVM listo?

Buen manual

Aunque no está al estilo que yo hubiera preferido, en que un quick book forma los primeros dos capítulos y luego el resto para ampliar las funcionalidades… no está mal la didáctica del manual y sobre todo en español.

Cuando le preguntaron a los Manifold´s porqué no hacían un manual formal dijeron que la ayuda en línea era la mejor forma de mantener actualizados todos los cambios, al tiempo que le evitaban tener que incrementar $25 por licencia en un manual impreso que mientras llegaba al buzón ya estaba desactualizado… en fin, quien los saca de su tema… no es malo ser testarudo pero J$$%&#lin si nos tocara a todos empantanarnos en hacer manuales para cada herramienta a implementar.

Tener una buena herramienta es magnífico, Manifold lo es, pero su soporte a lo cavernícola es medio tomado del pelo… dicha que existen los foros.   Espero los geofumados de esta aplicación que tanto admiro recuerden que seguimos siendo "clientes" y a un "cliente que pagó por su licencia" no le puedes decir ironías como: "por favor, no malgaste sus tokens de soporte… no esperamos que venga aquí con preguntas que están en el readme…"  ah, se me olvidaba que no hablan español por lo que poco gano con rasgar mis vestiduras ante tan selecto público.

En resúmen, creo que Manifold es una de las mejores soluciones de sofware SIG comercial, a un precio increíble… si yo fuera Oracle lo compraría.

…y me cae bien gvSIG, ya veremos cuanto me dura el romance.

Me había estado haciendo el currito, pero ni modo, ya salió un grupo de no fumadores que quieren un curso de GvSIG así que tengo una semana para aprender a usarlo e iniciar la tutoría que me tomará 2 semanas de mi horario nocturno. También con este post inicio una nueva categoría en mi panel lateral: GvSIG.

En realidad no pidieron esa aplicación, pidieron una que sea gratis y fácil de usar… gratis muchas, fácil de usar cuestionable!… emocionante sin duda!. Creo que aprovecharé para compararlo con Manifold y otros.

Si tuvieran $250 les recomendaría Manifold porque sé lo que hace y lo que no hace, pero como no quieren gastar plata entonces mejor irse por una herramienta que tenga manuales listos y que sea estable (aunque no les saldrá gratis la curva de aprendizaje… ni la mía).

Y para quienes no tienen idea que es GvSIG, aquí lo básico:

• Surge (como oferta a licitar) a finales de 2003, fue desarrollado por IVER quien ganó la partida, pero tiene la sombrilla institucional de el Fondo Europeo de Desarrollo Regional (FEDER), La Consejería de Infraestructuras de Valencia y de la Universidad de Jaume I
• La licencia es GNU GPL
• Está desarrollado 100% sobre Java (con excepción de algunas librerías propietarias de ECWy MrSID), por lo que corre tanto en Windows, Linux y Mac.
• Las librerías en que se ha desarrollado son estándares como Geotools y Java Topology Suite conocido como JTS entre otras.
• Es interesante que aparentemente soporta “internacionalización”… se supone que se adapta de forma nativa al idioma del usuario… mmmm?
• Soporta archivos de uso común como shp, dxf, dwg, dgn, kml e inclusive gml
• Soporta formatos raster como MrSID, GeoTIFF, ECW y ENVI
• Soporta estándares OGC incluidos WMS, WFS, WCS y servicios de nomenclaturas
• Promueve las cinco características que eran requisitos al momento de ofertarse: Portable (Windows / Linux en aquel momento), Modular, Código abierto, sin costo de licenciamiento, Interoperable (al menos con AutoCAD, Microstation y ArcView en aquel momento), Sujeto a Estándares.

Si se quiere extender, se pueden integrar servicios IMS y otras maravillas a través de extensiones que incluyen visualizar y editar cartografía de OpenStreetMap, conexión a extensiones de ESRI como ArcSDE y ArcIMS… entre otras.

De lo más enriquecedor de esta herramienta es la comunidad que está detrás de su desarrollo, difusión y documentación… algo que le garantiza un cierto nivel de sostenibilidad con que no cuentan todas las plataformas abiertas… al menos con tanto énfasis en idioma español.

Allí les cuento como me va.

Boston GIS ha publicado una comparación entre estas herramientas para manejo de datos espaciales:

• SQL Server 2008 Spatial,
• PostgreSQL/PostGIS 1.3-1.4,
• MySQL 5-6

Es interesante, que Manifold es mencionado como una alternativa viable… eso es bueno luego que hace más de un año le tiramos flores esperando crezca su popularidad.

Aunque a Manifold no le va bien con MySQL, y el comparativo no considera Oracle, en lo que Manifold está bien sentado.

Admito que apenas si he hecho algo de traducción, y por mi interés en Manifold sin embargo si están interesados en el post, pueden verlo completo en Inglés en su fuente original, pues en la segunda etapa del post muestran un listado de las funciones espaciales de las diferentes plataformas.

Característica	SQL Server 2008 Spatial	MySQL 5-6	PostgreSQL / PostGIS 1.3-1.4
Sistema Operativo	Windows XP, Windows Vista, Windows 2003, Windows 2008	Windows XP, Windows Vista, (no comprobado en 2008), Linux, Unix, Mac	Windows 2000+ (including Vista and 2003, no comprobado en 2008), Linux, Unix, Mac
Licencia	Comercial- fuente cerrada	Comercial código abierto (COSS), algunas partes GPL.	FLOSS (PostgreSQL es BSD, PostGIS es GPL Open Source - se pueden usar aplicaciones comerciales pero si se hacen cambios que afectan las librerías de PostGIS, debes regresarlas a la comunidad
GIS gratuitos que cargan los datos	shp dataloader for SQL Server 2008 desarrollado por Morten Nielsen (aún no trabaja con RC0)	OGR2OGR, shp2mysql.pl script	se incluyen shp2pgsql, OGR2OGR, QuantumGIS SPIT, SHP loader para PostGIS también desarrollado por Morten usando SharpMap.NET , existen otros
GIS Comerciales que lo soportan	Manifold, Safe FME Objects, ESRI ArcGIS 9.3 (en un último service pack)	Safe FME Objects	Manifold, FME Objects, ESRI ArcGIS 9.3
Disponibilidad de controladores específicamente para componentes espaciales	? aún no - SharpMap.NET eventualmente y probablemente construido en un nuevo ADO.NET 3.5+	GDAL C++, SharpMap via OGR, AutoCAD FDO	SharpMap.Net, JDBC postgis.jar incluido con postgis, JTS etc. tons para Java, GDAL C++, AutoCad FDO beta support
Visores de escritorio y editores gratuitos	Se construirán sobre SQL Manager, pero no disponibles en RCO y solo para viewer	GvSig	OpenJump, QuantumGIS, GvSig, uDig
Visores de escritorio y editores comerciales	ESRI ArcGIS 9.3 Server SDE en el último service pack, Manifold, FME	FME	ESRI ArcGIS 9.3 Server, ZigGIS para escritorio, Manifold, FME
Herramientas para web mapping - algo así como OpenLayers y otros entornos que soportan GML	Manifold, MapDotNet, ArcGIS 9.3 (en el último service pack), UMN MapServer ver, MapGuide Open Source (usando beta FDO driver)	UMN Mapserver, GeoServer, MapGuide Open Source	Manifold, MapDotNet, ArcGIS 9.3, UMN Mapserver, GeoServer, FeatureServer, MapGuide Open Source (usando beta FDO driver)
Funciones espaciales	Ambos OGC SFSQL MM y Geodetic custom (más de 70 funciones)	OGC MBR (bounding box functions) algunas funciones para relaciones espaciales, 2D solamente	Más de 300 funciones y operadores, no soporte geodésico, excepto para poing-2-point en funciones de distancia no indexadas, personalizado PostGIS para 2D y algo de 3D, algo de soporte MM en arreglos circulares y curvas compuestas
Indexado espacial (de acuerdo a algunos reportes, Oracle también usa algo de R-Tree y puede usar quadtree IBM DB2… o algo por el estilo	Si, 4 grillas multinivel (BOL says its B-Tree based)	R-Tree quadratic splitting - indexado solo existe para MyISAM	GIST - una variante de R-Tree
Soporte geodésico real, soporte para mediciones a lo largo de un esferoide. Hay que anotar que Oralce tiene soporte para esto	Si, con algunas limitantes	No	No
Hospedaje compartido	Mucho	Mucho	Algo, a menos que tengas un servidor dedicado sobre Linux / windows se puede lograr muchas cosas

Hoy ha sido el día que me ha correspondido exponer en el curso de catastro inmobiliario de Bolivia. El tema ha sido orientado a la reflexión de cómo elegir una herramienta informática para un desarrollo geomático.

Este es el gráfico que he usado, y mi enfoque ha sido el análisis del contexto en donde esperamos implementar la solución.

El asunto es que si se quiere elegir una simple herramienta para captura de datos se debe considerar aspectos que no tienen que ver solamente con la capacidad de hacer vectores, sino más bien la sostenibilidad que puede soportar en la medida que sea exigido por los usuarios que acceden a ésta desde diferentes niveles y la cantidad de usuarios que requerirán licencias.

Entre algunos criterios que hemos considerado, y cuyo peso podrá variar en función del contexto de país o alcances, entre otros se pueden considerar:

• Interoperabilidad
• Estándares OGC
• Curva de aprendizaje
• Velocidad vrs. Cantidad de usuarios
• Crecimiento modular
• Disponibilidad de interfases de programación (API)
• Costo integral

Luego hemos dividido el contexto geomático en al menos seis etapas y sopesado el nivel de importancia de los criterios anteriores en diferente momento. Cada una de las etapas puede seleccionarse un listado de características especiales que los usuarios o especialistas proponen y a estos se les da un peso a fin de evaluar de forma comparativa las ventajas y desventajas de las diferentes soluciones:

1. La etapa de construcción

En esta, básicamente se espera que la solución sea efectiva y práctica para la producción a alto nivel por parte de los técnicos que vienen de campo, digitalizan, limpian topología, integran a bases de datos e interactúan con imágenes o servicios de mapas.

2. La etapa de administración

En esto se considera, que los datos producidos puedan someterse a estándares tales como para ser aceptados dentro de una base de datos o un administrador de archivos versionados. Aspectos como sostenibilidad de formatos y API disponible son muy importantes. Y claro, las soluciones que se buscan a este nivel para manejo de bases de datos se espera que más que tener interfases atractivas, puedan tener un buen rendimiento para entornos multiusuario y capacidad de almacenar tanto datos tabulares como geometría e índices raster.

4. La etapa de Publicación, a este nivel se considera que las soluciones de construcción de datos hayan tenido posibilidades de transformación a estándares ogc y que las herramientas de servicio de datos tengan un nivel de personalización para que tanto se puedan servir datos como que también se vean artísticamente atractivos.

5. La etapa de mantenimiento, esto es un segundo nivel de construcción, en que se espera que las herramientas tengan la opción a poder personalizar su acceso para conservación de resultados versionados, almacenamiento histórico de cambios y de nuevo, facilidad en la construcción precisa. Si es posible la opción a hacer anotación gráfica bajo un activex que funcione en línea… mejor.

6. La etapa de respaldo, le he llamado así, pero en realidad es una etapa de repositorios de acceso, donde los usuarios dentro de la institución acceden, transforman datos, respaldan y generan nuevos productos. Aquí los requerimientos a la solución CAD/GIS apenas se van a la estabilidad de formato y capacidad de soportar versionado, mientras que las herramientas de manejo, que tengan mucha disponibilidad al desarrollo, normas de seguridad y funcionalidades cliente servidor.

3. La etapa de intercambio, este es un segundo nivel de la publicación, en la que se espera servir datos en formatos xml, gml u otros soportados por estándares ogc, productos que esperamos sean utilizados por otras soluciones geomáticas pero que también regresen modificados. Que decir, capacidad de pervertirse bajo estándares geofumados, incluida la opción de simplificación vectorial… sí, bien geofumados.

Aunque el principio es aplicar un test de características a diferentes soluciones en cada etapa del proceso, no debemos olvidar su contexto integral; así que hemos concluido con un ejercicio rápido en caso de tener un cliente importante, como un instituto de catastro en un país, que desea implementar un sistema completo para un entorno de unos 20 técnicos de producción CAD/GIS, 3 desarrolladores, 75 usuarios de intranet y consulta múltiple en línea (hemos omitido los costos de un Oracle de $30,000 anuales por procesador, el desarrollo informático, los equipos y la implementación):

Hacerlo con AutoDesk podría costar arriba de $180,000, con las limitantes en la fase de repositorios que debería complementar con otras marcas y el rendimiento de recursos de los equipos para servir datos de forma eficiente y bajo metas altas de postproceso.

Hacerlo con Bentley podría costar hasta $210,000, con las limitantes en la fase de intercambio, publicación tomada de los cabellos y algo en la curva de aprendizaje

Hacerlo con ESRI podría constar hasta $300,000, con las limitantes en la fase de construcción y repositorios, para lo que ocuparía complemento de otras marcas; aparte que en el camino podría surgir que se requieren 10 licencias de una extensión que vale $9,000

Hacerlo con Manifold podría costar $15,000, con las limitantes en la fase de construcción, curva de aprendizaje y necesidad de desarrolladores de primera (aunque en todos los casos hay que desarrollar mucho). También aclaro que hay otras soluciones de bajo costo, pero uso este porque lo he probado últimamente y me ha sorprendido.

En el peor de los casos me sobran $155,000 como para contratar la elaboración de buenos manuales y si juego con licencias runtime puedo tentar el ego del cliente.

Es curioso que casi el total se puede hacer con software libre, a puro GvSIG/Grass, Postgre, intelliCAD y otras hierbas si logro integrar un equipo de sistematización de procesos, desarrolladores geofumados y la credibilidad para vender el proyecto… si el cliente tenía considerado $700,000… le puedo pegar más duro pues entre mayor es la cantidad de usuarios se puede justificar más el software libre o de bajo costo.

En resumen, espero haber despertado su curiosidad por las soluciones libres y de bajo costo, aunque el tiempo era muy corto como para llegar más lejos. Hemos definido varias conclusiones breves:

• La tecnología adecuada es: “la que pueda ser sostenible” dentro del contexto global del desarrollo
• Nunca podrá existir una tecnología “buena para todo”
• El aspecto “económico” debe pensarse en función de “ciclo de vida de tecnologías” y su interoperabilidad
• Los procesos documentados (sistematización) extienden la el ciclo de vida de las tecnologías
• No todos están listos para el software libre, para iniciar es preferible las aplicaciones “comerciales”, con la experiencia se puede pensar en aplicaciones “de bajo costo“, con la osadía a las “libres” o “propias”