Resultados do observatório: catálogo retrospetivo de 30 dias do Báltico e estudo de sensibilidade

Versão kshana-observatory/adsb/v1 sobre kshana-interference-map/adsb/v2 (parâmetros pré-registados no método de base, inalterados). MODELLED: não há referência independente externa, nem verdade de referência, nem atribuição de causa. Uma célula degradada significa que uma elevada proporção das aeronaves amostradas aí comunicou baixa exatidão de navegação nesse dia; não diz porquê. Uma célula que não é observada, ou que está ausente, não foi avaliada, o que não é o mesmo que estar livre.

O que foi executado#

• Fonte: histórico readsb do adsb.lol (ODbL 1,0), versão v<YYYY>.<MM>.<DD>-planes-readsb-prod-0 do GitHub de adsblol/globe_history_2026, obtida por scripts/fetch_adsblol_day.sh uma parte de cada vez (cerca de 3,4 GB por dia, 2 partes). O editor não indica somas de verificação, pelo que o SHA-256 de cada parte fica registado em back-catalogue/fetch/<tag>.parts.json.
• Região e dias: a caixa 53,5, 9,0, 66,0, 31,0 (sul, oeste, norte, este: o mar Báltico e as suas costas), 30 dias UTC de 2026-09-15 a 2026-10-14, células de 0,5 grau, por scripts/observatory_backcatalogue.sh (um dia de cada vez, ficheiros em bruto eliminados após cada dia).
• Regras de publicação: o dia mais recente (2026-10-14) tinha mais de 24 h decorridas desde o seu fim quando foi produzido; caso contrário, o comando recusa. As execuções regionais calculam a linha de base do equipamento e o fundo do dia apenas a partir das comunicações da caixa (method.scope).
• Ficheiros: os 120 ficheiros de produto (GeoJSON, PNG, JSON de incidentes, manifesto por dia) não estão no git. O hash de cada ficheiro está em back-catalogue/MANIFEST.json, e um dia pode ser reconstruído a partir do seu arquivo e comparado.

Exemplo do que um dia lê: em 2026-09-15 o arquivo continha 110 619 797 linhas de posição em 79 826 ficheiros de trajetória; 103,0 milhões estavam fora da caixa, 5,6 milhões não eram ADS-B, 1,2 milhões estavam no solo ou abaixo de 5 000 ft, 0,6 milhões não tinham campo de exatidão, e 212 426 foram agregadas (contadores de entrada de manifest.json).

Reprodutibilidade#

Três dias (2026-09-18, 2026-09-26, 2026-10-03) foram obtidos de novo do arquivo e executados uma segunda vez: o GeoJSON, o PNG e o ficheiro de incidentes são idênticos byte a byte aos da primeira execução (SHA-256 igual), pelo que o produto é determinista, embora o sal do hash do identificador seja aleatório em cada execução.

Resumo do catálogo retrospetivo#

30 dias: 96 células degradadas no total, 28 dos 30 dias com pelo menos uma, 70 incidentes (grupos de células degradadas contíguas), nenhum dia com um efeito em todo o dia. A proporção mediana de aeronaves afetadas por célula (o fundo do dia) é 0 em 29 dias e 0,006 num, pelo que a salvaguarda do fundo (uma célula tem de exceder o fundo em 0,15) nunca alterou uma decisão nesta região. O número de células degradadas por dia vai de 0 a 8 (média 3,2). Cerca de um terço das células publicadas em cada dia é not_observed (poucas aeronaves amostradas): a cobertura é o limite deste produto, não o céu.

O que isto não diz: os dias com mais células degradadas não são "piores" em nenhum sentido físico, uma área afetada persistente seria subestimada (as aeronaves que voam apenas dentro dela durante todo o dia não têm linha de base fora dela e não são contadas), e nada aqui diz quem ou o que causou a baixa exatidão.

Estudo de sensibilidade (três dias)#

kshana interference-map sensitivity reexecuta as comunicações registadas de um dia sob alterações, uma de cada vez, dos parâmetros registados (dois valores cada, mais uma grelha de 1,0 grau). Dias: 2026-09-18 (o maior número de células degradadas, 8), 2026-09-26 (1 célula degradada) e 2026-10-03 (0). Relatórios completos: sensitivity/<day>.json (23 variantes cada; 2,2, 1,7 e 1,7 milhões de linhas reexecutadas). Células degradadas em cada variante (valor registado entre parênteses; o resultado registado é 8, 1 e 0 células degradadas):

A leitura, sem escolher um vencedor:

• As decisões são sensíveis aos limiares dos códigos de exatidão e às regras de amostragem, e as contagens pequenas variam muito. low_nic_max, degraded_share e min_reports_per_aircraft_in_cell alteram cada um o número de células degradadas por um fator de dois ou mais em todos os dias; relaxar low_nic_max para 6 transforma 1 célula degradada em 12 em 09-26 (Jaccard com o conjunto registado 0,08). Em 09-18, subir degraded_share para 0,4 mantém 1 das 8 (Jaccard 0,125). Uma decisão sobre uma célula próxima dos limiares é uma afirmação sobre os limiares tanto quanto sobre os dados.
• min_aircraft_sampled move sobretudo células entre não degradadas e não observadas: em 09-18 deixa o número de degradadas em 8 enquanto 21 a 56 células mudam de estado.
• Três salvaguardas estão inativas aqui: background_margin, min_baseline_good_reports e day_confound_background não alteram nada em nenhum dos três dias (a proporção do fundo é 0), pelo que esta região e este período nada dizem sobre o seu bom funcionamento. Seriam relevantes onde um efeito regional eleve o fundo.
• Uma grelha mais grosseira (1,0 grau) altera o quadro (2, 3 e 1 células degradadas; as células publicadas descem para cerca de um terço, 226 contra 694 em 09-18, porque cada célula é quatro vezes maior): o tamanho da célula é uma escolha de método, e o observatório fixa-o em 0,5 graus.
• Um dia sem nenhuma célula degradada registada (10-03) tem células degradadas em 9 das 22 variantes sem grelha (até 8 com low_nic_max 6): "nenhuma célula degradada" é também uma afirmação dependente de limiares.

Nenhuma variante é uma alternativa validada, e a regra registada não é alterada por este estudo. O estudo não diz quais são os valores certos dos parâmetros.