Modelando entidades geográficas lineares: a classe Track

Uma vez que já foi modelada a classe Position, que armazena as coordenadas de um ponto no espaço geográfico, um próximo passo é modelar alguma das entidades que já vimos na análise dos formatos GPX e KML.

As duas entidades mais marcantes são as entidades pontuais (Waypoints, ou simplesmente Points), e também as entidades lineares (LineString, Track, TrackSegment, Polyline, etc.).

Optei por usar o termo Track porque, além de ser um termo comumente usado (GPS Trackmaker, Google My Tracks, objeto gx:Track do KML), a palavra track em inglês representa "pista", ou "rastro", e se presta bem para uma linha que pode ter sido tanto o caminho que algo ou alguém percorreu - ou pretende percorrer - quanto algum elemento linear no espaço terrestre, como um rio, uma estrada, uma ferrovia ou uma linha de transmissão.

Matematicamente, qualquer linha no espaço geográfico é uma sequência contínua de pontos, que pode ser definida por uma função paramétrica, onde a posição varia em função de um parâmetro (tempo, distância ao longo da linha, etc.). Como em geral as entidades têm complexidade arbitrária, com ângulos e reentrâncias, é conveniente decompor uma linha em uma sequência de segmentos. Assim, a linha é descrita pela sequência de segmentos, onde cada segmento por sua vez é descrito por seus pontos de controle.

Os segmentos podem ser de vários tipos: retas, arcos, geodésicas, seções cônicas, curvas de Bézier, splines ou NURBS. Assim, uma ferrovia provavelmente terá muitos trechos retos longos e curvas suaves, enquanto uma estrada na montanha terá uma alternância entre curvas abertas e fechadas, e um rio terá formas mais orgânicas e complexas, por exemplo.

Uma característica importante desses segmentos é que, em sua definição, eles contém um número finito de pontos de controle. Um segmento de reta, por exemplo, contém um ponto inicial e final. Uma curva de Bézier possui, além dos pontos inicial e final, também dois pontos de controle. Qualquer que seja o tipo de segmento, deve ser possível interpolar uma posição intermediária, de acordo com alguma fórmula que depende do tipo de segmento. No segmento de reta, que é o mais simples, o método usado é a interpolação linear.

Interpolação linear (à esquerda) e interpolação por curvas (à direita). A representação por segmentos de reta provoca uma perda de informação que é dependente da quantidade de pontos de controle, bem como do posicionamento dos mesmos ao longo da linha.

Tanto o formato KML quanto o GPX representam as linhas geográficas como "LineStrings", ou seja, linhas compostas por segmentos de reta concatenados, em que a posição final de um segmento é sempre a posição inicial do segmento seguinte. Portanto, e por uma questão de simplicidade, é essa a estrutura que adotaremos na classe Track.

É importante lembrar que, do ponto de vista conceitual, essa simplificação faz com que haja uma incerteza sobre a linha, já que não há informação nesses segmentos. Para isso, parte-se do pressuposto que a amostragem da linha foi feita com uma resolução adequada, e que portanto os detalhes e reentrâncias da linha estão mantidos na representação.

Por exemplo, para representar uma ferrovia com longos trechos retos, pode ser que seja adequada uma resolução de um quilômetro ou mais entre os pontos. Já para representar uma trilha sinuosa que sobe a encosta de um morro, uma resolução de 5 metros ou menos parece mais adequada. O fato é que, entre um ponto e outro, não há certeza sobre a posição real da linha, exceto pela convenção de que ela não sofra variações abruptas. Portanto, calculam-se os pontos intermediários via interpolação linear, com a suposição de que o erro será pouco significativo.

Já de posse de uma boa representação para os dados da classe, vejamos quais são as operações desejáveis, baseado nos usos frequentes das Tracks em aplicativos. São elas:

• Comprimento dos Segmentos: é uma sequência que mapeia cada posição da linha para a respectiva distância com relação à posição anterior, ou seja, é uma sequência dos comprimentos de cada segmento da linha. Por convenção, o primeiro valor é sempre zero;
• Comprimento Total: é a soma dos Comprimentos dos Segmentos;
• Perfil Altimétrico: é uma sequência de pares numéricos, onde cada par associa uma distância a uma elevação correspondente;

Por ora, temos uma modelagem inicial dessa classe, a ser implementada em postagens futuras. Os passos seguintes de desenvolvimento serão a implementação de leitores de arquivo para que se extraiam objetos "Track" a partir dos formatos KML e GPX, e possivelmente alguma forma simples de visualização (plotagem).

