Implementando a posição geográfica com a classe Position

 As primeiras postagens deste blog se mantiveram bastante abstratas, mas algumas modelagens prévias foram necessárias para construir um modelo composto por elementos bem fundamentados.

Já foi argumentado que, para aplicações de uso pessoal (não profissionais), o datum WGS84, usado pelo sistema GPS, é a escolha óbvia, e que no caso de visualização em mapas, a Projeção Esférica de Mercator (usada pelo Google Maps e similares) é o padrão de facto.

Ambos os sistemas de referência (datum 3D e projeção 2D) descrevem o espaço em que os fenômenos geográficos são posicionados, e portanto a partir daqui podemos nos ocupar da definição da posição propriamente dita.

A importância da posição na informação geográfica é muito bem discutida no documento "Abstract Specification, Topic 5 - Features", onde lemos o seguinte:

• "As coordenadas de uma entidade geográfica de interesse (feature) são o conjunto de pontos suficientes para a construção geométrica da extensão geo-espacial dessa entidade";
• "O Mundo Dimensional (aquele definido por coordenadas) é o último nível de abstração geo-espacial "genérica" do Mundo Real. O próximo nível é chamado Mundo do Domínio, já dependente de um domínio de implementação";
• "Cada instância de uma entidade pode ser considerada a materialização de um modelo (classe) da entidade, tendo seus atributos preenchidos com os valores específicos daquela instância".
• "Recomenda-se que entidades com extensão espacial sejam modeladas por formas geométricas primitivas simples".
• "Entidades geográficas são definidas por seus atributos, um dos quais consiste em alguma Geometria. Por sua vez, geometrias são constituídas por um conjunto de Pontos dispostos e conectados de determinada forma".

Vemos então que o Ponto, na forma de uma coordenada em um sistema de referência, é a unidade elementar de descrição das propriedades espaciais de qualquer entidade geográfica.

Em outro documento, o "Abstract Specification, Topic 1 - Feature Geometry", temos um extenso modelo UML que trata da representação geométrica de entidades. Pretendo abordar maiores detalhes sobre outras entidades no futuro, mas no contexto de posições representadas por pontos, o esquema geométrico define três classes importantes:

1. A classe DirectPosition: tem a responsabilidade de armazenar os valores de coordenadas de uma posição dentro de determinado sistema de coordenadas. Apresenta três propriedades: coordinate, que é uma sequência ordenada de valores numéricos; dimension,  que retorna o número de dimensões do sistema de coordenadas; e coordinate_system, que retorna o sistema de coordenadas ao qual a posição pertence;
2. A classe GM_Point: é uma sub-classe de GM_Object, contendo uma instância de DirectPosition;
3. A classe GM_PointRef: é uma referência a algum outro ponto pré-existente, no sentido de permitir que um mesmo GM_Point possa participar de mais de uma feature, evitando redundâncias.

Coordenada: um tipo diferente de "par ordenado"

Uma consideração importante na definição de uma "posição geográfica" é a forma como os valores que compõem a coordenada são definidos. Um exemplo pode ser extraído dos próprios formatos KML e GPX, vistos anteriormente: a diferença com que a informação é armazenada em cada um dos formatos:

• No formato KML, a coordenada é uma string de caracteres, sem espaços, onde cada valor é separado por vírgula, especificamente na ordem "longitude,latitude,[elevação]", onde a elevação é opcional;
• No formato GPX, não há "ordenada", pois cada Trackpoint possui um atributo chamado Latitude, e outro atributo chamado Longitude, não importante a ordem com que eles são declarados. Além disso, a elevação é um elemento adicional, que pode ou não estar presente.

Assim sendo, temos um caso (KML) em que os valores de cada eixo do sistema de coordenadas são definidos somente pela ordem. O que chama a atenção é que, no formato KML, a longitude vem antes da latitude (GML Coordinate Reference System, LonLat84_5773), o que é o contrário do que costuma ocorrer em vários outros esquemas (e aliás, cria dificuldades enormes para "copiar e colar" strings representando coordenadas...).

Quanto a isso, diversas normas ISO estabelecem a forma recomendada de uso de uma coordenada:

