Esquema de Aplicação, Modelo de Domínio e Universo de Discurso em aplicações GPS para uso pessoal

Em postegens anteriores, foram feitas considerações sobre usos de GPS, e especificamente de arquivos de GPS, para aplicações pessoais de planejamento e registro de viagens ou atividades esportivas envolvendo deslocamentos (ciclismo, por exemplo).

Atualmente, temos uma situação em que duas plataformas (GPS + Internet) tornou possível a muitas pessoas, mesmo sem grandes conhecimentos técnicos,  pesquisar, planejar, executar e analisar essas viagens e atividades. E isso ocorre graças à existência de aplicações que fazem justamente a mediação entre os usos pretendidos pelo usuário, e a estrutura computacional dos dados propriamente ditos.


Como já foi comentado previamente, o grupo que realizou a mais completa análise dssa problemática foi o ISO/TC 211, e o resultado desse trabalho foi o conjunto de normas ISO 191xx, que será usado também como referência para esta discussão.

Uma coisa que precisa ficar clara, entretanto, é que esse trabalho da ISO tem um escoplo exaustivamente amplo e formal, focado principalmente em Sistemas de Informação Geográfica para uso profissional.

O que se busca aqui, como um resultado final da discussão, são orientações que permitam definir os requisitos de uma aplicação em nível de usuário final, sem treinamento especializado, para que este possa criar e extrair informação relevante, usando seus próprios dados pessoais em conjunto com dados de outras pessoas e também dados geográficos publicamente disponíveis.

A melhor fonte de referência para modelagem de dados voltada a aplicações (principalmente, mas não necessariamente geográficas) é a ISO - 103 - Conceptual Schema Language (Linguagem de Esquema Conceitual).

Alguns conceitos relevantes são os seguintes (comentários meus):

• Aplicação: "Manipulação e processamento de dados em suporte aos requisitos do usuário". Neste contexto, fica entendido que o usuário necessita atender uma necessidade pessoal sua, sendo que essa necessidade envolve manipulação da informação. Em geral, entendemos aplicação como um software a ser executado em um computador, manipulando informação de natureza digital / computacional, mediante comandos interativos do usuário.
• Esquema de Aplicação: "Esquema conceitual para os dados requeridos por uma ou mais aplicações". Isso significa que, para que a aplicação tenha condições de gerar informação relevante ao usuário, é necessária a existência de um modelo que contenha os conceitos necessários à manipulação e ao processamento.
• Modelo Conceitual: "Modelo que define os conceitos de um universo de discurso". Uma aplicação depende de um modelo de aplicação, que por sua vez depende de um modelo conceitual. A diferença entre ambos é que o modelo conceitual é autônomo, dependendo apenas da natureza da realidade representada, e da seleção de um domínio ou universo de discurso, que consiste num subconjunto das propriedades dessa realidade.
• Universo de Discurso: "Parte do mundo real (ou de um mundo hipotético) que um ser humano deseja descrever em um modelo". Todo modelo envolve uma simplificação, constituindo uma representação limitada do fenômeno real que ele descreve. Portanto, em geral apenas os aspectos da realidade que são relevantes a um determinado domínio de conhecimento são selecionados para participar do universo de discurso.
• Entidades ("features"): "Abstração de uma entidade ou fenômeno do mundo real". Uma entidade geográfica seria a representação de uma entidade ou fenômeno natural associado a uma determinada localização no Planeta Terra.

No caso da informação geográfica, a realidade seria o Planeta Terra, sua atmosfera, seus rios, florestas, desertos, montanhas, vegetação, população, cidades, e todos os outros ambientes naturais ou artificiais.

Um universo de discurso para a informação geográfica, e em especial no contexto de informações pessoais do usuário, seriam estradas, terrenos, relevos, cidades, ruas, pontes, túneis, postos de gasolina e locais de comércio, pontos turísticos, pontos de interesse em geral, bem como trajetos previamente desenhados ou percorridos por outras pessoas.

Um modelo conceitual consistiria na representação abstrata dessas entidades selecionadas pelo universo de discurso. Um modelo de terreno seria representado por uma superfície geométrica, uma estrada seria representada por uma linha, um local turístico seria representado por um ponto, e de um modo geral, a forma e a posição dessas entidades poderiam ser descritas através de coordenadas numéricas dentro de um determinado sistema de referência. Além da estrutura, também os comportamentos de cada tipo de entidade poderiam ser descritos, a fim de possibilitar que as aplicações realizem operações sobre esses objetos, com a intenção de extrair ou criar informação relavante sobre as entidades.