Formatos KML e GPX: reflexões sobre a natureza da informação geográfica - Modelo de dados de GPS, parte 2

Conforme comentado na postagem anterior, um componente importante da atividade "bicicleta + mapa + GPS" consiste na criação, edição e gerenciamento de arquivos contendo os dados que se pretende visualizar, armazenar e transferir entre o computador e o dispositivo GPS. Portanto, se considerarmos que os arquivos, enquanto forma de persistência, são um modelo de representação dos dados geográficos, que teoricamente permite reconstituir as características desses dados, uma forma possível de análise é, a partir da estrutura dos arquivos, inferir a natureza abstrata dessa informação. É o que me proponho a fazer nesta postagem.

"Faz sentido a conversão entre GPX e KML, ou vice-versa?"

 

Em se tratando de arquivos, de longe os mais difundidos são os formatos KML (Keyhole Markup Language) e GPX (GPs eXchange format). Mas algumas perguntas se fazem necessárias, especialmente considerando uma operação comumente oferecida por vários, senão todos, os softwares e sites de GPS: a conversão entre ambos os formatos. Essas perguntas são:

• Qual a natureza da informação armazenada no formato GPX?
• Qual a natureza da informação armazenada no formato KML?
• Será que ambos os formatos armazenam o mesmo tipo de informação? 
• Será que faz sentido falar em "converter" um formato em outro, ou então salvar um conjunto de dados geográficos em um ou outro formato?
• (e a pergunta que realmente importa) Considerando que ambos os formatos apenas representam informação, com finalidade de persistência e transferência, qual é a natureza primitiva dessa informação?

O formato GPX

Não consegui encontrar informações sobre a história do formato, mas de acordo com a home page, ele se propõe a ser um container justamente para o tipo de informação utilizada pelos aparelhos de GPS, seja a informação que se cria ou envia para o aparelho ao planejar a atividade, ou aquela que o aparelho cria durante a execução da atividade.

Ainda segundo a home-page:

"O formato GPX é um formato XML leve para transferência de dados de GPS (waypoints, rotas e tracks) entre aplicativos e serviços na internet."

O formato GPX tem três tipos fundamentais de informação: Waypoint, Track e Rota. Esses têm equivalência direta com as entidades de trabalho dos aparelhos de GPS da Garmin, e com a maioria dos outros aparelhos:

• Um Waypoint representa um ponto de interesse, contendo ao mínimo as propriedades de Latitude e Longitude, podendo conter Elevação (Altitude) e Estampa de Tempo (timestamp, datetime), e podendo ainda, dependendo do contexto, conter Nome, Descrição, Símbolo, e outras propriedades. Tipicamente, um Waypoint pode ser criado pelo usuário a partir de sua localização atual, ou então criado no próprio aparelho ou em um computador a partir de uma outra localização desejada em um mapa de referência;
• Um Track representa uma sequência de Trackpoints. Cada trackpoint é um sub-tipo de Waypoint (ou vice-versa), de forma que o Track representa a trajetória percorrida, ou seja, é um registro de eventos que foram ocorrendo ao longo do tempo;
• Uma Rota (Route) é uma sequência de Waypoints, servindo conceitualmente como uma sugestão de trajetória que o usuário poderá percorrer, utilizando a rota como um auxílio para a navegação sequencial entre seus waypoints. Ao contrário de um Track, que representa o fato passado, a Rota representa a possibilidade futura.

Quando eu disse acima que Trackpoints são subtipos de Waypoints, "ou vice-versa", isso traz logo uma primeira "dúvida": devem os tipos-base servir como definições de propriedades básicas, que deverão ser extendidas por sub-tipos - e nesse caso os subtipos fariam MAIS do que os tipos-base - ou pelo contrário, devem os tipos-base descrever completamente todas as propriedades possíveis, e os sub-tipos então restringiriam o comportamento?

Tomando o exemplo entre as duas entidades, a impressão que tenho é a seguinte: tipicamente, o Waypoint é um ponto avulso, ou seja, um elemento em si mesmo, com Nome, Descrição, Estilo, e outros metadados. Ele foi criado como ponto, e é visto como ponto e manipulado como ponto, dimensionalmente falando. Um conjunto de Waypoints não é necessariamente ordenado, mas se for, constitui uma Rota.

