A utilização do KML como formato para exibição de dados geográficos na Web está se tornando cada vez mais presente. Tanto é verdade que em abril deste ano a linguagem foi aceita como padrão pelos membros da Open Geospatial Consortiu (OGC) como formato para exibir e representar elementos geográficos em 2D e 3D na Web.
Se você não ouviu falar da OGC, talvez você se surpreenda ao descobrir o quanto importante é esta organização. Entre os seus mais de 360 membros, há um grande número de universidades, institutos governamentais, agências de defesa, institutos de pesquisa, grandes empresas, etc. Sua função é o de implementar padrões para representação e troca de dados geográficos.
Sendo um padrão aberto, prevê-se que um leque enorme de organizações passarão a adotá-lo num futuro não muito distente e se torne o principal formato de representação de dados geográficos e de dados para mapas digitais para Web.
Organizações como Microsoft, ESRI, Autodesk e Bentley já haviam implementado suporte ao formato em várias de suas aplicações. O próprio Microsoft Virtual Earth já oferece suporte ao KML há mais de 1 ano e outros como GeoBusca, Leica Titan, Mapufacture, Yahoo Pipes, MapQuest, NASA WorldWind, Flickr e Platial já estão pensando lá na frente. Há muitas ferramentas que simplesmente se prestam a gerar KML a partir de bases já existentes e outras que se encaixam dentro do universo de conversores do tipo DXFtoKML, SHPtoKML, XLStoKML, 3DMAXtoKML, etc.
No entanto, da mesma maneira quando se cria um arquivo XML, é necessário que o KML seja um arquivo válido para que quando processado por um interpretador não gere erro. E aí fica a pergunta: como criar, editar e analisar um KML de acordo com as especificadas no Schema da OGC e testá-lo antes do mesmo ser aberto num browser?
XML significa Extensible Markup Language, ou seja, uma linguagem extensível de marcação. Linguagens de marcação compreedem todas aquelas que possibilitam a formatação de elementos por meio de tags e atributos como o HTML e XHTML.
Por ser extensível, o XML possibilita a criação de elementos e isso significa que você mesmo pode criar suas próprias tags. A possibilidade do desenvolvedor definir marcadores personalizados torna o documento mais inteligente, dando significado ao texto armazenado entre os marcadores. Enquanto a HTML apenas trata de especificar a formatação de uma palavra ou um trecho de texto, a XML trata de fornecer significado. Esse é o aspecto mais importante da XML.
O mais importante dessa possibilidade de criação de tags está na oportunidade de desenvolver linguagens de marcação a partir da XML. Já existem diversos padrões no mercado criados a partir dessa linguagem como MathM (Mathematical Markup Language), GML (Geographic Markup Language), MML(Medical Markup Language), GXL (Graph Exchange Language), AML (Astonomical Markup Language) CML (Chemical Markup Language), etc. E KML é uma delas.
KML é um XML geográfico. É uma linguagem de marcação voltada para representar graficamente objetos geográficos que inclui imagens, anotações sobre objetos e controles de navegação. KML pode ser considerado um padrão complementar aos padrões existente da OGC tais como GML, WMS (Web Map Service) e WFS (Web Feature Service) que não têm elementos de representação gráfica.
A versão atual do KML utiliza elementos geométricos derivados da versão 2.1.2 da GML como você verá no exemplo logo abaixo que inclui point, linearRing e polygon. No entanto, apesar das semelhanças, GML e KML apresentam propósitos diferentes. Enquanto KML tem como principal objetivo a representação gráfica de objetos geográficos, GML é uma linguagem voltada para exprimir e transportar feiçoes geográficas (como pontes, estradas, veículos, hidrografia, etc) entre sistemas por meio da internet.
Podemos observar abaixo como um polígono é representado de forma análoga nos dois formatos:
<Polygon>
<outerBoundaryIs>
<LinearRing>
<coordinates>…..</coordinates>
</LinearRing>
</outerBoundaryIs>
</Polygon>
<gml:Polygon>
<gml:outerBoundaryIs>
<gml:LinearRing>
<gml:coordinates>…..</gml:coordinates>
</gml:LinearRing>
</gml:outerBoundaryIs>
</gml:Polygon>
Repare que estruturamente falando eles são semelhantes e se tornariam idênticos se tirássemos o gml:, os namespaces seriam os mesmo. Como GML é antecessor a KML, é evidente algumas tags foram "emprestas" da GML.
KML foi desenvolvida para o Keyhole Earth Viewer que passou a se chamar Google Earth depois que a Google adquiriu a Keyhole Inc em 2004. O nome "Keyhole" é uma homenagem ao satélites de reconhecimento militar (leia-se satélite espião) comumentes chamados Key Hole.
KML especifica um conjunto de elementos (marcadores, imagens, polígonos, modelos 3D, descrições textuais, etc) que podem ser exibidos em um geobrowser (NASA World Wind, Google Earth, Virtual Earth), no Google Maps for Mobile ou outra aplicação que tenha suporte para tal. Cada objeto geográfico possui obrigatoriamente uma longitude e uma latitude que ainda pode incluir outros recursos como altitude, linha de tempo, inclinação e visão de câmera.
No entanto, como você percebeu, esses "recursos extras" só são exibidos no geobrowsers com recursos 3D.
De acordo com as especificações da W3C, se um XML não respeitar a estrutura a qual se espera, o processamento do documento não será executado e você receberá de brinde um erro de análise. Não é maravilhoso?
Um documento HTML pode ser criado com vários erros de sintaxe (como esquecer de fechar uma tag, por exemplo). Na maioria das vezes, os navegadores conseguem "corrigir o descuido" e apresentar o documento formatado. Entrentanto, uma das principais razões de imcompatibilidade entre os navegadores é que cada um tem implementado uma maneira própria de encontrar e "corrigir" esses pequenos erros. Com XML isso não é possível, é 8 ou 80. Ou está estupidamente certo ou não.
Nos browser, o processamento de um arquivo KML é semelhante ao dos arquivos HTML e XML. Assim como o HTML, o KML tem uma estrutura de tags com nomes e atributos usados para finalidades de exibição específicas. Dessa forma, podemos entender que Google Earth, Nasa World Wind ou qualquer outro cliente funcionam como um navegador de KML.
Se um documento não for válido, ele não será processado. E não se pode jogar nas costas do Google Earth todo a análise de documentos KML, isso não é nada produtivo.
Você pode criar um KML simples em qualquer editor de texto básico como o Notepad ou qualquer outro, entretanto esses editores de texto não oferecem recursos para verificação de erros. Ou seja, se você estiver editando um KML, ele não detectará nenhum erro até o momento de abrir o KML em um geobrowser e receber um erro de análise.
Obviamente que se você utilizar um editor com esquema de validação para XML, será perfeitamente possível analisar a estrutura dos seus KMLs usando o KML Schema.
Assim como o XML, o KML também tem um Schema. O XML Schema é uma alternativa ao DTD (Documento Type Definition). Ambos são modelos que têm o propósito de fazer com que os elementos, seus atributos e conteúdo estejam de acordo com o que se espera de fato. Assim, ao se adotar um determinado Schema ou DTD para os seus documentos XML, você terá uma ferramenta valiosa para a validação e checagem dos elementos usados. Atualmente verifica-se uma tendência ao uso do XML Schema ao DTD por ter mais recursos que o último.
O XML Schema define as regras de validação de um documento XML. Ou seja, define os blocos de construção permitidos em um documento XML, quais elementos se relacionam, quais atributos são permitidos, etc. Ele foi originalmente proposto pela Microsoft, mas se tornou um recomendação oficial do W3C em maio de 2001. Antes que você perceba nas próximas linhas, o XML Schema é referenciado como XML Schema Definition (XSD).
Para entender, em linhas gerais, como o Schema está inserido dentro de um documento KML, vamos analisar o cabeçalho de dois arquivos KML:
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns=http://www.w3.org/2001/XMLSchema
xmlns:kml=http://www.opengis.net/kml/2.2
xmlns:atom=http://www.w3.org/2005/Atom
xmlns:xal="urn:oasis:names:tc:ciq:xsdschema:xAL:2.0"
targetNamespace=http://www.opengis.net/kml/2.2
elementFormDefault="qualified" version="2.2.0">
<Placemark>
<extrude>1</extrude>
<name>Guarulhos - SP, Brasil</name>
<open>1</open>
<address>Guarulhos - SP, Brasil</address>
<LookAt>
<longitude>-46.53345</longitude>
<latitude>-23.463452</latitude>
<altitude>0</altitude>
</LookAt>
<Point>
<coordinates>-46.53345,-23.463452,0</coordinates>
</Point>
</Placemark>
</kml>
<?xml version="1.0" encoding="UTF-8"?>
<kml xmlns=http://earth.google.com/kml/2.1
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance
xsi:schemaLocation="http://earth.google.com/kml/2.1
http://code.google.com/apis/kml/schema/kml21.xsd">
<Placemark>
<extrude>1</extrude>
<name>Guarulhos - SP, Brasil</name>
<open>1</open>
<address>Guarulhos - SP, Brasil</address>
<LookAt>
<longitude>-46.53345</longitude>
<latitude>-23.463452</latitude>
<altitude>0</altitude>
</LookAt>
<Point>
<coordinates>-46.53345,-23.463452,0</coordinates>
</Point>
</Placemark>
</kml>
Repare que o cabeçalho de um KML nada mais é que um XML apontando para o seu Schema. O primeiro exemplo aponta para http://www.opengis.net/kml/2.2 e o segundo para http://code.google.com/apis/kml/schema/kml21.xsd.
Trocando em miúdos a história toda: o Schema nada mais é que um conjunto de regras que definem o documento de acordo com as especificações. Ele passa a ser importante no momento em que você estiver editando o arquivo pois é possível checar "on the fly" os erros de sintaxes que porventura possa acontecer.
O esquema XML completo para o KML está em http://schemas.opengis.net/kml/.
Para editar ou criar um arquivo KML através de um editor que possa realizar análise de sintaxe, é necessário que este apresente recursos para análise de um documento XML. Há muitos editores de XML com esquema de validação ou mesmo parses como libxml, Xerces e outros que podem nos ajudar a validar KML.
Como há um mini tutorial em vídeo no site do Google Earth Solidário que mostra como gerar, editar e analisar um arquivo KML usando o editor jEdit, nós o utilizaremos aqui por ser recurso com mais poder didático. Logo, se você não entender as explicações, basta assistir o vídeo. Os passos são os mesmos.
jEdit é um editor de texto gratuito escrito em Java com linguagem de macro integrada e funcionalidades que podem ser agregadas através de plugins. Ele roda em plataformas Windows, Mac OS X, Linux e outros sistemas. Este editor permite a verificação de erros à medida que você digita, garantindo a validação do seu KML de acordo com o esquema oficial da linguagem.
Os passos para instalação e configuração são:
Achou um tanto burocrático os passos aí em cima? Então você pode se guiar pelo vídeo abaixo que está com legendas em português. Essencialmente os passos são os mesmos.
Após configurar o jEdit, agora é só começar a trabalhar com KML. O vídeo abaixo mostra tintin por tintin como depurar e verificar os erros e é mais didático do que está escrevendo as etapas por aqui. Para acompanhar os exemplos que o vídeo utiliza, é necessário fazer o download dos seguintes arquivos:
Embora a versão atual do KML seja 2.2, os exemplos utilizam o schema 2.1, mas é um mero detalhe e não interfere na parte funcional da análise que é mostrar as operações de edição de um documento KML.
Há duas maneiras de validar o seu KML: online e offline. O que foi mostrado aqui em cima permite validar um documento no mesmo tempo em que se edita, é o modo offline. No modo online, é necessário fazer o upload ou apontar para uma URL o KML.
Pensando justamente em prover uma solução online, a canadense Galdos Systems, a criadora da linguagem GML, criou uma aplicação online, ainda versão beta, que permite validar qualquer KML compatível com a versão 2.2, o KML Validator.
O serviço permite analisar um KML localizado em um endereço na internet ou através de upload. O serviço analisa a estrutura, os erros e ainda aponta recomendações para alteração de elementos e atributos incorretos ou descontinuados de versões anteriores. Futuramente a Galdos pretende lançar serviços e ferramentas, sobretudo para desenvolvedores, voltados para criação e análise de KML.
O KML Validator não é o único serviço de validação que você pode contar, há também o http://feedvalidator.org/ que possuem funções semelhantes, mas é mais genérico.
Aparecido Leite é graduado em Engenharia Cartográfica desde 2005 pela Universidade Estadual Paulista (UNESP)/SP. Mora atualmente em Guarulhos/SP e é Web Writer focado em Geotecnologias e GeoWeb. Trabalha com PHP, WordPress, CSS, Tableless, documentação para SIG e gasta boa parte de suas madrugadas mexendo com Python, GeoDjango, Google Maps API, Virtual Earth SDK, KML e qualquer coisa relacionada a Web Mapping, Neogeografia e SIG.