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?
fonte
<>e{}para ajudá-lo a organizar seus dados - e metadados -, você está fazendo errado.Respostas:
Eu não acho que essa pergunta possa realmente ser respondida definitivamente, pois existem muitas, muitas maneiras de abordar isso.
No entanto, esses pensamentos podem ser relevantes:
O armazenamento de dados é relativamente sem importância. Qualquer que seja o mecanismo usado, banco de dados, JSON, KML, etc, ainda é "armazenamento simples".
O importante é o software que você usa e como você representa os dados no software para poder realizar sua modelagem.
A velocidade está disponível de duas maneiras, distância x tempo ou como saída de um dispositivo GPS, de onde você está fornecendo seus dados. Portanto, o tempo se torna irrelevante, exceto como um item informativo.
Além disso, você também pode considerar o tempo usando um deslocamento desde o início da faixa. Se você tiver a velocidade e a distância, poderá calcular os horários nos pontos. (a distância entre dois pontos pode ser determinada por vários métodos diferentes )
A elevação deve ser considerada parte do Modelo Espacial, eles são relevantes para determinar toda uma série de informações interessantes sobre a pista em si, por exemplo, o grau pode ser calculado, o que permite entender as variações de velocidade ao longo de uma trilha. Se não houver inclinação, qualquer desaceleração ou aumento de velocidade pode ter sido causado pela remoção do pé do acelerador.
Em termos de mesclar faixas e faixas desenhadas à mão, o tempo é de pouca relevância. Você pode aplicar velocidades arbitrárias para determinar o tempo, por exemplo, quanto tempo percorrer uma pista a uma determinada velocidade. Se você estiver mesclando faixas com vários dias de diferença, seus dados simplesmente não farão sentido, portanto você terá que redefinir os campos de tempo, possivelmente usando deslocamentos no início da faixa.
Se a elevação não é conhecida, ela não é conhecida e, portanto, não deve ser zero. Também não deve ser negativo, pois as elevações negativas também são válidas. (Em um vale abaixo do nível do mar, poço de minas, etc)
Sim, DEMS estão disponíveis, sim, você pode extrair deles. A precisão será suficiente? Improvável, a menos que a precisão não seja um problema. GPS ou barometria, desde que as elevações sejam as melhores que você pode obter.
Então, para tentar dar uma resposta que se aproxima:
Armazene os dados em qualquer formato plano que desejar, mas eu recomendaria o PostGRES com PostGIS seja uma boa opção, ele lida com 3D de maneira agradável. Você pode usar as extensas funções espaciais no PostGIS para manipular / modelar seus dados.
Se você usar algum tipo de programa personalizado desenvolvido, use uma abordagem Orientada a Objetos em vez de matrizes. Se você usa matrizes, também pode usar um banco de dados.
fonte
Como já mencionado em outra resposta, existem muitas abordagens diferentes. Como solicitei "modelos de dados conceitualmente robustos", depois de muita pesquisa, encontrei dois grandes corpos de conhecimento que fornecem duas abordagens bastante diferentes para o conceito de "objetos em movimento" e têm muita sobreposição (no bom sentido):
fonte