Category Archives: Operaciones

Publicaciones relacionadas con la administración de hardware y sistemas. Todo lo relacionado con el Grupo de Trabajo de Operaciones

Un año de progreso en infraestructuras: Informe del Ingeniero de Fiabilidad del Sitio 2023/2024

Como Ingeniero Senior de Fiabilidad del Sitio (SRE) de la Fundación OpenStreetMap, el año pasado me centré dentro del Equipo de Operaciones de OpenStreetMap en impulsar la eficiencia, mejorar la resistencia y ampliar nuestra infraestructura para apoyar el crecimiento continuo del proyecto OpenStreetMap. Desde la migración a la nube hasta la actualización de los servidores, hemos realizado varias mejoras desde el año pasado para posicionar mejor la infraestructura de OpenStreetMap y hacer frente a estos retos de resistencia y crecimiento.

Mejorar los servicios de cara al usuario

Servicios de renderizado mejorados

La infraestructura de renderizado de teselas ha experimentado notables mejoras, como optimizaciones de hardware y software, una caducidad más rápida de la caché de teselas para hacer frente al vandalismo, y la automatización para bloquear a los usuarios no atribuidores. Ahora a diario volvemos a renderizar las teselas de zoom bajo, lo que mejora el rendimiento y permite un bucle de retroalimentación al mapeador más rápido. El servicio de teselas se utiliza mucho y mantener la demanda es un reto continuo.

Nuevo servicio de imágenes aéreas

Lanzamos un nuevo servicio de imágenes aéreas compatible con COGs GeoTIFF. El servicio aloja ahora aerial.openstreetmap.org.za, respaldado por 16 TB de imágenes de alta resolución. El nuevo servicio facilita el alojamiento de imágenes adicionales en el futuro.

Transición a la alternativa de Gmail y mitigación del spam

Tras enfrentarme a importantes problemas de spam con el espacio de trabajo de Google de OSMF, migré los servicios de correo electrónico de OSMF a mailbox.org. Esto ha reducido el volumen de spam y ha mejorado la eficiencia administrativa. También estamos en el proceso de transición de los datos históricos de Google Docs de OSMF a un servicio autoalojado.

Hacer frente a los ataques DDoS y al vandalismo

Este año nos hemos enfrentado a varios ataques de denegación de servicio distribuido (DDoS), incluido un importante incidente de DDoS para pedir rescate, del que se informó a las fuerzas de seguridad. Estos ataques pusieron a prueba nuestra infraestructura, pero hemos aplicado medidas para reforzar nuestra resistencia y protegernos mejor contra futuras amenazas.

También hicimos frente al vandalismo a gran escala que afectó a los servicios de OpenStreetMap. Gracias a la rápida respuesta y a los ajustes realizados por el equipo de Operaciones, hemos reforzado nuestra infraestructura para gestionar mejor los abusos y garantizar un servicio continuo.

Alojamiento de Planet Data en AWS S3

Junto con el Equipo de Operaciones de OpenStreetMap, he trasladado nuestro alojamiento de datos de planetas a AWS S3 con réplicas tanto en la UE como en EE.UU., lo que nos ha permitido restablecer por completo el catálogo retrospectivo de datos históricos. A través del patrocinio OpenData de AWS, los diffs de replicación y los datos planetarios son ahora más accesibles.

Facilitar la gestión de los sistemas

Gestión completa de la infraestructura de AWS con OpenTofu

Con el Equipo de Operaciones de OpenStreetMap he migrado con éxito todos los recursos de AWS gestionados manualmente a la Infraestructura como Código (IAC) utilizando OpenTofu (antes Terraform). Esta transición nos ha permitido mejorar la rentabilidad, aumentar la seguridad adoptando un modelo IAM de mínimo privilegio y obtener una mejor visibilidad de los gastos mediante etiquetas de facturación detalladas. Además, hemos integrado S3 Storage Analytics para optimizar aún más nuestros costes, hemos configurado copias de seguridad adicionales y hemos implementado reglas de ciclo de vida mejoradas.

Alerta mejorada de interrupción del servicio

