Estou pensando em escrever um software para lidar com trilhas e pontos de rota de GPS (principalmente armazenando, exibindo e calculando métricas como velocidade, nota e algumas estatísticas simples).
Gostaria de saber qual deve ser o modelo de dados mais conceitualmente robusto em relação aos pontos de controle, e aqui estão alguns "candidatos":
Considerando Faixas como sequências de Trackpoints:
1.1 As faixas são consideradas "2D", pois as projeções do mapa são 2D. Os pontos de trilha podem ou não ter elevação, podem ou não ter timestamp. Elevação e registro de data e hora são considerados "extras", "opcionais". Para aplicações terrestres, a elevação é uma função direta de lat / lon (obtida via DEM);
1.2 As trilhas são consideradas "3D", pois o espaço geográfico é, de fato, 3D, e a trajetória do receptor é 3D (a projeção em 2D é, portanto, uma forma de redução de dados). O registro de data e hora pode ou não estar presente (a faixa pode ter sido desenhada à mão).
1.3 As faixas são consideradas "4D" (3 espaciais + tempo). Assim, um mapa desenhado à mão é um caso especial em que a elevação e o carimbo de data / hora estão
nullou não presentes, mas as propriedades do Trackpoint estão sempre "lá".As faixas são consideradas dicionários de fluxos, onde todos os fluxos têm comprimentos iguais. Há uma lista de latitudes, uma lista de longitudes, uma lista de elevações, uma de registros de data e hora, etc. Isso facilita o cálculo de estatísticas de cada propriedade, e o conceito de Trackpoint se torna "virtual" em certo sentido, pois é um seção transversal de muitos fluxos.
Se bem entendi, o formato GPX adota 1.1., O KML adota 1.2. (sem suporte para registro de data e hora) e a API Strava adota 2. (no formato JSON), mas no final são apenas formatos de arquivo para serialização e armazenamento, não necessariamente para modelagem, representação computacional e processamento de números.
Existe alguma forma preferível, no sentido orientado a objetos, e por quê? (Acredito que digitação forte e modelagem sensível pelo menos evitariam operações que não fazem sentido).
EDIT: algumas perguntas adicionais "intrigantes":
- Uma trilha desenhada à mão é CONCEPTUALMENTE a mesma coisa que uma trilha registrada por dispositivo? Eles devem ter diferentes tipos de dados?
- Deve ser considerado "correto" que o KML armazene elevações nulas como zero? Zero É uma elevação e, se você não conhece a elevação, não deve atribuir um zero numérico a ela, não é?
- Importa, em uma pista com elevação, se a elevação é extraída de dados DEM ("offline") ou de dados GPS ou dados barométricos ("no campo")? Isso deve ser sinalizado no objeto Track? Salvo em diferentes propriedades do Trackpoint? Ignorado? Eles devem ser tipos de dados de coleção diferentes?
- Se eu editar uma faixa gravada por dispositivo em um editor de mapas (adicionar, mover e remover pontos) ou combinar faixas de datas diferentes, como os carimbos de data e hora nos pontos de trilha devem ser tratados? Eles devem ser "redefinidos" para nulos? Um objeto (coleção de trackpoints) de um tipo diferente deve ser criado a partir dos anteriores?
<>e{}para ajudá-lo a organizar seus dados - e metadados -, você está fazendo errado.