He heredado un portal web (interno) bastante grande/complejo (ejecutado bajo python 2.6.6), que tiene algunas capacidades de mapeo, usando Mapnik 2.2.0. El servicio web ha empezado recientemente a lanzar errores 500 cuando intenta crear algunos de los mapas que se muestran, con el único error:
$ Premature end of script headers: app.wsgi
Los mapas se generan a partir de geojson que se pasa como una cadena (habiendo sido creado a partir de un diccionario de python); he rastreado hasta 1 línea de código en un map.py
que añade una capa a un mapa:
data = mapnik.Ogr(file=json, layer='OGRGeoJSON')
cuando comento esa línea de código (y la asociada m.layers[-1].data = data
) entonces la imagen se muestra en el portal, pero obviamente sin esta capa. El json es válido (lo he comprobado en http://geojsonlint.com ).
Esfuerzos de depuración
Usar un archivo json separado
Quería ver si al llamar al JSON desde una fuente externa se reproducía el problema. Por lo tanto, guardé la cadena json como un archivo separado ( test.json
), en el mismo directorio que map.py
y modificó el Ogr
llamar a
data = mapnik.Ogr(file='test.json', layer='OGRGeoJSON')
Todavía recibo un error 500, pero con un mensaje de error un poco más verboso:
datasource = mapnik.Ogr(file='testgeo.json', layer='OGRGeoJSON')
File /usr/lib64/python2.6/site-packages/mapnik/__init__.py, line 536, in Ogr
return CreateDatasource(keywords)
RuntimeError: OGR Plugin: Failed to read GeoJSON data
Comprobación del geojson
$ ogrinfo testgeo.json
ERROR 4: GeoJSON Driver doesn't support update.
Had to open data source read-only.
INFO: Open of `testgeo.json'
using driver `GeoJSON' successful.
1: OGRGeoJSON (3D Polygon)
Así que el json parece válido
Uso de la línea de comandos de Python
También he probado a ejecutar python de forma interactiva en el mismo directorio que map.py
y test.json
:
$ python
Python 2.6.6 (r266:84292, Jul 23 2015, 15:22:56)
[GCC 4.4.7 20120313 (Red Hat 4.4.7-11)] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import mapnik
>>> mapnik.Ogr(file="testgeo.json", layer="OGRGeoJSON")
<mapnik.Datasource object at 0x7f6243c27398>
Más información
$ gdal-config --version
1.9.2
$ ogr2ogr --version
GDAL 1.9.2, released 2012/10/08
Esto devuelve sin errores (así que asumo que esto significa que el geojson es válido, confirmando mi prueba anterior de ejecutar el geojson a través de http://geojsonlint.com ):
$ ogr2ogr testgeo.shp testgeo.json
Versión del SO
$ lsb_release -a
LSB Version: :base-4.0-amd64:base-4.0-noarch:core-4.0-amd64:core-4.0-noarch:graphics-4.0-amd64:graphics-4.0-noarch:printing-4.0-amd64:printing-4.0-noarch
Distributor ID: CentOS
Description: CentOS release 6.7 (Final)
Release: 6.7
Codename: Final
Estos 3 esfuerzos de depuración muestran que el json es válido y que la llamada funciona, excepto cuando se ejecuta a través del webstack. He comprobado los permisos y la propiedad de todos los archivos y directorios relevantes, y todos parecen ser como yo esperaba.
¿Qué otra cosa podría estar causando el problema?
Actualización (2 semanas después de hacer la pregunta original)
Hoy he llegado al trabajo y he pensado en volver a mirar para ver si puedo sacar algunos mensajes de error (nueva semana, nuevo comienzo). Pero, extrañamente, el código no parece fallar (por ahora, al menos). He cambiado nada y, por lo que he podido comprobar, no ha habido cambios de hardware en los servidores.
Esto se convierte ahora en una investigación de lo que hizo causarlo, y si hay algo que pueda hacer para evitar que vuelva a ocurrir...
0 votos
No soy desarrollador pero a primera vista veo alguna diferencia en la definición de sintaxis OGR de los datos json (por ejemplo ' ' ' en lugar de ' " '). Además recuerdo que la extensión de archivo soportada por OGR es ".geojson" en lugar de ".json". Espero que os pueda ayudar en algo
0 votos
Desgraciadamente, cuando utilizo un archivo externo hace funcionan (independientemente de la extensión del archivo); es cuando el json está incrustado en el python como una cadena que ahora ha dejado de funcionar
0 votos
¿Has comprobado que utilizas la misma versión de python/ scripts mapnik para ejecutar mapnik.Ogr en la línea de comandos y en tu webstack? ¿Tal vez hay una implementación diferente y una actualización podría ayudar?
0 votos
Sí, es Mapnik 2.2.0 y Python 2.6.6 en todos los casos
0 votos
Es
file
¿una ruta relativa? Tal vez el directorio de trabajo del servidor está en otro lugar y por eso no lo encuentra, podrías intentar añadir el parámetrobase="/home/geojsonfolder"
a lamapnik.Ogr
llame a0 votos
@chrki Lo he intentado y sigue sin funcionar. Dado que no funciona tanto cuando el json es una cadena como cuando es un archivo, imagino que la ubicación de un archivo no es el problema
0 votos
¿Quizás podrías intentar ejecutar ogrinfo (o se llama gdalinfo ?) en el archivo geojson, y ver si eso arroja algún error/advertencia?
0 votos
@til_b He añadido la salida de ese comando en mi pregunta
0 votos
Bastante raro. No tengo una instalación de mapnik en este momento para comprobarlo. ¿has comprobado el rastreador de problemas de mapnik, para ver si es un error conocido y hay una solución documentada? no se me ocurre nada más.
0 votos
@George Yeh, he echado un vistazo a los problemas de github... :/
1 votos
¿Cuál es el sistema operativo en el que se está desplegando? Una vez tuve un error raro por culpa de los permisos. Esta era la estructura aproximada: carpeta A > carpeta B (donde B es hijo de A). Entonces, había dado todos los permisos a la carpeta B, pero no a la A. Como la A no era accesible al proceso, todo lo demás fallaba (había usado -R como opción). Si no me equivoco, esto fue en RHEL. Vuelve a comprobar que, tal vez, sea una cosa.
0 votos
@George OS información añadida a la pregunta
0 votos
CentOS debería tener/comportarse de manera similar. ¿Puedes comprobar lo que he sugerido en el comentario anterior?
0 votos
@George todas las carpetas del entorno web son 755, y tienen el mismo propietario
0 votos
Secundo la preocupación por los permisos: sólo porque la carpeta tenga 755/el mismo propietario, ¿qué pasa con ese archivo en particular? Esto es especialmente sospechoso si el archivo ha sido modificado o reemplazado poco antes de que se produzca este error.
0 votos
Además, puede ver el registro de errores de Apache en tiempo real si utiliza este comando:
sudo tail -f /var/log/apache2/error.log
La idea es, disparar ese comando en una ventana de terminal, luego tratar de solicitar la capa a través de su aplicación; ver lo que aparece en el registro.0 votos
@elrobis El archivo definitivamente tiene los permisos correctos también (Mi pregunta dice que ya había comprobado eso)
0 votos
@elrobis los únicos errores que aparecen en el archivo de registro son los que he puesto en mi pregunta
0 votos
De forma totalmente extraña, al intentarlo de nuevo esta mañana ha funcionado. He cambiado nada :/ por lo que puedo averiguar, no ha habido ningún cambio de hardware en el servidor