Hemos implementado alertas por SMS para las interrupciones críticas del servicio, junto con una cuenta patrocinada de PagerDuty. Estas mejoras garantizan tiempos de respuesta más rápidos y una mejor coordinación durante las interrupciones, y se está trabajando en la integración completa con Prometheus/Alertmanager y Statuscake.

Reducción de la Deuda Técnica

Este año hemos avanzado en la reducción de la deuda técnica trasladando varios servicios heredados a soluciones más fáciles de mantener. Por ejemplo, hemos puesto en contenedores servicios antiguos, como los sitios web del Estado del Mapa, que antes funcionaban con instalaciones de WordPress mal mantenidas. Esta transición ha mejorado la escalabilidad, la seguridad y el mantenimiento a largo plazo de estos servicios.

Además, sustituimos nuestra instalación de código personalizado de OTRS por una instalación del paquete Znunyde Debian. Este cambio simplifica las actualizaciones y reduce la carga de mantenimiento, garantizando que el sistema permanezca actualizado y seguro sin modificaciones personalizadas.

Garantizar la resistencia de la infraestructura a pesar de los fallos del hardware

El año pasado mantuvimos una infraestructura resistente incluso ante fallos de hardware. Sustituimos numerosos discos y RAM, garantizando una interrupción mínima de los servicios. Nuestro sistema de supervisión a medida nos permite detectar señales tempranas de fallos de hardware, lo que nos permite actuar con rapidez y sustituir los componentes defectuosos antes de que causen problemas importantes. Este enfoque proactivo ha sido clave para mantener el tiempo de actividad y la fiabilidad del sistema.

Mejora de las infraestructuras

Replicación entre sitios de las copias de seguridad

Para garantizar una sólida recuperación de desastres, he establecido una replicación entre cuentas y regiones para las copias de seguridad de AWS S3, lo que permite una recuperación puntual. Esto salvaguarda los datos y servicios críticos, incluso ante fallos graves, proporcionando tranquilidad a largo plazo.

Infraestructura de alta disponibilidad

Las actualizaciones de hardware clave en nuestras sedes de Ámsterdam, Dublín y OSUOSL mejoraron el rendimiento, la capacidad de almacenamiento y la fiabilidad de la red. En 2022 se instalaron nuevos conmutadores, y ahora hemos terminado de establecer una configuración de alta disponibilidad (HA) para garantizar un mejor servicio, que hemos seguido mejorando pasando a enlaces ascendentes diversos duales con nuestro ISP para mejorar la capacidad de recuperación.

Migración a Debian

Estamos migrando de Ubuntu a Debian 12 (Bookworm) como nuestra distribución estándar. Todos los servidores nuevos funcionan ahora con Debian. Nuestra gestión de configuración de chefs se ha actualizado con código de prueba para garantizar la compatibilidad permanente. Esta transición marca un cambio hacia una mayor estabilidad y seguridad a largo plazo. Post de Mastodon celebrando la transición.

De cara al futuro

El año que tenemos por delante nos brinda nuevas y emocionantes oportunidades a medida que avanzamos. Las prioridades clave para 2024 / 2025 incluyen:

Involucramiento

Compromiso con la Comunidad y Comunicación Exterior: Aumentar la colaboración con el Grupo de Trabajo de Comunicación (GTC) y mejorar nuestra comunicación de cara al público sobre el estado del servicio y los cortes.

Mejorar la documentación y la incorporación: Mejoraremos la documentación de incorporación y realizaremos sesiones específicas para ayudar a los nuevos colaboradores a participar en las operaciones más fácilmente. Esto incluye mejorar la fiabilidad y la cobertura de nuestros procesos de prueba, garantizando contribuciones más fluidas y reduciendo la curva de aprendizaje para los nuevos miembros del equipo.

Planificar y optimizar

Planificación de la capacidad para el crecimiento de la infraestructura: A medida que OpenStreetMap y la demanda de nuestros servicios crezcan, nos aseguraremos de que podemos escalar para satisfacer la demanda. Al anticiparnos a las necesidades futuras y equilibrar el rendimiento con un crecimiento rentable, pretendemos mantener la calidad y disponibilidad del servicio que espera nuestra comunidad.