Por outro lado, um Trackpoint raramente será identificado de forma isolada, pois ele só "conta" como Trackpoint se for pertencente a uma Track. A Track, nesse caso, é que possuiria as propriedades Nome, Descrição, Estilo, e uma determinada propriedade seria a sequência de Trackpoints (o que, em XML, pode ser representado por um elemento do tipo "trackpoint collection", ou diretamente colocando os trackpoints em ordem sequencial entre as tags do elemento Track).

Seja como for, a vocação - e a própria capacidade-limite - do formato GPX são entidades relacionadas aos aparelhos de GPS: pontos, linhas, sequências de pontos.

O formato KML

Enquanto o GPX aparentemente é um formato que surgiu de forma despretensiosa e "foi ficando" até se tornar o padrão de-facto para dados GPS, praticamente sem modificações, o KML é um formato que evoluiu de forma bem mais consistente e "encorpada".

O Keyhole Markup Language foi criado pela empresa Keyhole, Inc. para uso em seu produto Keyhole Earth Viewer. A empresa foi fundada em 2001 e comprada pelo Google em 2004, e o Keyhole Earth Viewer acabou rapidamente virando o Google Earth, lançado em 2005. O formato foi tão bem sucedido que acabou sendo enviado ao ISO/OGC (Open Geospatial Consortium) em 2008, e atualmente a especificação oficial é dada pelo ISO/OGC, que adotou o formato como um de seus padrões, mantendo o compromisso de trabalhar cooperativamente com o Google e com a comunidade de usuários para que o formato evolua de forma consistente, padronizada e pública.

Abaixo, podemos ver o diagrama do formato KML. Em preto estão os elementos padrão definidos pelo ISO/OGC, e em vermelho estão as extensões utilizadas pelo Google Earth.

Esquema do formato KML (fonte: Google KML Reference)

Uma análise dessa estrutura permite intuir a natureza da informação que o KML se propõe a representar, que corresponde à descrição encontrada na página do ISO/OGC:

"KML é uma linguagem XML focada em visualização geográfica, incluindo anotações de mapas e imagens. Visualização geográfica inclui não apenas a apresentação de dados geográficos no globo, mas também o controle da navegação do usuário no sentido de para onde ele deve ir e para onde ele deve olhar."

Assim sendo, a própria definição acima já cria um marcante contraste entre os superficialmente similares formatos GPX e KML. Enquanto o primeiro é somente um container para uns poucos tipos de elementos geográficos associados à navegação por GPS, esse último é, além de um container, uma definição sobre a forma como esses dados devem ser visualizados, e potencialmente até um registro sobre a intenção de uso e visualização dos dados contidos no arquivo.

Voltando à análise da estrutura do KML, vejamos de que forma podemos particionar alguns dos elementos por categoria:

• Estruturação do arquivo: Document, Folder;
• Definições de aparência dos elementos: Style, SubStyle, StyleSelector, etc.;
• Definições de elementos vetoriais: Geometry (e todos os subtipos);
• Definições de intenção de visualização: Tour, TourPrimitive e subtipos, PlayList;
• Definições de elementos raster: Overlay e subtipos;
• Referências externas: NetworkLink

Dos elementos citados acima, os únicos que contêm uma correspondência direta com o GPS são os tipos Geometry:

• gpx:Track -> gx:Track (e em menor grau kml:LineString, que não possui timestamp);
• gpx:Waypoint ->  kml:Point;
• gpx:Route -> não tem correspondência em KML.

Discussão

Algumas das perguntas feitas no início já parecem ter uma resposta após essa análise dos tipos de informação que cada arquivo se propõe a representar.

Diria que, de modo geral (ou seja, para as aplicações mais comuns dos arquivos pela comunidade de ciclistas e aventureiros em geral), NÃO faz sentido falar na conversão de um formato em outro, ao menos não se quisermos uma conversão sem perdas. Acho problemático que isso não seja explicado com mais clareza nas inúmeras documentações de software, postagens e conversas a respeito que já encontrei pela internet afora, e também usando os aplicativos e plataformas.

De modo geral, também, me parece que ambos os formatos têm tido um uso qualitativamente distindo, embora essa distinção não seja explícita.