• Entende-se por coordenada uma sequência de n valores escalares representando um único ponto em um espaço n-dimensional;
• A coordenada é equivalente ao que na matemática e também na informática recebe a denominação vetor: um elemento que não é escalar, mas sim formado por componentes, e portanto tem propriedades e operações algébricas, aritméticas e geométricas vetoriais, que são qualitativamente diferentes das mesmas propriedades e operações escalares.
• Os valores devem ser mutuamente independentes entre si;
• O número de valores deve ser igual ao número de dimensões do Sistema de Referência;
• A ordem dos valores é definida pelo Sistema de Referência utilizado;

Vejam que no caso do GPX a posição não é exatamente uma coordenada, pois latitude e longitude são definidos nominalmente, sem uma ordem especial.

Latitude e Longitude são qualitativamente diferentes

Quando pensamos em espaço tridimensional, geralmente imaginamos coordenadas XYZ de um sistema retangular onde cada eixo pode assumir valores que variam de -infinito a +infinito, e onde as unidades de medida em qualquer eixo são simétricas.

Já no caso das coordenadas esféricas, isso não ocorre, pelos seguintes motivos:

• Os valores de Latitude não são infinitos, eles variam entre a latitude do pólo norte e a latitude do pólo sul, respectivamente -90 e 90 graus;
• Os valores de Longitude não são "exatamente" infinitos, mas sim cíclicos ao redor do eixo terrestre. Se um objeto se deslocar continuamente ao longo do Equador, em algum momento ele ultrapassará o limite e "aparecerá" do outro lado de um intervalo que varia entre -180 e 180 graus;
• Os valores de elevação podem ser positivamente infinitos (embora isso signifique praticamente trocar a geografia pela astronomia), mas se tivermos uma elevação negativa com relação ao nível do mar, e o valor dessa elevação for excedendo o raio terrestre, estaremos já criando uma elevação crescente em direção ao outro lado do globo.

Assim sendo, há restrições naturais ao intervalo válido para cada um dos valores de uma coordenada geográfica, que devem ser considerados ao definir uma classe Position.

Elevação: definir ou não definir?

Outro "tema polêmico" diz respeito à elevação. Até muito recentemente, os softwares e sites de mapas (TrackMaker, Google Maps) apresentavam a informação em 2D. Trajetos desenhados com o mouse envolviam clicar no mapa, definindo uma sequência de coordenadas 2D que constituíam uma Track. A informação tridimensional só era disponível se tivéssemos um arquivo GPS, do qual era possível plotar a altimetria em um gráfico de altitude vs distância, por exemplo.

Com a chegada do Google Earth, um imenso ganho foi obtido em termos de "sentir" o terreno durante a visualização, com a possibilidade de imaginar a dificuldade de passar por um ou por outro caminho, e desenhar o caminho preferido na forma de um Track. Para a imensa decepção, entretanto, mesmo os arquivos KML salvos no Google Earth continham "0.000" no valor de altitude...

Atualmente, existem várias fontes de dados de elevação online, derivadas do projeto Shuttle Radar Topography Mission (SRTM), e diversos aplicativos e sites já exibem informação de altimetria automaticamente, sob demanda, enquanto o usuário desenha sua rota sobre o mapa. Como em geral a elevação do terreno é função da posição geográfica, visto que cada ponto da superfície da Terra tem uma única altitude (exceto nos casos raros de penhascos verticais ou com inclinação negativa), é conceitualmente possível extrair a altitude de uma coordenada do tipo latitude,longitude, usando para isso um Modelo de Elevação Digital (Digital Elevation Model - DEM).

É importante salientar que a premissa acima - elevação como função de latitude e longitude - vale apenas para a superfície terrestre, não sendo suficiente para descrever trajetórias de objetos voadores, marinhos ou subterrâneos.

Se considerarmos que o espaço geográfico é tridimensional, e que o sistema de coordenadas que escolhemos (WGS84) é também tridimensional, sendo os dados de mapa apenas o resultado de uma projeção (ou seja, uma visualização bidimensional de entidades cuja natureza é tridimensional), então somos obrigados a afirmar que o valor de elevação faz parte de qualquer instância de uma classe Position, mesmo quando não é conhecido.

O Google Earth opta por inserir o valor "0,000" (zero) em pontos cuja elevação não é conhecida.

O KML define como opcional o terceiro valor de coordenada, assim como o GPX trata a elevação como algo que é "medido", ou seja, pode ou não estar presente. Isso contempla bem o caso em que um TrackSegment apresenta elevação na maioria dos pontos, mas por razões quaisquer possa conter pontos onde o valor de elevação é ausente.