Optimización continua de los costes: Seguiremos buscando formas de reducir costes aprovechando patrocinios como el programa AWS OpenData, garantizando operaciones sostenibles.

Seguir reduciendo la deuda técnica: Seguiremos simplificando nuestra infraestructura reduciendo la carga de mantenimiento de los sistemas heredados, por ejemplo aumentando el uso de contenedores. Esto ayudará a agilizar las tareas de gestión y nos permitirá centrarnos en otras mejoras, haciendo que la infraestructura sea más eficiente y escalable con el tiempo.

Seguir mejorando las infraestructuras

Implantación de equilibradores de carga de alta disponibilidad: Despliegue de la configuración HA (VRRP + LVS + DSR) de los equilibradores de carga para mejorar la fiabilidad del sistema y reducir los posibles tiempos de inactividad.

Finalización de la integración de Prometheus con PagerDuty: Finalización de la integración de Prometheus para la supervisión y PagerDuty para agilizar las alertas y la respuesta a incidentes.

Completar la transición a un entorno Debian completo: Migrar todos los servicios restantes de Ubuntu a Debian para aumentar la estabilidad y la seguridad.

Mejorar las estrategias de recuperación y copia de seguridad en caso de catástrofe: Perfeccionando nuestra documentación de recuperación e introduciendo medidas adicionales de copia de seguridad en todos los servicios críticos están protegidos y son recuperables en caso de fallo.

Cierre de OAuth 1.0a y HTTP Basic Auth en OpenStreetMap.org

En 2024, el Grupo de Trabajo de Operaciones (OWG) de la OSMF retirará OAuth 1.0a y HTTP Basic Auth en OpenStreetMap.org. Estas son formas técnicas para que las aplicaciones autentiquen a los usuarios con el sitio web o API de OSM. OAuth 1.0a y HTTP Basic Auth han quedado obsoletos desde 2023, ya que OAuth 2.0 es ahora el método de autorización estándar para la mayoría de los sistemas.

Hay tres fechas clave en el proceso de transición:

  • 1 de marzo de 2024: Se deshabilitaron los nuevos registros de aplicaciones OAuth 1.0a. Las aplicaciones existentes no se vieron afectadas. HTTP Basic Auth no se vio afectado.
  • 1 de mayo de 2024: los administradores del sistema iniciarán caídas de tensión para encontrar aplicaciones que todavía usan OAuth 1.0a o HTTP Basic Auth.
  • 1 de junio de 2024: OAuth 1.0a y HTTP Basic Auth se cerrarán.

Es necesario retirar estos métodos de autenticación debido a motivos de seguridad y a la complejidad de mantener tantas implementaciones de autorización, incluidas aquellas que dependen de componentes no mantenidos.

¿Cómo me afecta esto como desarrollador?

Si eres desarrollador de una aplicación que utiliza OAuth 1.0a o HTTP Basic Auth para iniciar sesión en el sitio web OpenStreetMap.org, es posible que debas realizar algunos cambios para migrar a OAuth 2.0. Afortunadamente, este es un estándar industrial bien respaldado.

Si su aplicación solo realiza llamadas de lectura a la API, la autorización es opcional. Para fines de limitación de tráfico, sigue siendo una buena idea agregar autorización a sus solicitudes, pero no es obligatorio. Si su aplicación es un sitio web que utiliza OSM para iniciar sesión, utilizar OAuth 2.0 es mucho más fácil, pues tiene un soporte mucho mejor debido a que muchos otros sitios lo usan. También evita problemas como que los usuarios terminen con muchos tokens en su lista en el sitio web.

Si estás desarrollando software que edita mediante la API y se ejecuta localmente, es posible que debas realizar cambios en el código. Todos los lenguajes comunes tienen bibliotecas que manejan OAuth 2 y las bibliotecas son la opción preferida para cualquier autorización. También puedes usar la biblioteca de Zverik para herramientas de línea de comandos, o escribir tu propio shell script de aproximadamente una docena de líneas.

Deberías poder encontrar muchos ejemplos en línea de implementaciones de clientes OAuth 2 en tu idioma. Si deseas obtener información más detallada o hacer preguntas técnicas, utilice el ticket de GitHub. Aquí, el OWG también rastrea las aplicaciones que requieren modificaciones para usar OAuth 2.0.