• O KML tem mais vocação para representar informação estática, e de modo geral uma informação sobre o terreno, na forma de estradas, pontos de referência, opcionalmente imagens (overlays), e representação / visualização de elementos que fazem parte do globo terrestre, de sua estrutura e de sua paisagem. Seriam os elementos típicos estudados pela cartografia.
• Já o GPX é orientado a objetos móveis, sejam veículos, pessoas, animais, ou qualquer outra coisa que se movimente enquanto tem sua trajetória registrada por um GPS. Mesmo os elementos prescritivos, como Rotas ou Waypoints, são orientados à navegação, e não à cartografia.

O Google, através de suas extensões ao KML, define o tipo gx:Track, que é um precedente no sentido de representação de trajetória, mas com uma estrutura bem diferente do elemento gpx:Track. Embora isso aumente a compatibilidade entre ambos os formatos, no sentido de permitir ao KML armazenar informações de trajetória, essa funcionalidade ainda não é oficial (não foi incorporada pelo ISO/OGC, existindo somente como extensão do Google), e não há sinais de que venha a substituir o GPX em vocação ou em popularidade de uso, pelo menos não nos próximos anos.

Por outro lado, o elemento <time> nos Trackpoints do GPX é opcional, o que permite armazenar apenas a geometria de um trajeto (que dessa forma se torna uma descrição geométrica estática), mas o KML parece ser uma melhor opção para isso, e provavelmente vai continuar sendo.

Implicações para usuários de GPS (em ciclismo ou outras atividades)

Para quem utiliza a combinação GPS + Mapas Online = Passeios Divertidos, seja em nível básico ou avançado (incluindo programação), as recomendações seriam as seguinte:

• Use o KML para criar dados geográficos sobre o terreno, suas estradas, pontos de referência, dados esses que servirão para o planejamento de um passeio, ou para servir como referência dos aspectos geográficos de uma região. Em geral, a forma de criação dessas informações é a edição direta com o mouse sobre um mapa de referência, ou a seleção de entidades já prontas em um mapa geral contendo entidades geográficas, para que sejam armazenadas no arquivo KML;
• Use o GPX para salvar e transferir o registro de uma atividade, ou seja, para descrever a trajetória do deslocamento do veículo ou da pessoa, da forma como ela ocorreu no espaço e no tempo, tendo sido registrada pelo aparelho GPS. Opcionalmente, o GPX pode ser usado para transferir dados no PC de volta para o GPS, embora haja um número crescente de dispositivos (especialmente smartphones) que reconhecem e carregam informações de arquivos KML para exibição como mapas de fundo durante a navegação. Também é relevante lembrar que, no caso de atividades esportivas em que a intenção é reproduzir um desempenho anterior na forma de um "virtual partner", o GPX é um formato conveniente para enviar uma atividade previamente realizada de volta ao aparelho (embora em geral isso seja feito em algum outro formato de arquivo proprietário).

Extrapolação do modelo de dados: além dos formatos de arquivo

 O raciocínio seguido nesta postagem foi semelhante a uma "engenharia reversa", tentando intuir a estrutura da informação geográfica a partir da análise da estrutura de dois formatos de arquivo populares.

Seria ingênuo pensar que essas duas estruturas de dados descrevem completamente tudo que há para descrever. Seria ingênuo pensar que a descrição pura e simples de algo seja suficiente para revelar sua natureza característica, e seria ingênuo tentar identificar qual formato de arquivo é "o melhor", ou "o mais completo".

O trabalho com arquivos, e mesmo o trabalho em aplicativos ou sites ou bancos de dados, pressupõe um modelo de dados, e por definição "o modelo" é apenas uma simplificação do "objeto" propriamente dito. Formatos de arquivo são formas de representar entidades geográficas para persistência e transferência da informação. Modelos de objeto (não tratados nesta postagem) são formas de representar a estrutura e o comportamento dessas entidades em software, de forma que sobre elas se possam realizar operações e produzir novas informações, que sejam interessantes e úteis a um determinado contexto de aplicação.

Na próxima postagem, a ideia é debater sobre a natureza da informação geográfica, principalmente no contexto da atividade ciclística, mas com ideias e considerações aplicáveis a qualquer tipo de deslocamento geográfico. Me parece que apenas com um modelo conceitual que seja consistente, relevante, robusto e intencional, pode-se garantir um modelo de dados - necessariamente uma representação simplificada - que permita a qualquer aplicação um tratamento adequado dessa informação, através de operações e visualizações que capturem a essência não só dos elementos geográficos, mas também de seu significado para as pessoas que por eles se referenciam.