Considerar coordenadas 31.96212, -103.004715
Os conversores UTM fornecem coordenadas UTM 13/R/FR
.
O conversor de exemplo está aqui: http://www.rcn.montana.edu/resources/converter.aspx
Mas há muitos deles e eles dão respostas semelhantes para essas coordenadas.
Simultaneamente, no conjunto de dados do Sentinel-2 aqui http://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/13/R/
Não consigo encontrar o FR
subdiretório.
No google, esta localização é aqui:
E encontrando o mesmo lugar no navegador de imagens do Sentinel , vejo que esse bloco é diferente
que significa,13/S/FR
ou seja, o mesmo UTM
e quadrado, mas banda diferente.
Como isso é possível?
ATUALIZAR
O KML com blocos do Sentinel-2 também relata o S
bloco em um determinado local
ATUALIZAÇÃO 2
De acordo com esta imagem
tirada daqui , a FR
praça está localizada metade na S
zona UTM e metade na R
zona. Obviamente, a maioria dos conversores automáticos atribui esse quadrado à R
zona, enquanto o Sentinel-2 é responsável por S
zona.
Existe alguma verdade aqui?
ATUALIZAÇÃO 3
O código Python simples, extraído daqui https://gis.stackexchange.com/a/224994/32207
bandVals = "CDEFGHJKLMNPQRSTUVWXX"
lon = 31.96212
lat = -103.004715
zone = int(lat + 186.0) / 6
if (lon >= 84.0):
band = 'Y' if (lat < 0.0) else 'Z'
elif (lon <= -80.0):
band = 'A' if (lat < 0.0) else 'B'
else:
band = bandVals[int(lon + 80.0) / 8]
print '{:02d}{:s}'.format(zone,band)
também retorna 13R
.
Esse erro está nos dados do Sentinel-2 ou o quê?
S/FR
, enquanto os conversores UTM dãoR/FR
. Como calcular a localização se os conversores UTM funcionam incorretamente?Respostas:
Em resposta à sua pergunta de comentário "como simular esse algoritmo":
Esta é uma solução bastante bruta, mas fácil de implementar e deve oferecer bom desempenho:
Em seguida, verifique se a pasta existe na estrutura de dados do Sentinel 2. Se sim, você terminou, viva.
Caso contrário, verifique as grades UTM vizinhas e veja se o bloco / pasta "FR" existe nelas. Dado que há sobreposições em todos os lugares, você teria que verificar todas as 8 grades ao redor.
A ordem mais provável de verificação seria 13S, 13Q, 12R, 14R, 12S, 14S, 12Q, 14Q.
Os quatro últimos podem ser relevantes se suas coordenadas estiverem nos cantos de uma zona UTM, mas são altamente improváveis.
Dada a maneira como o Sentinel2 rotula blocos, apenas um dos vizinhos deve ter essa pasta, garantindo que você obtenha o arquivo correto.
Qualquer outra solução geograficamente mais "correta" envolveria muito mais sobrecarga computacional do que eu acho que se justifica aqui.
E, definitivamente, definitivamente relate isso à equipe da ESA, conforme sugerido por Kersten nos comentários. Realmente não entendo por que eles escolheram um sistema organizacional tão desnecessariamente complicado.
fonte
Post relacionado aqui
O que tem funcionado para mim é usar o K2 S2 fornecido pela ESA para calcular todos os blocos ali que se cruzam com a minha AOI e, em seguida, procurar esses blocos na AWS.
Esse KML parece funcionar como uma definição de todos os IDs de bloco possíveis gerados pelo S2, eliminando muitas opções sobrepostas.
Observando o KML (somente inspeção visual, não 100% de certeza), parece-me que, na pior das hipóteses, você teria que procurar por quatro blocos.
Seria bom ter o algoritmo usado pela ESA para definir o KML para tornar isso mais eficiente.
fonte