¿Cómo me afecta esto como mapeador?

La mayoría de mapeadores no notarán ningún cambio. La transición no afectará la forma en que inicias sesión en tu cuenta OSM ni en la que utilizas el sitio web. iD y JOSM han admitido OAuth 2.0 como método de autenticación predeterminado desde hace algún tiempo. Si utilizas tu cuenta OSM para iniciar sesión en un sitio de terceros como HOT Tasking Manager, MapRoulette o HDYC, no te verás afectado porque esos sitios ya se han migrado a OAuth 2.0. El acceso a la API en modo solo lectura no requiere autorización alguna.

La Fundación OpenStreetMap es una organización sin fines de lucro, formada para apoyar el Proyecto OpenStreetMap. Se dedica a fomentar el crecimiento, desarrollo y distribución de datos geoespaciales gratuitos para que cualquiera pueda usarlos y compartirlos. La Fundación OpenStreetMap posee y mantiene la infraestructura del proyecto OpenStreetMap, está financiada por cuotas de membresía y donaciones, y organiza la conferencia anual internacional State of the Map. Nuestros grupos de trabajo voluntarios y nuestro pequeño personal central trabajan para apoyar el proyecto OpenStreetMap. Únete a la Fundación OpenStreetMap por solo £ 15 al año o gratis si eres un colaborador activo de OpenStreetMap.

Impulsando el futuro de OpenStreetMap: Un año de mejoras del ingeniero de fiabilidad del sitio de la Fundación OpenStreetMap

Hace poco más de un año, me uní a la Fundación OpenStreetMap (OSMF) con el objetivo de mejorar la fiabilidad y seguridad de la tecnología y la infraestructura que sustenta OpenStreetMap. A lo largo del año pasado, he trabajado estrechamente con el Grupo de Trabajo de Operaciones, un equipo dedicado de voluntarios. Juntos, hemos logrado un progreso significativo en la mejora de nuestros procesos y documentación, fortaleciendo en última instancia nuestra eficacia colectiva. Estoy inmensamente agradecido por el apoyo y la colaboración dentro de este grupo, y estoy encantado de presenciar los notables avances que hemos dado en la construcción de una base sólida para el futuro de OpenStreetMap.

Entraré en un poco de detalle a continuación sobre lo que se ha hecho. A un alto nivel, facilité la administración de la implementación del software que se ejecuta en nuestros servidores; fortalecí nuestra infraestructura de red a través de una mejor redundancia, monitoreo, acceso y documentación; aumenté nuestro uso de servicios en la nube para la representación de teselas, aprovechando un generoso patrocinio de AWS; mejoré nuestras prácticas de seguridad; actualicé nuestros entornos de desarrolladores; y por último, pero definitivamente no menos importante, finalicé la migración de 16 años de contenido de nuestros antiguos foros a nuestros nuevos foros.

Si quieres saber más de mí en el transcurso del trabajo del año pasado, echa un vistazo a mi charla en State of the Map 2022 y mi entrevista en el podcast GeoMob. Y me encantaría saber de ti, envíame un correo electrónico a osmfuture@firefishy.com.

Detalles de confiabilidad del sitio 2022-2023

Gestión de software en nuestros servidores

Pequeños Componentes de infraestructura en contenedores (GitHub Actions for building)

He puesto en contenedores muchos de nuestros sitios pequeños que se construyeron previamente utilizando métodos a medida en nuestra base de código de chef como parte de la configuración de “Configuración como código”. Se movieron los pasos de compilación a Github Actions. Configuré una base para cualquier proyecto futuro basado en contenedores (“docker”) en el futuro. Estos son nuestros primeros proyectos basados en contenedores / docker alojados en la infraestructura OSMF.

Nuestro código basado en chef ahora es más simple, más seguro y se implementa más rápido.

Pruebas de chef mejoradas (documentación de incorporación de operaciones)

