La comunidad geoespacial necesita un lenguaje común para alcanzar la interoperabilidad real y a la vez mantenerse al día de los avances tecnológicos en las áreas de conocimiento relacionadas, adoptándolas de forma ágil y abierta sin perder de vista que el objetivo último de este lenguaje común es permitir que los proveedores de datos y servicios lleguen hasta los usuarios finales a través de aplicaciones útiles, usables, ricas y con un rendimiento excelente.
Por ejemplo, no es de recibo que desde que Google introdujera su revolucionario producto Google Maps en 2007, la comunidad geoespacial haya tardado 4 años en publicar un protocolo que permita servir mapas cacheados de forma estándar. En estos 4 años hemos sufrido colectivamente las limitaciones del protocolo WMS, con servicios de bajo rendimiento y mala disponibilidad y han proliferado soluciones ad-hoc, no estándar para paliar estos problemas.
La especificación de GeoServicios REST de Esri Versión 1.0 [1] fue desarrollada originalmente por Esri para proporcionar interoperabilidad entre ArcGIS Server y la comunidad de tecnologías de la información. La especificación de Esri había sido implementada de forma extensa por sus usuarios y partners durante más de 4 años.
En 2010 se liberó como una especificación abierta y no propietaria y desde entonces ha sido implementada por desarrolladores ajenos a la comunidad de usuarios de ESRI.
En 2011, ESRI ha presentado la especificación de la API REST de GeoServicios para su consideración como estándar OGC. Se ha formado un Grupo de Trabajo (Standards Working Group) para documentar la especificación de acuerdo a la política de espeficicaciones modulares y para atender los comentarios recibidos de la comunidad OGC y durante la revisión pública.
Ahora tenemos la oportunidad de dejar dogmatismos a un lado y centrarnos en dar servicio a los usuarios. La adopción de la API REST de ESRI como estándar por parte de OGC sería una oportunidad magnífica de avanzar el diseño de los protocolos estándar y dar un empujón de calidad y usabilidad a las aplicaciones geoespaciales que generamos.
Descubre más información sobre los GeoServicios REST de Esri Versión 1.0 [1] (http://www.slideshare.net/ESRI/jiide-rest-vs-ogc-sin-notas)
Publicado por Camino Ballesteros - Esri España
3 comentarios:
Solo quiero puntualizar que es inexacto que la comunidad que trabaja con IG haya tardado 4 años a partir de la aparición de Google Maps (2007)en publicar un protocolo estándar para servir mapas cacheados. En primer lugar, Google Maps apareció en el 2005; en segundo lugar, la primera contribución al estándar WMS-C definido por OSGeo data del año 2006.
Salud e interoperabilidad
Antonio F. Rodríguez (IGN)
Soy Javier Abadía, el autor de la presentación y del texto.
Tienes toda la razón. Se trata de un error por mi parte, mas grave si cabe porque para una versión más larga de la presentación que conté anteriormente en otro sitio incluía una tabla con la cronología correcta, incluyendo los hitos de Octubre 2004, Google compra Keyhole, Febrero de 2005, Google anuncia Google Maps, y Septiembre de 2006, se publica la recomendación WMS-C de OsGeo (que no estándar OGC)
Hola, Javier:
Efectivamente, WMS-C no es estándar OGC, es estándar OSGeo, además es un estándar abierto. Está claro que estándar es simplemente una solución técnica dominante en una porción o en todo un sector de actividad y WMS-C ha funcionado muy bien y ha desempeñado en un estupendo papel en muchos entornos.
Volviendo al tema de los estándares y su status, WMS aparte de estar muy implantado y a veces con buena QoS (el de Catastro y el de PNOA) es que es norma ISO (ISO 1928) y en la UE es práctiamente obligatorio para las AA. PP. por el Reglamento Europeo sobre servicios de visualización.
Salud e interoperabilidad
Antonio F. Rodríguez
Publicar un comentario