Te invitamos a visitar la segunda versión, publicada en mayo de 2009, para ello haz click en este enlace.
Los clientes ligeros web para SIG son aplicaciones en Internet que se encargan de visualizar información geográfica y permiten su manipulación a través de herramientas básicas de navegación y análisis.
En términos generales, los clientes ligeros web poseen baja capacidad de análisis por su misma esencia, pues no soportan la lógica del programa, sin embargo, es cada vez más frecuente realizar procesamiento de información geográfica en línea, con ayuda de programas en el servidor que se encargan de procesar los datos, lo cual ha ayudado a ampliar el rango de usuarios que se enfocan en este tipo de soluciones.
El Open Geospatial Consortium (OGC) ha promovido el uso de estándares para servicios web de mapas que han ayudado a establecer un marco común de trabajo para acceder a información geográfica en la internet (Web Map Service, Web Feature Service, Web Coverage Service), presentarla por medio de estilos (Style Layer Descriptor), filtrarla (Filter encoding), almacenarla, transportarla (Geography Markup Language y Keyhole Markup Language) y procesarla (Web Processing Service).
Los clientes ligeros web se han beneficiado también de tecnologías como AJAX (Asynchronous JavaScript And XML) acercando a los usuarios que en principio veían la navegación de mapas en internet como un ejercicio desgastante y poco agradable. Las consultas de información ahora son más transparentes, permitiendo que los datos viajen del cliente al servidor y se retornen resultados sin que se paralice la navegación. API's (Interfaz de Programación de Aplicaciones) basadas en Javascript han sido dispuestas para construir clientes ligeros web para SIG, dejando que el navegador interprete sentencias y se encargue casi por completo de la interacción con el usuario, lo cual agrega rapidez en operaciones tan complejas como la edición de geometrías en línea.
Existen varios proyectos para construir clientes ligeros web para SIG. GeoTux ha elaborado la siguiente comparación basándose en proyectos de software libre y open source. La comparación se presenta en tres partes para facilitar su visualización:
- Descripción general: Se da una introducción a cada proyecto.
- Características técnicas: Se presentan datos técnicos de los programas para facilitar una descripción detallada.
- Enlaces de interés: Comprende una captura de pantalla que muestra una interfaz elaborada con cada proyecto y direcciones de acceso a páginas de interés de los mismos.
La comparación se ha enfocado en los siguientes clientes ligeros web, seleccionados por su reconocimiento en el área de SIG en internet:
| CartoWeb | Chameleon |
Flamingo |
Fusion |
| iGeoPortal |
Ka-Map | Mapbender | MapBuilder |
| MapFish | msCross |
p.mapper | OpenLayers |
| TimeMap |
CONVENCIONES: Ventaja / Desventaja
COMPARACIÓN: (Por favor evita ver la comparación en IE6 o IE7 pues parece que aún no puede trabajar bien con estilos, puedes eso si, emplear un navegador libre, como Mozilla Firefox, Opera o K-Meleon entre otros, en los cuales se ha probado la correcta diagramación de las tablas)
| [1] Compatible con BSD. [2] Compatible con GPL. [3] Actualmente se trabaja sobre traducciones a varios idiomas: Sueco, español, búlgaro, polaco, italiano, francés, checo, esloveno, entre otros. [4] Documentación incompleta. [5] Aunque OSGeo no lo apoya como proyecto oficial, le da alojamiento a sus listas de correo y a su Trac. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| [1] Solo soporta puntos para el WFS. [2] Se ejecuta mediante un applet de Java. [3] Actualmente se trabaja en un cliente catálogo de metadatos empleando GeoNetwork. (Ver: https://trac.mapfish.org/trac/mapfish/wiki/Proposals/Catalogue) [4] No tiene listas de correo propias. Las listas de correo son del proyecto Deegree. [5] Tiene listas de correo para: Usuarios, desarrolladores, commits, anuncios, tilecache y trac, entre otras. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
NOTAS CON RESPECTO A LA COMPARACIÓN:
- En el proceso de recolección de información se buscó la documentación de cada proyecto en su página oficial, extrayendo los datos de interés y posteriormente se escribió a las listas de correo de los proyectos (exceptuando MapBuilder, por su terminación; msCross, por su no existencia; e iGeoportal, porque la lista de correo no es propia del proyecto). Se recibió respuesta de los siguientes proyectos: Chameleon, Fusion, Ka-Map, MapBender, MapFish, OpenLayers, quienes validaron la información recogida e hicieron aclaraciones y sugerencias.
- Las celdas en blanco indican datos que no se pudieron recoger.
- El apoyo de OSGeo se da cuando el proyecto se gradúa del proceso de incubación, por lo cual los proyectos que están en la incubadora no son proyectos oficiales de OSGeo y no reciben su soporte. (Ver: http://www.osgeo.org/node/343)
- El parámetro "Formatos de datos soportados" se refiere a los datos que el cliente web puede cargar sin uso de un servidor de mapas.
En la comparación colaboraron los usuarios: Geowarrior, remyalex, samtux y tuxman.
Debido a la constante innovación e implementación de tecnologías en este tipo de proyectos, esperamos mantener actualizada la comparación cada seis (6) meses.
Tú puedes colaborar
Si ves algún error u omisión en la comparación por favor dínoslo y con prontitud haremos la corrección. Si conoces algún otro cliente ligero web y te gustaría verlo en la comparación escríbenos para investigarlo y anexarlo.
LICENCIA:
Este artículo puede ser utilizado bajo la licencia "Attribution 2.5 Colombia", obsérvala en este enlace: http://creativecommons.org/licenses/by/2.5/co/
REFERENCIAS:
- Página web oficial de cada proyecto. (Ver parte 3 de la comparación, Enlaces de interés)
- Emanuel Schütze. Current state of technology and potential of smart map browsing in web browsers. Alemania. Junio de 2007. Disponible en la URL: http://www.smartmapbrowsing.org/html/index_en.html
- Open Source Geospatial Foundation (OSGeo). Página oficial: http://osgeo.org
- Estilos CSS para tablas: http://icant.co.uk/csstablegallery/index.php
- Banderas del mundo: http://www.33ff.com/
- Wikipedia. Definición de cliente ligero: http://es.wikipedia.org/wiki/Cliente_liviano
Comentarios
Mi pregunta es que para una persona que inicia con estos clientes (en este caso se ha tocado algo de mapserver a pelo y me de que va un poco), cuál sería el más recomendable para realizar un servidor de mapas lo más agradable posible(teniend o en cuenta los que no se nada sobre php y javascript).
Gracias...
Con respecto a PHP y Javascript, bueno, seguro vas a tener que comenzar a emplear al menos uno de los dos lenguajes cuando empieces a configurar y a personalizar tu aplicación. Dependiendo de los requerimientos que tengas podrás elegir uno u otro cliente. Por ejemplo, Cartoweb, Ka-Map, MapBender y p.mapper vienen con varias funcionalidades listas para usar pero puede que tan solo necesites navegación en el mapa, así que te bastaría con OpenLayers :o.
Te recomiendo entonces que definas muy bien las funcionalidades que necesitas y que luego observes la documentación de los proyectos para que conozcas de primera mano qué tanto puede suplir un cliente tus requerimientos o qué tanto tendrás tú que poner en cuanto a desarrollo.
Saludos.
La información ofrecida en este artículo es muy interesante y completa además.
Tengo inquietudes acerca de pmapper, apenas empiezo a desarrollar en este framework, pero tengo entendido que existen 3 modos de ejecución entre los cuáles se encuentran CGI, MapScript y WebServices, dónde este último permite combinar los recursos con lenguajes como JAVA. Es óptimo realizar aplicaciones en este modo? y dónde puedo encontrar información detallada de desarrollo en esta modalidad.
Existen componentes en PHP como NuSOAP, para consumir e incluso crear webservices; aquí hay algunos ejemplos:
www.scottnichol.com/nusoapprogwsdl.htm.
www.ferdychristant.com/blog/articles/DOMM-6J2QFF.
Lo "malo" de los webservices, es que la información o métodos que implementan, quedarán dispuestos en la web, por tanto, son tan seguros como el ambiente o la red en la que se publiquen, a menos que implementen certificados digitales (método que considero un poco complejo).
Espero te sirva.
Muchas gracias por la respuesta. Voy a revisar los links que me envías. Mi inquietud está orientada a usar recursos diferentes a php (que hasta el momento es el lenguaje dónde se han desarrollado el mayor número de librerías de desarrollo) como JAVA, que es un lenguaje dónde ya tengo alguna experiencia en desarrollo web con Java Server Faces (JSF), lo ideal sería ahorrar tiempo de entrenamiento en PHP y desarrollar directamente con JAVA eso sí de acuerdo a las especificacione s que ofrece MapScript por ejemplo. Lo que no sé por el momento es si es recomendable desarrollar con esta metodología o mejor me dedico a trabajar directamente con php y allí lo combino con otros lenguajes que necesite.
Muchas gracias por la información. í‰xitos.
Recientemente trabaje en un proyecto desarrollado bajo el estándar JSF integrado con openlayers, en este proyecto trabajamos con el framework de IceFaces y se obtuvieron resultados aceptables( eso si debe tener cuidado con las librerías de java script con las etiquetas enriquecidas que ofrecen los distintos frameworks JSF ).
Para comenzar a implementar soluciones como estas es necesario, tener claro la diferencia en entre la programación que se hace en el cliente (pagina web) integrándola con el framework o cliente ligero para realizar tu mapa, la programación que se haga en la aplicación del lado del cliente con las etiquetas JSF y lo que se desarrolle del lado del servidor (si ha trabajado con JSF habrá notado la facilidad de intercambiar información entre etiquetas de la pagina web y los BackingBean del lado del servidor) . Entendiendo esto es posible que la solución que busque vaya enfocad a realizar su página web con etiquetas jsf y la aplicación web geográfica con html para que pueda trabajar con OpenLayer e intercambiar información con etiquetas JSF. Y eso si trabajando con servicios OGC (WMS...u otro, si estaba trabajando con pmmaper seguramente estará trabajando con mapserver) proporcionados por un servidor de mapas haciendo peticiones desde el cliente. ( Otra cosa seguramente se perderá lo que puede hacer con mapscript)
Aunque claro tienes otras opciones para trabajar directamente con etiquetas desde tu pagina Web ejecutadas en MapFaces, aunque los proyectos no son aún muy maduros puede probarlos, para ver si se acomodan a los requerimientos de su aplicación (eso sí pienso yo se perdería la flexibilidad que ofrece openlayers).
geofaces http://code.google.com/p/geo-faces/
MapFaces http://mapfaces.codehaus.org/
En esta url se peude encontrar mas informacion http://urewera.boarsnest.net/MapScript/ o en http://ms.gis.umn.edu:8081/ms_plone/docs/howto/javamapscript :-
Muchas gracias por la información, muy completa. ;-). Voy a implementar dichos componentes.
Exitos y gracias de nuevo.
de antemano muchas gracias.
Lo que buscas se trata en el WPS del OGC, que te permite definir parámetros y llamar procesos espaciales que corren en el servidor.
Para GRASS hay muchos adelantos que datan de años atrás:
Por ejemplo, para GRASS7 se espera una utilidad para obtener la descripción de cada proceso en XML conforme a WPS.
Te recomiendo que mires la wiki de GRASS:
grass.osgeo.org/wiki/WPS
Aquí encuentras una implementación de WPS con Python enfocada a GRASS:
pywps.wald.intevation.org/
Y no dejes de revisar el trabajo de 52º North al respecto.
Saludos.
la idea que tengo es realizar una aplicacion RIA que permita ejecutar comandos o realizar procesos a un servidor de grass mediante WPS.
ya he averiguado acerca de estos tipos de sevicios pero lo que me falta es definir cual va ser mi lenguaje a utilizar ya que manejo java, no se si sea factible realizarlo desde este.
te agradesco tu orientacion ya que he visto cosas muy interesantes como jgrass para udig, no se si sea el camino correcto para lo que quiero hacer.
de antemano muchas gracias.
Bueno, no se si viste esta página: http://pywps.wald.intevation.org/gallery/index.html
Hay varios ejemplos de implementación de WPS (GRASS) con OpenLayers (Javascript) como cliente web, en ese sentido podrías mirar proyectos como GeoExt o MapFish para elaborar la interfaz de la aplicación usando como base ExtJS (Javascript).
52º North tiene planeado liberar un cliente OpenLayers WPS próximamente: http://www2.52north.org/pipermail/geoprocessingservices/2010-March/000838.html
Te puede interesar ZOO project: http://www.zoo-project.org/
Pretenden crear una plataforma Open Source para servir WPS y consumirlos con un cliente basado en OpenLayers, sin embargo, no parece haber mayor información en su página web.
Por el lado de Java, revisa cómo se comporta el cliente de Deegree (no es RIA) con WPS y mira MapFaces (RIA), tal vez te sirva por el lado de los componentes JSF.
Saludos.
ya estoy en la configuracion de pywps con grass , tenia unos problemas con unas librerias de xml pero ya lo solucione.
lo que no he entendido es como se envian las peticiones desde el navegador a pywps, hay una parte del manual que habla de un directorio cgi-bin , creo que por ahi es la cosa , pero no se como configurar esa parte.
tambie vi que para realizar los procesos que llamo desde el navegador tengo que tener estos en la carpeta processes y en el archivo _init_.py agregarlo en la lista para que puedan ser utlizados, si esta bien esta parte??.
si me puedes ayudar con la configuracion del cgi-bin de apache para poder ejecutar lo procesos desde el navegador.
la configuracion la estoy realizando en ubuntu 9.1
muchas gracias.
tenia problemas era con permisos, ahora seguire configurandolo.
muchas gracias.
Suscripción de noticias RSS para comentarios de esta entrada.