Utilizamos chef.io para la gestión de la infraestructura (configuración) de todos nuestros servidores y el software utilizado en ellos. Durante el último año, las pruebas de cocina del chef test se han extendido y ahora también funcionan en las modernas máquinas Apple Silicon. Las pruebas ahora se ejecutan de manera confiable como parte de nuestros procesos de CI / PR. Las pruebas agregan control de calidad y garantía a los cambios que hacemos. El soporte ARM fue más fácil de agregar porque podíamos usar la cocina de prueba antes de pasar al hardware del servidor ARM.

Tener pruebas confiables debería ayudar a incorporar nuevos colaboradores del chef.

Se reforzó nuestra infraestructura de red

Network Upgrades @ AMS (Nuevos switches, enlaces redundantes duales, Dublín pronto)

Nuestra configuración de red en Ámsterdam no era tan redundante como debería haber sido. El equipo Cisco Small Business que utilizamos se nos había quedado pequeño. Tuvimos cortes de energía inesperados debido a problemas de hardware. El equipo también estaba limitando futuras actualizaciones. El grupo de operaciones decidió reemplazar el hardware con equipos Juniper que habíamos estandarizado en el centro de datos de Dublín. Reemplacé el equipo con un tiempo de inactividad mínimo en un entorno en vivo (<15 minutos).

Los centros de datos de Dublín y Ámsterdam ahora utilizan una configuración estandarizada y más segura. Cada servidor ahora tiene enlaces totalmente vinculados para mejorar la redundancia y el rendimiento. Los switches han mejorado la potencia y la redundancia de la red. Estamos esperando la instalación de los enlaces ascendentes totalmente resistentes (pedido enviado) en el próximo mes.

Acceso fuera de banda a ambos centros de datos (basado en 4G)

Construí e instalé dispositivos de acceso fuera de banda en cada sitio. Los dispositivos están cableados a equipos de red y administración de energía mediante consolas seriales. Los dispositivos fuera de banda tienen un enlace 4G resistente a una red 4G privada (1NCE). Los dispositivos de acceso fuera de banda son Raspberry PI personalizadas con fuentes de alimentación redundantes y 4 conectores seriales.

Documentación de Infraestructura para facilitar el mantenimiento (Racks / Power)

Documenté cada unidad rack, puerto de alimentación (Power Distribution Unit), conexión de red y cable en los centros de datos. Esto facilita la administración de los servidores, reduce los errores y nos permite instruir adecuadamente a las manos remotas (proveedor de soporte externo) para que realicen cualquier cambio en nuestro nombre.

Oxidized (visibilidad de equipos de red)

Nuestra configuración de red y distribución de energía ahora se almacena en git y se informan los cambios. Esto mejora la visibilidad de cualquier cambio, lo que a su vez mejora la seguridad.

La configuración se supervisa continuamente y cualquier desviación de configuración entre nuestros sitios ahora es mucho más fácil de resolver.

Infraestructura Terraform como Código (mejorar la gestión / repetibilidad)

Terraform es una herramienta de infraestructura como código, ahora la usamos para administrar nuestro servicio de monitoreo remoto (statuscake) y estoy en el proceso de implementarlo para administrar nuestra infraestructura de AWS y Fastly.

Anteriormente, todos estos componentes se administraban manualmente utilizando las respectivas interfaces de usuario web. La infraestructura como código permite al equipo de operaciones trabajar colaborativamente en los cambios, mejora la visibilidad y la repetibilidad / reversión de cualquier cambio.

Gestionamos todos los dominios DNS utilizando el código dnscontrol. Se han realizado mejoras incrementales durante el último año, incluida la adición de pruebas de IC para mejorar la colaboración externa.

Aumentó nuestro uso de servicios en la nube

AWS en uso para la infraestructura de representación. Optimización de los costos de AWS. Seguridad mejorada. Copia de seguridad mejorada. Más en trámite

El equipo de operaciones ha ido aumentando lentamente nuestro uso de AWS en los últimos años. He creado varias cuentas de AWS específicas de uso utilizando un modelo de organización de AWS para mejorar la facturación y la seguridad según las directrices de prácticas recomendadas de AWS. Recibimos generosamente el patrocinio de AWS para expandir nuestra infraestructura de renderizado. Creamos la nueva infraestructura de renderizado experimental con la arquitectura ARM con AWS Graviton2 EC2.
No hemos usado anteriormente servidores basados en ARM. Como parte de las mejoras en nuestro chef (configuración como código) habíamos agregado soporte de pruebas locales para Apple Silicon (ARM), solo se requirieron pequeñas adiciones para agregar la compatibilidad requerida para los servidores ARM al chef.

