Controlador temporal - simbologia dependente do tempo baseada em @map_start_time

Question

Recentemente, eu estava assistindo ao vídeo de Nyall Dawson "QGIS 3.14, manipulação de tempo e demonstração de animação de mapa". no mínimo 47 ( nyall dawson / vídeo do youtube no mínimo 47 ) as coisas estão ficando interessantes do meu ponto de vista.

Ao testar os recursos do "controlador temporal", obtive alguns resultados confusos ao tentar implementar a abordagem de simbologia dependente do tempo mostrada no vídeo - imag_01 mostra meus resultados seguindo o vídeo-tutorial:

• dados: uma trilha de GPS de uma corrida de iates no Adriático. o intervalo de aquisição de dados é de cerca de 5 min
• símbolos de ponto (amarelo): em primeiro plano são controlados pelo controlador temporal QGIS
• pontos (cinza): no fundo são atemporais e exibidos apenas para dar uma visão geral das configurações do controlador temporal:
• largura do passo: 15min (= 0,25 horas)
• o intervalo exibido começa 2018-10-15 15:45:00
  e termina em 2018-10-15 16:00:00 (veja os valores ao lado da entrada "Quadro:")

o tamanho do ponto depende de uma expressão temporal - assim como no vídeo: hour(@map_start_time - time_s_oesec")(veja a expressão em image_02) onde

• @map_start_time é a variável interna do QGIS - que deve ser igual ao valor inicial do quadro, ou seja, '2018-10-15 15:45:00' no meu exemplo
• time_s_oesec é uma referência ao campo temporal em meus dados - ou seja, a localização dos dados de carimbo de data / hora de rastreamento por GPS (... os valores no campo time_s_oesec são armazenados sem segundos neste exemplo para manter as coisas simples)

Como @map_start_timeé o limite inferior do intervalo de tempo exibido, qualquer carimbo de data / hora dentro do intervalo é maior ou igual @map_start_time. Escalando os pontos amarelos (de acordo com o vídeo de Nyall Dawson) baseia-se na expressão acima mencionado: hour(@map_start_time - time_s_oesec).

image_01 mostra meus rótulos de teste

• 1ª linha: valor do campo do ponto GPS, por exemplo, " time_s_osec: 15.10.18 15:50:00"
• 2ª linha: valor atual da variável de início do mapa, por exemplo, " @map_start_time: 15.10.18 15:45:00"
• 3ª linha: " @map_start_t* - time_s*: 1,92" esses valores devem ser negativos devido à expressão @map_start_time - time_s_oesece NÃO devem variar de> 1 a> 2 dentro do intervalo definido
• 4.line: este é o meu valor de verificação -> este valor é a saída de: hour(to_datetime('2018-10-15T15:00:00')- "time_s_osec") onde '2018-10-15T15:45:00'é um texto fixo que é transformado em horas com base no formato de data e hora QGIS e deve corresponder exatamente ao valor real de a variável @map_start_time

Obviamente, a expressão na linha 4 retorna resultados válidos - veja / compare os seguintes exemplos em image_01:

Para o ponto no tempo gps no mapa 15/10/2018 T15: 45: 00

• to_datetime('2018-10-15T15:45:00')/ time_s_oesec: 15:45 / resultado = -0,00 ... que é o esperado,
  mas @map_start_time - time_s_oesecretorna um valor de 2,0

para o ponto no tempo gps no mapa 15/10/2018 T15: 29: 00

• to_datetime('2018-10-15T15:45:00')/ time_s_oesec: 15:29 / resultado = 0,27
  mas @map_start_time - time_s_oesecretorna um valor de 2,27

Resumo: expressões na linha 4 - que são baseadas no text-check-value '2018-10-15T15:45:00'retornam valores positivos para gps-timestamps antes da "hora de início do quadro" 15:45 (já que a data e hora do GPS é menor que a hora de início) e valores negativos após 15 : 45 já que é o contrário.

Embora a expressão hour(to_datetime('2018-10-15T15:00:00') - "time_s_osec"resulte em valores corretos, a maneira como o "gerenciador temporal" trata @map_start_timenesse contexto é estranha / falha.

Mas ... Vale a pena um relatório de bug?

Se necessário, posso fornecer dados de teste

image_01:

image_02:

Answer 1

Recebi uma dica de rduivenvoorde sobre o sistema de relatório de bugs QGIS (consulte: Problema de relatório de bugs do GitHub QGIS 39393. na verdade, é uma solução alternativa e ainda não tenho certeza de por que está funcionando. mas funciona para a minha implementação.

de acordo com as informações no GitHub, o QGIS não reconhece o fuso horário e esse problema é considerado complexo. após as respostas do GitHub, os valores de dados e hora são geralmente interpretados como valores UTC agora.

mas dimensionar o tamanho dos símbolos de ponto com base em um valor dependente do tempo pode ser implementado com esta expressão:

hour(@map_start_time - to_datetime(to_string( "time_s_osec" )+'Z') )

Onde

• to_string ... muda o valor do tempo do campo "time_s_osec"para uma string

• +'Z'concats a Z ... onde Z indica tempo "ZULU" (sim, é chamado assim); O fuso horário ZULU corresponde exatamente ao fuso horário UTC!

• to_datetime se transforma de volta em um valor de data e hora

• e hour(@map_start_time - to_datetime(to_string( "time_s_osec" )+'Z') )calcula a diferença entre a hora de início do intervalo de tempo (que depende da posição dos controles deslizantes de tempo e do valor da etapa) em horas decimais

se entendi direito, faz sentido ("manualmente") converter os dados de tempo do campo original em valores de hora UTC (por exemplo, em um novo campo de data e hora) e aplicar a expressão acima mencionada naquele novo e correto Valores UTC.