Por fim, a aplicação propriamente dita - e concretamente implementada em uma plataforma computacional - converte o modelo conceitual em um esquema de aplicação, com classes, métodos, estruturas de dados, formatos de arquivo e tipos numéricos apropriados à plataforma escolhida, afim de satisfazer os casos de uso adequados às necessidades do usuário.

As normas ISO determinam (ISO 19109 - Rules for Application Schema) que a informação geográfica seja representada usando o UML (Unified Modeling Language), o que é conveniente quando se pensa em implementar uma aplicação orientada a objeto.

Em postagens futuras, veremos que o esquema KML corresponde bastante ao modelo UML proposto pela ISO para as entidades geográficas (ponto, linha, região, superfície, embora não necessariamente com o mesmo nome), mas algumas operações (na forma de métodos) não têm como ser descritas em KML, necessitando de classes instanciadas dentro de uma aplicação sendo executada.

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.

Por um modelo de dados para GPS aplicado ao ciclismo - Parte 1: Uma breve história baseada em experiência pessoal

Eu, como ciclista de longa data, peguei toda a evolução do uso de GPS em bicicleta, assim como a evolução dos serviços de mapa online (Google Earth e depois Google Maps), e mais recentemente dos sites de aglomeração exponencial de dados de GPS, cujo exemplo de maior destaque é o Strava.

No início, aventuras pelo mundo afora eram acompanhadas de mapas rodoviários de papel, ou planilhas de quilometragem baseadas nesses, provavelmente feitas à mão. Em regiões mais remotas, muita utilidade tiveram, para mim e para outros, os mapas topográficos do exército. Tanto por um meio quanto por outro, a incerteza era um fator sempre presente, incluindo estradas que haviam sido modificadas, placas na estrada que indicavam distâncias erradas, etc.

Mapa topográfico da região de Riozinho - RS, escala 1:50.000

O primeiro passo no sentido de eliminação de incerteza foi começar a usar GPS para pedalar. A simples ideia de ter um aparelho que soubesse SEMPRE onde eu estava, e principalmente se eu havia voltado pelo mesmo caminho, era revolucionária. Mas não tão revolucionária, pois nos modelos mais primitivos não havia mapa de fundo, e portanto era necessário enviar uma rota ao aparelho antes, e nem sempre foi fácil criar essa rota antecipadamente.

Meu primeiro GPS, que me acompanhou em dezenas de pedaladas,
era um Garmin eTrex Venture como o da foto acima

O passo seguinte ocorreu logo em seguida, quando fui apresentado mais diretamente ao software GPS Trackmaker, que é simplesmente GENIAL, e curiosamente é produzido até hoje pela empresa de mesmo nome, situada em Minas Gerais. Esse software faz algo que considero crucial para a atividade de "navegar no mundo de bicicleta usando um GPS": ele vincula o MAPA, e no caso do mapa embutido que já vem com o software, um mapa feito para uso eletrônico, com o APARELHO de GPS. Explico melhor por que isso é importante:

• O mapa eletrônico, em uso no PC, é o momento em que o usuário está em contato com uma fonte difusa de dados geográficos, na confortável situação em que pesquisas, reflexões, comparações, síntese de dados a partir de outras fontes, tudo isso pode ser feito sem um limite crítico de tempo ou "cansaço". É nesse contexto que a ação intelectual do usuário, subsidiada por fontes potencialmente ilimitadas de informação geográfica (mapas, sites, trajetos percorridos por outros usuários de GPS que tenham compartilhado online, etc.) podem ser processados e sintetizados na forma de uma rota que é salva em arquivo e enviada ao aparelho.
• O aparelho de GPS, por sua vez, é como se fosse uma extensão móvel de todo esse planejamento. A diferença é que ele é levado a campo, e em campo é que o plano é executado. Para muitos planejadores de viagens, a transformação gradual da rota planejada (desconhecida, imaginada) em rota percorrida (confirmada, ratificada, assimilada) é um componente importante do próprio prazer de fazer a viagem por locais até então desconhecidos. O próprio fato de o GPS tornar, em tempo real, um lugar desconhecido em um lugar, de certa forma, "conhecido", é a razão de ser possível fazer viagens por lugares desconhecidos, coisa que não seria possível de outra forma - ao menos não com a mesma eficácia.

Software GPS Trackmaker com mapa de fundo

Durante muito tempo, essa era uma atividade que atraiu um nicho de participantes, em geral adeptos de atividades de aventura, que percorriam diversos lugares com seus GPS e iam compartilhando essas rotas, que num segundo momento começaram a alimentar mapas feitos a mão, já em formato eletrônico que era então compilado e transformado em mapa base para uso tanto nos softwares de edição, quanto nos mapas de fundo dos aparelhos mais sofisticados que tivessem essa funcionalidade. Um exemplo clássico de uma comunidade brasileira dedicada é o Projeto Tracksource. Iniciativa similar, mas com um foco diferente, é o Open Street Maps (OSM). Ambos envolvem a produção de conteúdo geográfico público por uma comunidade de voluntários que criam, editam e aperfeiçoam um grande mapa digital.