Nos impresionó el rendimiento de las instancias EC2 de AWS Graviton2 para ejecutar la pila de representación de teselas de OSM. También probamos el escalado bajo demanda y la creación de instantáneas de instancias para posibles mejoras adicionales de la pila de render en AWS.
Hemos aumentado nuestro uso de AWS para la copia de seguridad de datos.

Mejoramos nuestra seguridad

Durante el último año se han realizado una serie de mejoras generales de seguridad. Por ejemplo: El acceso al servidor ahora es a través de clave ssh (el acceso con contraseña ahora está deshabilitado). También hemos pasado de un administrador de contraseñas basado en gpg a medida para el equipo de operaciones a usar gopass (versión rica en funciones de https://www.passwordstore.org/), GoPass mejora la administración de claves y el uso compartido del almacén de contraseñas.

Además, también hemos mejorado el bloqueo de nuestras instancias de WordPress al reducir los componentes instalados, deshabilitar las actualizaciones en línea y deshabilitar el acceso XMLRPC. También estamos trabajando para reducir los usuarios con acceso y eliminar los permisos de acceso no utilizados.

Áreas clave documentadas de vulnerabilidad que requieren mejoras (redundancia, seguridad, etc.)

Documentación sobre vulnerabilidad técnica: Estoy elaborando un informe sobre áreas clave de vulnerabilidad que requieren mejoras (Redundancia, Seguridad, etc.). El documento se puede utilizar para enfocar la inversión en el futuro para reducir aún más nuestra exposición a los riesgos.

Hemos renovado nuestros entornos de desarrollo

Nuevo servidor de desarrollo

Hemos migrado todos los usuarios de desarrollo a un nuevo servidor de desarrollo en el último año. El servidor antiguo había terminado su vida útil (~ 10 años) y estaba alcanzando límites de capacidad (CPU y almacenamiento). El nuevo servidor se entregó directamente al centro de datos de Ámsterdam, se instaló físicamente con manos remotas y comuniqué la migración, y luego migré todos los usuarios y proyectos.

Subversion retirada

Retiré nuestro viejo repositorio de código svn.openstreetmap.org el año pasado. El repositorio de código se utilizó desde el inicio del proyecto, y contenía un rico historial de desarrollo de código en el proyecto. Convertí el repositorio de código svn a git usando una configuración de reposurgeon personalizada, se prestó atención a mantener el historial de contribuciones completo y vincular correctamente a los contribuyentes anteriores (350+) a las respectivas cuentas de github y relacionadas. Los antiguos enlaces svn se mantuvieron y ahora enlazan al archivo en github https://github.com/openstreetmap/svn-archive.

Migración del foro

En la migración del antiguo foro migramos 1 millón de publicaciones y 16 años de publicaciones a discourse. Todas las publicaciones se convirtieron de fluxbb markdown a la versión de markdown de discourse. Todas las cuentas se fusionaron y la autenticación se convirtió a OpenStreetMap.org “inicio de sesión único” basado en auth.

Todos los enlaces antiguos del foro redirigen (enlace al importado) para corregir el contenido. Usuarios, categorías (países, etc.), temas de hilo y publicaciones individuales.

¿Puedes ayudar al Grupo de Trabajo de Operaciones?

Imagen de Dorothea Kazazi, CC-BY-SA 3.0
Logotipo de OSM por Ken Vermette, CC-BY-SA 3.0 y se aplican las marcas registradas.

El Grupo de Trabajo de Operaciones de OSM es un grupo de voluntarios, responsable del funcionamiento de los servidores propiedad de la Fundación OpenStreetMap. 
Siempre estamos dispuestos a encontrar nuevos miembros y buscamos especialmente a personas que:

  • puedan analizar nuestra infraestructura de servidores
  • hacer planes
  • prever las futuras necesidades de hardware
  • elaborar presupuestos

Esto implica un cierto nivel de conocimientos técnicos, pero no se trata de escribir código, por ejemplo, y ser miembro del OWG no da acceso a ninguno de los servidores: eso es cosa de nuestros administradores de sistemas. Si quieres unirte a nosotros, lee nuestra política de afiliación y ponte en contacto con nosotros.

Alguna información adicional:

  • Los principales canales de comunicación del OWG son Github y el correo electrónico. Rara vez tenemos reuniones.
  • Estimación de horas por semana: 1-3

Envíanos un correo electrónico a operations@osmfoundation.org
También estamos en Twitter @OSM_Tech

Si tienes los conocimientos técnicos y la experiencia para ser administrador de sistemas, lee nuestra política de afiliación de administradores de sistemas y ponte en contacto con nosotros.

OSM Grupo de Trabajo de Operaciones

¿Quieres traducir éste y otros artículos del blog a tu idioma? Envíanos un correo electrónico a communication@osmfoundation.org con el asunto Ayudar con traducciones en [your language]

La página Fundación OpenStreetMap es una organización sin ánimo de lucro, creada en el Reino Unido para apoyar el Proyecto OpenStreetMap. Se dedica a fomentar el crecimiento, desarrollo y distribución de datos geoespaciales gratuitos para que cualquiera los use y comparta. La Fundación OpenStreetMap posee y mantiene la infraestructura del proyecto OpenStreetMap, recibe apoyo financiero de las cuotas de membresía y donaciones y organiza anualmente la conferencia State of the Map. No tiene empleados a tiempo completo y apoya el proyecto OpenStreetMap a través del trabajo de nuestros Grupos de Trabajo voluntarios. Considera la posibilidad de hacerte miembro de la Fundación OSM.

OpenStreetMap se fundó en 2004 y es un proyecto internacional para crear un mapa libre del mundo. Para hacerlo, nosotros, miles de voluntarios, recopilamos datos sobre carreteras, ferrocarriles, ríos, bosques, edificios y mucho más en todo el mundo. Todos pueden descargar nuestros datos de mapas de forma gratuita y utilizarlos para cualquier propósito, incluido el uso comercial. Es posible producir sus propios mapas que resaltan ciertas características, calcular rutas, etc. OpenStreetMap se utiliza cada vez más cuando uno necesita mapas que se pueden actualizar muy rápida o fácilmente.

Nuevo servidor de teselas en Pau, Francia

Gracias a las generosas donaciones y a los miembros activos de la comunidad OpenStreetMap, la infraestructura de OpenStreetMap sigue creciendo.

Un nuevo servidor de teselas, Lurien, se ha añadido a la red de caché de teselas de OSM. Ubicado en Pau, Pyrénées-Atlantiques, Francia, actualmente, Lurien ofrece servicios a direcciones IP de Francia, España, Portugal, Andorra, Gibraltar, Italia, Mónaco, San Marino y el Vaticano.

Lurien, destacado.

Las teselas de mapas se envían a los usuarios en función de su ubicación GeoDNS. La Fundación OpenStreetMap busca servidores de teselas distribuidos adicionales. Si deseas donar un servidor de teselas y alojamiento, consulta la página de requisitos de teselas CDN en la wiki.

Nos gustaría agradecer a PauLLAcon el apoyo de la Université de Pau et des Pays de l’Adour (UPPA) por el servidor y la conectividad, y a Communauté d’Agglomération de Pau Pyrénées (CDAPP) por el alojamiento del centro de datos. También nos gustaría agradecer al colaborador de OpenStreetMap Christophe Merlet por gestionar la donación.

La Fundación OpenStreetMap es una organización sin fines de lucro, formada en el Reino Unido para apoyar el Proyecto OpenStreetMap. Su objetivo es fomentar el crecimiento, el desarrollo y la distribución de datos geoespaciales gratuitos y proporcionar datos geoespaciales para que cualquier persona los utilice y comparta. La Fundación OpenStreetMap posee y mantiene la infraestructura del proyecto OpenStreetMap. Puedes apoyar a OpenStreetMap donando a la Fundación OpenStreetMap.