Assim, me parece (e a discussão a esse respeito é muito bem-vinda) que inserir o valor "0,000" no lugar de "nulo" é um erro, pois zero é um valor numericamente válido, porque ele pode de fato ser zero (por exemplo no nível do mar), e é impossível distinguir, em uma aplicação se uma instância com elevação zero possui ou não possui alguma elevação. Em especial, no KML, o elemento <altitudeMode> determina como uma feature deve ser renderizada, possibilitanto ao próprio Google Earth (ou qualquer outra aplicação compatível) renderizar corretamente as entidades junto ao solo quando a elevação for zero e o modo for clampToGround.

A definição da classe Position

Depois de tudo que foi exposto, chegamos na hora de propor uma classe para a representação da posição geográfica. A seguir, as características dessa classe:

• A classe se chamará Position. O idioma inglês foi escolhido porque é a linguagem da tecnologia e de todos os padrões utilizados até agora (ISO, KML, GPX) e das linguagens em que o sistema possa vir a ser implementado. Outros nomes seriam possíveis. A ISO propõe DirectPosition, mas não apresenta nenhum outro tipo Position que não seja "direct", e não justifica o uso de "direct" neste contexto. Aplicações web (Google, Strava, etc.) usam latlon ou latlng, mas esses nomes são pouco específicos. Também, o nome Point não me parece ser o mais adequado, pois refere-se à primitiva geométrica e/ou topológica, que contém a posição como um de seus atributos. Também foi evitado o prefixo "geo", como em "GeoPoint" ou "GeoPosition", devido à confusão entre as disciplinas Geometria e Geografia. Dado que a classe Position pertencerá a algum namespace situado em um pacote voltado à informação geográfica, o contexto de Position como uma classe geográfica fica implícito, e deverá também estar explícito em alguma documentação;
• O sistema de coordenadas é o WGS84. Qualquer projeção 2D deverá utilizar a latitude e a longitude nesse sistema, simplesmente ignorando a elevação;
• As propriedades (atributos) da classe se chamam latitude, longitude e elevation. O termo elevação é preferível para representar valores absolutos em relação ao geóide ou elipsóide de referência, enquanto altitude se refere à altura com relação ao solo - por exemplo, de um avião durante o vôo;
• As propriedades podem ter seu nome iniciando com letra maiúscula ou minúscula, de acordo com a convenção da linguagem em que a classe for implementada;
• A propriedade latitude deve respeitar a restrição $\begin{aligned}\{ -90 < latitude < 90 \}\end{aligned}$, a propriedade longitude deve respeitar a restrição $\begin{aligned}\{ -180 < longitude < 180 \}\end{aligned}$, e a propriedade elevation deve respeitar a restrição $\begin{aligned}\{ elevation < -EARTH\_RADIUS \}\end{aligned}$, onde EARTH_RADIUS deve ser uma constante definida em um namespace acessível à classe Position;
• Nenhum construtor da classe Position deve ser capaz de gerar uma instância de Position com valores inválidos (fora do intervalo);
• Uma posição não é mutável. Se algum código cliente quiser alterar uma posição, deve criar uma nova instância de Position com os novos valores desejados;
• O valor de elevação, quando não conhecido, deve receber o valor nulo (NaN, None, null, ou o que for mais apropriado na linguagem de implementação).

Um comportamento que definitivamente merece debate é como validar os valores de latitude, longitude e elevação passados como argumentos ao construtor, quando esses valores excedem os limites. Como já foi argumentado, o valor de longitude muda subidamente de 180 para -180 se girarmos ao redor do equador. Por outro lado, se formos seguindo um meridiano, a latitude aumenta até 90 e passa imediatamente a diminuir (pelo meridiano oposto) até -90, e então passa a aumentar novamente. Um gráfico do primeiro deslocamento mostraria a longitude variando como um dente de serra, enquanto o gráfico do segundo seria um formato triangular (desculpem pela ausência da figura, ainda não domino a arte de produzi-las para as postagens). Se o construtor deveria limitar os valores ao máximo, ou calcular sua correspondência "podando" o excesso (provavelmente usando o operador de divisão em módulo "%"), ou simplesmente gerar um erro, ainda não tenho certeza, mas me parece que a segunda opção é matematicamente válida.

No momento, a classe não possui nenhum método, já que sua responsabilidade é somente definir uma posição geográfica válida.

Na próxima postagem, pretendo propor implementações em alguma(s) linguagem(ns), considerando que as linguagens alvo que pretendo trabalhar são Python, C# e Javascript.

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.