Um fator que foi definitivo - na minha opinião - e que teve tão grande sucesso que hoje chega a ser banalizado, é o "boom" de serviços de mapa online, do qual o maior exemplo é o Google Maps. Embora no início as fotos de satélite não fossem em alta resolução em todos os lugares, nem houvese estradas roteáveis no mapa inteiro, a cada ano pôde-se perceber uma absurda evolução, ao ponto de hoje até mesmo as estradas de terra estarem TODAS identificadas e roteáveis (ao menos no Rio Grande do Sul, que é onde moro e costumo pedalar), de forma que não seria exagero dizer que a edição manual de mapas para envio ao GPS se tornou obsoleta: vale mais a pena clicar no ponto A, depois no ponto B, e mover os pontos intermediários para onde se queira passar, exportando a rota gerada para um arquivo .KML que pode facilmente ser enviado aos aparelhos GPS por meio de algum software.

Dando sequência à série de revoluções (lembrando que essa é minha perspectiva pessoal, outras pessoas provavelmente terão impressões bem diferentes), uma "dupla revolução" marca a mudança de um aspecto conceitual importante na relação Bicicleta + GPS: a popularização dos smartphones com GPS, e a popularização de um determinado site de armazenamento de atividades esportivas gravadas com GPS: o Strava.

Essa mudança conceitual de que falo consiste na mudança do foco de atenção com relação ao dado que o GPS produz: ao invés de extrair do trajeto a informação geográfica (distância, altimetria, lugares percorridos, mapa, ou seja, informação sobre o terreno), agora a informação mais importante, é a informação sobre o ciclista! Em um contexto em que as trilhas já foram trilhadas, os terrenos já foram explorados, e principalmente e todo o planeta já foi fotografado e mapeado, podendo ser visto na internet a qualquer momento, o que passou a contar mais é algo que secretamente era o sonho de todos aqueles que já tiveram um velocímetro na bicicleta: gravar TODO o trajeto. Saber em que velocidade eu estava, e qual foi a hora em que eu passei, em TODOS OS PONTOS do trajeto. Agora já não é mais necessário dar start, stop ou mesmo zerar o velocímetro. Grava-se tudo, e depois se analisa, seleciona, segmenta, compara, se realizam todas as operações de análise em casa, com ferramentas computacionais avançadas diponíveis publicamente no browser, e em constante evolução.

Painel de análise de atividade do Strava, que permite navegar nos gráficos, selecionar determinados segmentos, e saber médias e máximas parciais, diretamente no browser

Assim sendo, passamos de uma situação de escassez e hipervalorização da informação geográfica (a glória era achar um arquivo, compartilhado por alguém, que contivesse a trajetória para o acesso a determinado ponto turístico - pois do contrário seria impossível ir até ele com certeza), para uma situação de abundância que beira a banalização, onde a gente chega ao lugar já sabendo até quais as placas vai encontrar na estrada (pois já analisou o caminho no Google Street View, por exemplo).

No campo da análise de movimento, também passamos de uma situação de escassez (onde as únicas informações que restavam eram o tempo, a distância, a velocidade média e a velocidade máxima, marcadas no velocímetro), para uma situação de abundância, onde dia a dia se acumulam trajetos e mais trajetos, nossos, dos nossos amigos e de desconhecidos, que contêm informação suficiente para reconstituir as atividades ciclísticas praticamente como elas aconteceram de fato, como é o caso do Strava Activity Playback.

As questões que surgem com tudo isso são:

• Estamos de fato aproveitando todos os benefícios que essa avalanche de informação, que é tão recente e tão inédita, é capaz de nos proporcionar?
• O que é possível fazer com conjuntos de dados de GPS ciclísticos tão vastos como o do Strava? Ou, num nível pessoal, com sua própria coleção de trajetos?
• Que tipo de software essa "nova geração" de dados requer para que possa mostrar todo seu valor? Que algoritmos, operações, entidades, objetos, devem ser criados para corretamente representar e manipular essa informação?
• Os formatos de arquivo disponíveis atualmente (.GPX, .KML, etc.) são adequados para representar essas entidades? Especificamente esses dois formatos representam o mesmo TIPO de elementos?

Enfim, essas e outras perguntas eu pretendo aprofundar com novas reflexões em postagens que seguirão.