Home > geospatial - GIS > KML… ¿OGC compatible o monopolio de formato?

KML… ¿OGC compatible o monopolio de formato?

OGC standards La noticia anda por allí, y aunque hace más de un año se gestionaba que el formato kml fuera considerado un estándar… el momento en que se aprueba genera muchas críticas sobre las intenciones de Google de monopolizar un formato que tiene muy bien posicionado.  Que ahora se diga que el kml está en los OGC Standards, gener diversas opiniones.

Lo bueno

Los estándares son buenos, de no existir no podría sostenerse la interoperabilidad entre las diferentes herramientas tecnológicas principalmente las comerciales.  El objeto del Open Gis Consortium (OGC) es sistematizar estándares de datos espaciales que permitan crear protocolos de intercambio bajo esquemas documentados, tal como definiciones de entidades, relaciones y diccionarios de datos etc.

Al ver la lista de tecnologías que tienen varios de sus productos bajo el slogan «ogc standards» vemos que el esfuerzo ha sido muy bien apoyado, entre ellos AutoDesk, ESRI, Bentley, Intergraph, Leica, Oracle, CadCorp,  Mapinfo, Manifold… entre otros incluido Microsoft apenas el año pasado. Esta tabla refleja de las categorías sobre las cuales existen estándares OGC, incluido KML que sería un estándar de datos XML de geolocalización.

Hasta ahora ha sido complicado poder interactuar con un kml sin tener que importarlo (kml to dxf), y a la fecha a Google no se le ha antojado darle capacidad a su Google Earth para que abra directamente un .shp o un .dxf; el hecho que el kml sea estándar podría suponer que estas cosas podrían cambiar porque se asegura que la evolución sucedida no obedecerán al criterio loco de Google y entrará en juego la creatividad de la industria geoespacial y la comunidad en general.

De modo que no está mal, que Google suelte su formato kml y que bien que lo hace bajo el modelo «open», porque de esta forma se puede garantizar sostenibilidad a quienes invierten en desarrollos.  Esto supone la facilidad de crear aplicaciones sin tener que importar o transformar datos, y aunque parezca muy teórico, el criterio «open» aparte de ser colaborativo busca la neutralidad beneficiando a todos sin matricular los formatos con un programa particular… excepto a Google, claro.

Lo malo

El problema es que esta aprobación del formato por la OGC llega en un momento sensible en los grandes mercados de tecnologías; y nos referimos precisamente al momento en que Microsoft no pudo comprar Yahoo! quien ha decidido coquetear con Google.

Microsoft supera a Google en las herramientas de escritorio, Google supera a todos en el dominio sobre Internet, Yahoo! supera a ambos en la publicidad en línea. Microsoft le apuesta a las licencias cautivas, Google intenta promueve el uso de «sus» aplicaciones gratuitas, Yahoo! se muere cada segundo. Virtual Earth es cada día más atractivo, Google Earth tiene más cobertura, Yahoo maps…

Estas ligeras coyunturas son las que generan dudas si Google intenta soltar el kml al público, no porque le esté regalando algo al mundo sino porque quiere que todos trabajen en un formato que ya ha logrado posicionar… parecido cuando Microsoft ofreció .NET para cualquiera que quisiera desarrollar aplicaciones de escritorio, asegurando compatibilidad con estilo de llevarnos a tremendos niveles de sufrimiento y en busca de opacar a Java. También gran parte de la comunidad geoespacial ha menospreciado el potencial de el kml por sus limitadas capacidades a que ha llegado, pues aunque admitimos que Google Earth y Google Maps tienen admirables logros, el kml no hace más que mostrar pinches ubicaciones, porque el principio fue ese: simplicidad geográfica sobre xml y siempre con enfoque web.  Pero los desarrollos de las grandes herramientas de escritorio no se han preocupado más que por  importar y exportar el kml por esa loca costumbre de Google de clavarnos su API a como de lugar.

)GC Standards – Lo feo

…y esto podrá liberar la posibilidad de hacer desarrollos que se conecten a los datos de Google Maps sin tener que pasar por su API ? Hasta la fecha, si quieres hacer algo tienes que localizar a un ejecutivo de Google, contarle lo que quieres hacer, lo que quieres mostrar, como se verían los datos… y luego esperar que te den condiciones del nivel de resolución máximo a mostrar, donde debes poner el logotipo de Google y por supuesto, la obligación de comprar un Google Earth Enterprise Client al precio que se les ocurra o en caso extremo montar un Google Earth Pro sobre el servidor condicionado a sus caprichos.

También aunque aplaudimos que la alternativa abierta esté siendo apoyada por tecnologías bien posicionadas, como es el caso de Google y los miles de dominios que han desarrollado sobre su API, recordamos que no hace mucho MySQL, que recibió una gran colaboración de la comunidad, un día fue comprada por SUN por la modesta suma de un billón de dólares.  Y de eso los que ayudaron a resolver los bugs de cada versión no han visto un céntimo.

En la conferencia de Baltimore, ya me puedo imaginar el discurso de Mark Reichardt, CEO de OGC quien impartirá una plenaria llamada: «La visión de el OGC«, y en la que seguramente ofrecerán un altar a Google. ¿En qué terminará esta novela?

2 comentarios

  1. De acuerdo. Gracias por la respuesta que me parece muy acertada. Que Google someta el kml al estándar le daría más estabilidad respecto a cambios caprichosos.

  2. Hola,

    A ver no mezclemos churras con merinas, una cosa es que Google tenga un servicio de mapas sobre el que hacen un gran negocio, y otra cosa muy distinta es que OGC haya dado el espaldarazo al formato en el que Google transfiere gran parte de su información geográfica.

    Me explico: al definir KML como un estándard, nos aseguramos de que va a estar documentado, luego cómo lo usemos es muy diferente. Hace poco Google publicó una implementación libre de una biblioteca para trabajo con KML (que será tan buena como Google halla querido que sea, pero eso es otra guerra). En gvSIG ya hay soporte para KML sin utilizar esta biblioteca y se está trabajando en mejorarlo porque es una alternativa viable para transmitir información en un formato más o menos sencillo (lo que no quita que se pretenda dar soporte a GML 3.2, mucho más potente y probablemente dimensionado para otros usos). Poder traerte a gvSIG un KML publicado por quien sea, hacer análisis con él y volver a generar otro KML para publicarlo donde te dé la gana (sin pasar por los servicios de Google obviamente) es realmente interesante ¿no?

    En definitiva, que no hay que confundir la forma de hacer negocios de Google con la definición de estándares. Personalmente creo que es bueno que KML sea estándar ya que al menos nos aseguramos de que todos utilizaremos un mismo formato.

    Un saludo

Comentar

Su dirección de correo electrónico no será publicada.

Este sitio usa Akismet para reducir el spam. Aprende cómo se procesan los datos de tus comentarios.