Mirar coordenadas 31.96212, -103.004715
Los convertidores UTM dan sus coordenadas UTM 13/R/FR.
El convertidor de ejemplo está aquí: http://www.rcn.montana.edu/resources/converter.aspx
Pero hay muchos de ellos y dan respuestas similares para estas coordenadas.
Simultáneamente, en el conjunto de datos Sentinel-2 aquí http://sentinel-s2-l1c.s3-website.eu-central-1.amazonaws.com/#tiles/13/R/
No puedo encontrar el FRsubdirectorio.
En google esta ubicación está aquí:
Y veo el mismo lugar en el navegador de imágenes Sentinel , ese mosaico es diferente
que significa,13/S/FR es decir, la misma banda UTMcuadrada pero diferente.
¿Cómo es esto posible?
ACTUALIZAR
KML con mosaicos Sentinel-2 también informa Smosaico en una ubicación determinada
ACTUALIZACIÓN 2
De acuerdo con esta imagen
tomada desde aquí , la FRplaza se encuentra mitad en la Szona UTM y mitad en la Rzona. Obviamente, la mayoría de los convertidores automáticos asignan este cuadrado a la Rzona, mientras que Sentinel-2 lo representa por Szona.
¿Hay alguna verdad aquí?
ACTUALIZACIÓN 3
El código simple de Python, tomado de aquí 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)
También vuelve 13R.
¿Es este error en los datos de Sentinel-2 o qué?
S/FR, mientras que los convertidores UTM danR/FR. ¿Cómo calcular la ubicación si los convertidores UTM funcionan incorrectamente?Respuestas:
En respuesta a su pregunta de comentario "cómo simular este algoritmo":
Esta es una solución bastante bruta, pero fácil de implementar y debería ofrecer un buen rendimiento:
Luego, verifique si la carpeta existe en la estructura de datos de Sentinel 2. Si es así, has terminado, ¡hurra!
De lo contrario, verifique las cuadrículas UTM vecinas y vea si el mosaico / carpeta "FR" existe en ellas. Dado que hay superposiciones en todas partes, debería verificar todas las 8 cuadrículas circundantes.
El orden más probable para verificar sería 13S, 13Q, 12R, 14R, 12S, 14S, 12Q, 14Q.
Los últimos cuatro podrían ser relevantes si sus coordenadas se encuentran en las esquinas de una zona UTM, pero son altamente improbables.
Dada la forma en que Sentinel2 etiqueta los mosaicos, solo uno de los vecinos debería tener dicha carpeta, lo que garantiza que obtenga el archivo correcto.
Cualquier otra solución geográficamente más "correcta" implicaría una carga computacional mucho mayor de lo que creo se justifica aquí.
Y definitivamente, definitivamente informe esto al equipo de la ESA como lo sugiere Kersten en los comentarios. Realmente no entiendo por qué eligieron un sistema organizativo tan innecesariamente complicado.
fuente
Publicación relacionada aquí
Lo que me ha funcionado es utilizar el KML S2 proporcionado por ESA para calcular todos los mosaicos que se cruzan con mi AOI, y luego buscar estos mosaicos en AWS.
Este KML parece funcionar como una definición de todos los identificadores de mosaico posibles generados por S2, eliminando muchas opciones superpuestas.
Al mirar el KML (solo inspección visual, no 100% seguro) me parece que en el peor de los casos tendrías que buscar 4 mosaicos.
Sería bueno tener el algoritmo que ESA usó para definir el KML para hacerlo más eficiente.
fuente