Más

Conversión de mapas ráster de Ordnance Survey en mosaicos de mapas web WGS84

Conversión de mapas ráster de Ordnance Survey en mosaicos de mapas web WGS84


Me gustaría generar mosaicos de mapas similares a Google / Bing a partir de mapas ráster 1: 25000 y 1: 50000 de Ordnance Survey, que se proporcionan como mosaicos de cuadrícula nacionales de 4000x4000 del Reino Unido (GeoTIFF).

Puede encontrar un mosaico de muestra en http://www.ordnancesurvey.co.uk/docs/sample-data/25k-raster-sample-data.zip.

Gracias a este sitio y a otros (esta es la primera vez que uso las herramientas GIS adecuadas), he logrado utilizar gdalwrap para reproyectar los mosaicos y gdal_retile.py para cortar el mosaico reproyectado en trozos más pequeños.

Todavía tengo las siguientes preguntas:

  1. los archivos de origen usan un mapa de color, por lo que, según mi muestra de un solo mosaico, lo convertí a un color de 24 bits para poder usar un algoritmo de remuestreo mejor que el vecino más cercano, pero no sé qué tan escalable será para todo el Reino Unido. ¿Hay alguna forma de obtener un remuestreo de calidad sin convertir primero a color de 24 bits?

  2. ¿Cómo consigo gdalwrap o gdal_retile.py (u otra utilidad) para alinear los mosaicos generados con la cuadrícula del mapa web (el mundo dividido en 2 ^ mosaicos de zoom de igual lat-lon delta)? En este momento, mis mosaicos tienen el tamaño de píxel correcto, pero lo más probable es que no estén alineados con la cuadrícula lat-lon ni con el nivel de zoom.

  3. los mosaicos generados por gdal_retile.py se nombran de acuerdo con la ubicación de cada uno en el archivo de origen, pero necesito traducir eso al número de mosaico global para mi nivel de zoom. ¿Las herramientas admiten hacer eso sobre la marcha o necesito posprocesar?

  4. el uso de gdal_retile.py con la opción -levels genera subdirectorios, pero los mosaicos son todos negros; Esperaba la pirámide alejada (y menos mosaicos, no más, que el nivel predeterminado), ¿debería usar una opción diferente?

  5. incluso para esta muestra más pequeña, cada comando parece tomar un tiempo excesivamente largo, y esto es en una MacPro y SSD octo-core. ¿Existe una guía de desempeño para GDAL?

Esto es lo que he estado haciendo, comenzando con el archivo de muestra sx99.tif:

pct2rgb.py sx99.

En lugar de gdal_retile.py, he intentado usar gdal2tile.py en los mapas ráster preformados.

Sin embargo, aunque la coordenada X para cada uno de los mosaicos generados es correcta, la coordenada Y parece ser al menos el doble de lo que esperaba.

Intenté configurar explícitamente el SRS de origen y el perfil de destino, sin ningún efecto.

gdal2tiles.py sx99_24b_warped.tif

No puedo entender qué va mal. La imagen intermedia deformada se ve bien:

$ gdalinfo sx99_24b_warped.tif Controlador: GTiff / GeoTIFF Archivos: sx99_24b_warped.tif El tamaño es 4074, el sistema de coordenadas 4085 es: PROJCS ["WGS 84 / Pseudo-Mercator", GEOGCS ["WGS 84", DATUM ["WGS_1984", SPHEROID [ "WGS 84", 6378137,298.257223563, AUTHORITY ["EPSG", "7030"]], AUTHORITY ["EPSG", "6326"]], PRIMEM ["Greenwich", 0], UNIT ["grado", 0.0174532925199433] , AUTORIDAD ["EPSG", "4326"]], PROYECCIÓN ["Mercator_1SP"], PARAMETER ["central_meridian", 0], PARAMETER ["scale_factor", 1], PARAMETER ["false_easting", 0], PARAMETER [" false_northing ", 0], UNIT [" meter ", 1, AUTHORITY [" EPSG "," 9001 "]], EXTENSION [" PROJ4 "," + proj = merc + a = 6378137 + b = 6378137 + lat_ts = 0.0 + lon_0 = 0.0 + x_0 = 0.0 + y_0 = 0 + k = 1.0 + unidades = m + nadgrids = @ null + wktext + no_defs "], AUTHORITY [" EPSG "," 3857 "]] Origen = (-396511.819462091429159,6584391.706861065700650) Tamaño de píxel = (3.948971656093984, -3.948971656093984) Metadatos: AREA_OR_POINT = Estructura de la imagen del área Metadatos: INTERLEAVE = PIXEL Coordenadas de la esquina: Superior izquierda (-396511.819, 6584391.707) (3d33'42.93 "W, 50d47'27 .29 "N) Inferior izquierda (-396511.819, 6568260.158) (3d33'42.93" W, 50d41'57.18 "N) Superior derecha (-380423.709, 6584391.707) (3d25 '2.66" W, 50d47'27.29 "N) Inferior derecha ( -380423.709, 6568260.158) (3d25 '2.66 "W, 50d41'57.18" N) Centro (-388467.764, 6576325.932) (3d29'22.80 "W, 50d44'42.32" N)

Pero los archivos resultantes están en el rango de (para el nivel de zoom 11): 1003 <= x <= 1004 y 1359 <= y <= 1360, donde esperaba y alrededor de 780…


Con respecto a los tiempos de ejecución: Lanczos es extremadamente lento, pero otros algoritmos de remuestreo producen resultados similares (quizás incluso mejores):

  • cerca (11s)
  • bilineal (17 s)
  • promedio (27 s, un poco suave)
  • bicúbico (30 años, llamadocúbicoen GDAL, el grosor del texto a veces es extraño)
  • antialias (45 años, requiere pil y numpy)
  • cubicspline (1m53s, demasiado suave)
  • lanczos (11m8s, extremadamente lento)

En mi opinión, el resultado de antialias es el mejor compromiso, e incluso sin intentar usar varios núcleos, mi computadora de escritorio debería poder procesar todo el Reino Unido en aproximadamente 48 horas.


gdal2tiles utiliza el punto de origen inferior izquierdo, no el superior izquierdo, por lo que el patrón de nombre de archivo es{zoom} / {x} / {tilenum-y} .png ">


Pruebe MapTiler (http://www.maptiler.com/).

El instalador para Mac OS X está disponible después de completar el formulario http://www.maptiler.com/demo/, y puede arrastrar y soltar GeoTIFF directamente (no haga VRT, solo ralentizan el proceso de renderización de mosaicos).

Aquí hay un video tutorial: https://youtu.be/WQbX4dqlHgY

Vea un ejemplo de mapa de mosaico ampliable de todo el Reino Unido hecho de Ordnance Survey OpenData: http://os.tileserver.com/.

(Por cierto, también puede obtener de nosotros los MBTiles)