<?xml version="1.0" encoding="UTF-8"?><!-- generator="wordpress/wordpress-mu-1.2.4" -->
<rss version="2.0" 
	xmlns:content="http://purl.org/rss/1.0/modules/content/">
<channel>
	<title>Comentarios en: KML&#8230; &#191;OGC compatible o monopolio de formato?</title>
	<link>http://galvarezhn.cartesianos.com/2008/04/15/kml-ogc-compatible-o-monopolio-de-formato/</link>
	<description>Un espacio para fumarse un buen café con sabor espacial</description>
	<pubDate>Thu, 20 Nov 2008 17:41:39 +0000</pubDate>
	<generator>http://wordpress.org/?v=wordpress-mu-1.2.4</generator>

	<item>
		<title>Por: XuRxO</title>
		<link>http://galvarezhn.cartesianos.com/2008/04/15/kml-ogc-compatible-o-monopolio-de-formato/#comment-987</link>
		<author>XuRxO</author>
		<pubDate>Tue, 15 Apr 2008 10:46:35 +0000</pubDate>
		<guid>http://galvarezhn.cartesianos.com/2008/04/15/kml-ogc-compatible-o-monopolio-de-formato/#comment-987</guid>
		<description>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 &lt;b&gt;cómo&lt;/b&gt; lo usemos es muy diferente. Hace poco Google publicó una &lt;a href="http://libkml.googlecode.com/" rel="nofollow"&gt;implementación&lt;/a&gt; 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</description>
		<content:encoded><![CDATA[<p>Hola,</p>
<p>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.</p>
<p>Me explico: al definir KML como un estándard, nos aseguramos de que va a estar documentado, luego <b>cómo</b> lo usemos es muy diferente. Hace poco Google publicó una <a href="http://libkml.googlecode.com/" rel="nofollow">implementación</a> 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?</p>
<p>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.</p>
<p>Un saludo</p>
]]></content:encoded>
	</item>
</channel>
</rss>
