Migrar una automatización de Zapier o Make a un nuevo host de geocodificación
Las automatizaciones sin código basadas en un paso de geocodificación necesitan un enfoque de migración distinto al del código propio. Así puedes gestionar ese cambio.
Alojar tú mismo Nominatim frente a usar un host compatible (drop-in) alojado
Alojar Nominatim por tu cuenta es un camino legítimo y bien documentado, y muchas organizaciones lo hacen con éxito, sobre todo las que tienen motivos sólidos para mantener la infraestructura de geocodificación íntegramente dentro de su propia red. Pero la contrapartida es real y conviene decirla con claridad en lugar de pasarla por alto: asumes la descarga e importación de un extracto de datos de OpenStreetMap, la provisión de suficiente espacio en disco y memoria para atender las consultas a una velocidad aceptable, mantener esos datos razonablemente actualizados a medida que OpenStreetMap se actualiza, y operar el servidor con las garantías de disponibilidad que necesite tu aplicación.
Nada de eso es difícil en el sentido de ser oscuro o estar mal documentado. Es difícil en el sentido de ser continuo. Una instancia de Nominatim alojada por tu cuenta que funcionaba bien el día de su lanzamiento puede perder vigencia un año después si nadie ha programado el proceso de actualización, y diagnosticar por qué una dirección concreta dejó de coincidir correctamente exige entender tanto el software de Nominatim como las convenciones de los datos de OpenStreetMap que tiene debajo.
Un reemplazo compatible (drop-in) alojado elimina por completo esa capa operativa, a cambio de hacer pasar tu tráfico de geocodificación por la infraestructura de un tercero en lugar de la tuya, que es la decisión real que se toma aquí, no una cuestión de que una opción sea simplemente mejor.
El host de compatibilidad con Nominatim de My Geocode reproduce la estructura de respuesta exacta que devuelve una instancia de Nominatim pública o alojada por tu cuenta, con display_name, lat y lon como cadenas, y un objeto de dirección que usa los propios nombres de campo de OpenStreetMap, como suburb y postcode; solo cambian los textos de copyright, términos y privacidad. Los detalles de referencia están en /compatibility/nominatim/. El código escrito para una instancia alojada por tu cuenta solo debería necesitar un cambio de host y de autenticación, ya que la estructura de campos se mantiene.
Algunas preguntas que conviene responder con sinceridad antes de elegir cualquiera de los dos caminos:
- ¿Tiene tu organización un motivo concreto de cumplimiento normativo o de residencia de datos que el alojamiento propio satisface y un servicio alojado no?
- ¿Cuánto tiempo de ingeniería se dedica actualmente a mantener la instancia propia, y cuánto valdría ese tiempo dedicado a otra cosa?
- ¿Es tu volumen de tráfico lo bastante alto y estable como para que los costes de infraestructura ya estén justificados, o fluctúa de una manera que un coste predecible por solicitud o por suscripción gestiona mejor?
Si la respuesta apunta a abandonar la infraestructura propia, la autenticación en el lado alojado usa una clave enviada como X-API-Key, Authorization: Bearer, autenticación HTTP Basic o un parámetro de consulta, en sustitución de la política de uso basada en el User-Agent que espera una instancia pública de Nominatim. Los precios incluyen 2.500 solicitudes gratuitas al día sin clave, 2.500 gratuitas más por clave y día contadas por red, y después crédito prepago a 0,0001 € por solicitud o una clave Unlimited a 50 € al mes, la misma tarifa que cualquier otro endpoint de la plataforma. Para muchos equipos, comparar los costes de servidor, el tiempo de mantenimiento de ingeniería y el volumen de solicitudes con estos precios es la forma más rápida de resolver la cuestión en un sentido u otro.