Esto no significa necesariamente que vayamos a cancelar nuestras suscripciones hoy mismo. La propuesta de valor de Gemma 4 es, sobre el papel, ayudarnos a ahorrar tokens de nuestras cuentas de pago y ganar privacidad en tareas mecánicas o procesamiento de datos locales. En este post, vamos a comprobar si realmente es capaz de actuar como un agente operativo configurándolo con LM Studio y OpenCode.

El Fundamento: ¿Qué significan los números?

Al buscar Gemma 4, verás nomenclaturas como "26B A4B". Descifrarlas es vital para no bloquear tu máquina:

• Los Parámetros (B): La "B" significa Billions (miles de millones). Son las variables que el modelo ajustó durante su entrenamiento. A más parámetros, mayor capacidad de razonamiento.

• Arquitectura MoE (Mixture of Experts): El modelo 26B A4B tiene 26 mil millones de parámetros totales, pero solo activa 4 mil millones (Active) por cada token generado. Obtienes la inteligencia de un modelo grande con la velocidad de uno pequeño, aunque necesitas RAM para alojar los 26B enteros.

El Formato: GGUF vs MLX

• GGUF: El estándar universal. Es el formato más común para Windows o Linux. Su gran ventaja es el GPU Offloading: si el modelo no cabe entero en tu tarjeta gráfica (VRAM), GGUF permite que la CPU ayude con el trabajo sobrante de forma transparente.

• MLX: El "traje a medida" para Apple Silicon. Si tienes un Mac (M1 a M4), el formato MLX es superior. Está diseñado por Apple para aprovechar la memoria unificada, permitiendo que la CPU y la GPU compartan datos instantáneamente sin cuellos de botella. Es más rápido y eficiente que cualquier otro formato en esta arquitectura.

Cuantización: ¿Por qué hablamos de "Bits"?

Los pesos originales de un modelo ocupan mucha memoria (16 bits). Cuantizar es reducir esos bits para que el modelo quepa en hardware doméstico:

• 8 bits: Casi sin pérdida de inteligencia, pero pesado.

• 4 bits (Q4_K_M): El estándar de oro. El modelo ocupa una cuarta parte del original con una pérdida mínima de razonamiento. Siempre que puedas, apunta a este nivel.

• 2 bits: El modelo se vuelve "torpe" y pierde coherencia lógica. Solo como último recurso.

Licencia Apache 2.0: Un cambio de paradigma

Uno de los aspectos más disruptivos de Gemma 4 no es técnico, sino legal. Históricamente, modelos como Llama o las versiones previas de Gemma utilizaban licencias personalizadas de "pesos abiertos" que imponían restricciones de uso comercial o límites de usuarios.

Gemma 4 rompe con esto al adoptar la licencia Apache 2.0. A diferencia de los modelos anteriores que eran "abiertos pero con condiciones", Apache 2.0 es una licencia permisiva de software libre real. Esto permite a cualquier desarrollador o empresa modificar, distribuir y usar el modelo con mayor libertad.

Más allá del chat: Gemma 4 en Modo Agente

Aquí es donde Gemma 4 brilla frente a sus predecesores. Ha sido diseñada con soporte nativo para function-calling y flujos de trabajo agénticos. Mientras que en LM Studio solo tienes un chat, herramientas como OpenCode permiten que Gemma 4 actúe como un agente de codificación.

¿Qué es OpenCode?

OpenCode es un agente de código abierto para tu terminal o IDE que puede leer tus archivos, ejecutar comandos de shell y aplicar correcciones automáticamente. No solo te da el código; crea el archivo, lo prueba y lo itera hasta que funciona.

Configuración del entorno (paso a paso)

Para tener este flujo de trabajo, necesitamos conectar ambas herramientas:

En LM Studio:

• Descarga Gemma 4 26B A4B (o la versión E4B si tienes poca RAM).

• Ve a la pestaña de Local Server y actívalo en el puerto 1234.

• Asegúrate de subir el GPU Offload al máximo y ajustar el contexto a un mínimo de 32K.

En OpenCode:

Configura el archivo opencode.json para que apunte a tu servidor local:

"lmstudio": {
  "name": "LM Studio",
  "npm": "@ai-sdk/openai-compatible",
  "options": {
    "baseURL": "http://localhost:1234/v1",
    "apiKey": "lm-studio"
  },
  "models": {
    "gemma-4-e2b": {
      "name": "Gemma 4 Local (LM Studio)"
    }
  }
}

Ahora, desde tu terminal, puedes lanzar comandos como: opencode "refactoriza este componente usando hooks de React" y el agente usará a Gemma 4 para realizar la tarea directamente en tu sistema de archivos.

Aunque sobre el papel todo parece sencillo, suele haber un problema con estas configuraciones. Le pides a opencode que haga algo usando gemma 4 y en lugar de esa acción te entrega un mensaje diciendo como se hace. Las herramientas no se terminan de entender entre sí. Raro en informática verdad?.

¿Qué es la parálisis del modelo?

Aunque Gemma 4 está entrenada para actuar como agente, su entrenamiento de refuerzo (RLHF) a menudo prioriza ser un "asistente servicial de chat". Ante una orden como "lista los archivos", el modelo puede caer en la parálisis de explicar en lugar de ejecutar. Te dirá "Para ver los archivos deberías usar ls" en lugar de emitir el comando técnico que OpenCode necesita procesar.

El System Prompt como Protocolo Operativo

Para romper esta inercia, debemos configurar un System Prompt en LM Studio que actúe como un "contrato de ejecución". No le estamos enseñando capacidades nuevas; le estamos indicando qué rol operativo debe asumir en este flujo de trabajo, por ejemplo:

"Eres un asistente de programación integrado en el terminal mediante OpenCode. Obligatorio: Para cualquier acción que requiera el sistema (leer archivos, listar directorios, ejecutar comandos), utiliza siempre el formato de herramientas de OpenCode. No te limites a escribir el comando, ejecútalo."

Este prompt garantiza que el modelo pase del modo "consultor" al modo "ejecutor", emitiendo las señales JSON correctas para que OpenCode actúe sobre tu sistema de archivos.

Conclusión

Gemma 4 es el primer modelo abierto que realmente permite un desarrollo local-first con capacidades agénticas algo serias. Pero seamos realistas, no se puede comparar con los servicios por API de los big players. Es una buena alternativa para no gastar tokens en tareas sencillas. Y Evidentemente, si tienes que trabajar con datos sensibles o necesitas privacidad y trabajar en local, aunque sea limitado, puede ser una gran ayuda.

Esto abre posibilidades interesantes, además, para explorar técnicas de trabajo con IA sin quemar el presupuesto de tokens. Eso sí, no esperes que te permita olvidarte de tus suscripciones actuales, porque las tareas que vas a poder delegar todavía están limitadas. Toca probarla a fondo y ver hasta dónde llega.

La alternativa más eficiente hoy en día es el uso de modelos de lenguaje locales. Gracias a la integración entre Ollama y el proyecto CLI OpenCode, es posible ejecutar un asistente potente directamente en tu máquina, sin costes de suscripción y con total privacidad.

1. Verificación de hardware: ¿Qué puedes ejecutar?

El primer paso para trabajar en local es conocer la capacidad real de tu equipo. No necesitas una estación de trabajo de última generación para tareas de código básicas, pero sí un mínimo de recursos para que la experiencia sea fluida.

Una herramienta muy recomendable para esto es canirun.ai. Este sitio analiza tus especificaciones técnicas (especialmente la memoria RAM y la VRAM de tu tarjeta gráfica) y te indica qué modelos podrás ejecutar.

2. El equilibrio entre potencia y ligereza

Para tareas de automatización y ayuda en el código, la regla general es que un modelo a partir de 7 mil millones de parámetros (7B) suele ser el punto de equilibrio ideal. Son lo suficientemente inteligentes para entender lógica de programación y lo bastante ligeros para correr rápido en hardware doméstico moderno.

En mi caso personal, estoy utilizando actualmente Qwen 2.5 Coder 7B. Para generar pequeños scripts de Python o comparar ficheros JSON de gran tamaño, su respuesta es casi instantánea y la precisión es sorprendente. No obstante, dependiendo de tu hardware (si tienes más de 32GB de RAM o una GPU potente), podrías escalar a modelos de 14B o 32B si buscas un razonamiento más profundo.

3. Configuración simplificada: El comando "mágico"

Aunque OpenCode permite una configuración manual detallada, la forma más rápida y limpia de conectar tus modelos locales con el asistente es utilizar el puente directo que ofrece Ollama.

Una vez tengas instalado Ollama y hayas descargado tu modelo preferido (por ejemplo, con ollama pull qwen2.5-coder), solo tienes que ejecutar:

ollama launch opencode

Este comando es clave porque automatiza toda la configuración: detecta tu instancia local, establece las variables de entorno necesarias y lanza la interfaz de OpenCode lista para trabajar. Evitas así tener que configurar manualmente proveedores externos o servicios en la nube, manteniendo todo el flujo 100% local.

4. Casos de uso ideales

¿Cuándo merece la pena usar este setup en lugar de una IA comercial? Principalmente en tareas de "baja complejidad pero alta fricción":

• Manipulación de archivos: "Crea un script que renombre todos los .txt de esta carpeta a .md y les añada la fecha actual".
• Comparación lógica: "Analiza estos dos directorios y dime qué funciones faltan por sincronizar".
• Limpieza de datos: "Tengo este CSV mal formateado, genera un script para normalizar las columnas".

Conclusión

La combinación de OpenCode y Ollama no solo es una cuestión de ahorro de costes (que también), sino de agilidad y privacidad. Al delegar las tareas más pesadas y repetitivas a un modelo local de 7B, liberas tu presupuesto de tokens para problemas realmente complejos y mantienes un flujo de trabajo en la terminal mucho más dinámico.

Este post, más largo de lo habitual, nace de una necesidad personal: la de poner en orden mis propias notas, investigaciones y aprendizajes. Al final, escribir es la mejor forma que conozco de estructurar las ideas y separar el grano de la paja. Mi intención con esta serie no es venderte la última herramienta de moda, sino bajar a tierra lo que está pasando y cómo podemos entender esta tecnología sin que nos explote la cabeza.

Ni magia, ni robots: Solo computación y patrones

A veces parece que hay una especie de "niebla" mental sobre la IA. Parece que estamos ante un oráculo o un cerebro consciente. Lo que veíamos en las películas se ha hecho realidad, y tenemos entre nosotros un Skynet o HAL de verdad. Pero si abrimos el capó y miramos los engranajes, la realidad es mucho más terrenal.

En esencia, la IA es software diseñado para imitar capacidades humanas, pero con una diferencia fundamental respecto al desarrollo tradicional. Si un programa clásico es una receta rígida donde yo, como programador, defino que "si pasa A, haz B", la IA es un aprendiz de patrones. No necesita que le dé todas las reglas por escrito; ella misma encuentra las regularidades en los datos. Pero ojo, no "piensa". Es pura estadística aplicada a una escala masiva.

¿Por qué ahora?

Algo que solemos ignorar es que las redes neuronales no son una novedad de hace dos años. La idea de imitar las conexiones sinápticas para procesar datos es una teoría que ya se manejaba en los años 50. Entonces, ¿por qué no tuvimos este "boom" hace décadas?

Para que estas redes neuronales "despertaran", han necesitado dos ingredientes que solo coinciden ahora:

• Datos masivos: Internet se ha convertido en el campo de entrenamiento más grande de la historia.
• Hardware (GPUs): Necesitábamos chips capaces de hacer billones de operaciones por segundo. La receta ya estaba escrita, pero hasta hace poco no teníamos el horno lo bastante potente para cocinarla.

¿Qué es un LLM en realidad?

Los modelos de lenguaje que usamos hoy son redes neuronales gigantescas entrenadas para una sola tarea: adivinar la siguiente palabra.

• Si escribes "El cielo está...", la red neuronal ha procesado tanta información que sabe que la palabra más probable es "azul".
• No es que "entienda" el concepto de cielo, es que es un maestro de la probabilidad estadística gracias a esa capacidad de computación masiva.

Hasta hace nada, la IA se dedicaba a clasificar: te decía si un correo era spam o si en una foto aparecía un gato. Era IA discriminativa. Lo que ha cambiado las reglas del juego es la IA Generativa.

Como su nombre indica, su superpoder es crear contenido nuevo. Ha pasado de organizar carpetas a ser capaz de redactar un texto, generar una imagen desde cero o, lo que a muchos nos interesa, escribir una función de código que funciona a la primera. No es que "sepa" lo que hace, es que sabe qué palabra o píxel tiene más probabilidades de ir después del anterior.

Los tres pilares de lo que puede generar:

1. Texto (LLMs): Como ya vimos, son redes neuronales maestras en la probabilidad. No solo escriben poemas; pueden programar software, resumir libros o traducir idiomas captando los matices culturales, no solo palabra por palabra.
2. Imagen y Arte Visual: Modelos como Midjourney o DALL-E han aprendido la relación entre las palabras y los píxeles. Saben qué aspecto tiene la "luz de atardecer" o el "estilo cyberpunk" y pueden construir una imagen desde cero (píxel a píxel) a partir de una frase.
3. Multimodalidad (El presente): Esto es lo más nuevo y potente. Es la capacidad de la IA para saltar entre formatos. Por ejemplo, una IA que puede "ver" una foto de tu nevera y "escribir" una receta con lo que hay dentro, o una IA que "escucha" un audio y lo convierte en un vídeo.

¿Qué NO es la IA?

• No es un buscador como Google: Un buscador te lleva a una web; una IA genera una respuesta nueva combinando lo que sabe.
• No tiene sentimientos: Si te pide perdón por un error, no es porque esté arrepentida, es porque ha aprendido que "lo siento" es la respuesta socialmente correcta en esa situación.
• No es infalible: Puede equivocarse (y mucho). Es una herramienta de apoyo, no una verdad absoluta.

Cómo aprende una máquina?

Imagina que quieres enseñarle a un niño a distinguir entre un perro y un gato. No le das un manual de 500 páginas sobre anatomía felina; simplemente ve un perro y le dices: "Esto es un perro", ve un gato y le dices "Esto es un gato". Aprende por repetición y asociación.

Con la IA pasa exactamente lo mismo:

1. Entrenamiento: Le "alimentamos" con millones de ejemplos (textos, fotos, códigos).
2. Patrones: La máquina nota que los gatos suelen tener orejas puntiagudas y los perros hocicos más largos.
3. Predicción: Cuando le enseñas una foto nueva, no "sabe" qué es, pero dice: "Hay un 98% de probabilidades de que esto sea un gato".

El espejo humano: El sesgo que nos complica la vida

Aquí entra un tema que me parece clave para entender por qué a veces nos frustramos con estas herramientas. En los años 60, Joseph Weizenbaum creó ELIZA, un chatbot básico que imitaba a un terapeuta. Weizenbaum lo programó para imitar a un terapeuta rogeriano (una técnica de psicología que consiste en devolverle al paciente sus propias palabras).

• Si tú decías: "Me duele la cabeza".
• ELIZA buscaba las palabras clave y respondía: "¿Por qué dices que te duele la cabeza?".

Se quedó horrorizado al ver que la gente se abría emocionalmente con la máquina, creyendo que los entendía.

Tenemos una tendencia innata a humanizar la tecnología (antropomorfismo). Si algo nos responde con lenguaje fluido, nuestro cerebro asume que "hay alguien ahí". Nos enfadamos con el chat o le hablamos con rodeos. El problema es que, al tratarla como a un humano, perdemos la especificidad operativa. Olvidamos que estamos ante una herramienta de cálculo y no ante un oráculo.

Para sacarle partido de verdad a la IA, el primer paso es romper ese espejo: menos charla y más instrucciones precisas. No pienses que "entiende" tu problema, cuando en realidad sólo está haciendo estadística avanzada para darte la respuesta más probable. Entender esto es la clave para saber como sacarle partido, tratándola como lo que es: una herramienta.

Capítulo 2. El Diccionario de Supervivencia

En el post anterior hablábamos de que la IA no es magia, sino computación y patrones. Pero para movernos con soltura en este ecosistema y, sobre todo, para no frustrarnos cuando las cosas no salen como esperamos, necesitamos hablar el mismo idioma que la máquina.

Para manejar la IA con criterio, no basta con saber qué botones pulsar. Necesitas entender los mecanismos que definen su comportamiento. Si ignoras estos conceptos, estarás usando la herramienta a ciegas.

1. El Token: La unidad de medida

La IA no procesa palabras completas como nosotros; trocea el texto en tokens. Un token puede ser una palabra corta, una sílaba o incluso un signo de puntuación.

¿Por qué te importa? Porque todo en este mundo se mide en tokens: desde la capacidad de respuesta hasta lo que te cobran por las APIs. Si entiendes que la IA "trocea" la información, entenderás por qué a veces le cuesta tanto contar letras de una palabra o hacer rimas perfectas: ella no ve letras individuales, ve bloques de datos.

2. La Ventana de Contexto: No es un pozo sin fondo

Este es, probablemente, el concepto más crítico. La Ventana de Contexto es la "memoria de trabajo" o la capacidad de atención de la IA en una sola sesión. Imagina que es una mesa de escritorio: cuando la mesa se llena, para poner un papel nuevo tienes que tirar uno de los que ya estaban.

• El peligro del truncamiento: Si le pasas un PDF de 200 páginas a una IA que solo tiene capacidad para 50, la IA no te avisará de que no llega. Simplemente cortará el texto sobrante. Tú creerás que ha analizado todo el archivo, pero la información del final (donde quizás estaba la conclusión o la cláusula clave) será invisible para ella.

• La pérdida en el medio: Incluso si el texto cabe, se ha demostrado que la IA recuerda mejor el principio y el final de lo que lee. Los detalles que quedan enterrados en el centro del documento suelen diluirse.

3. Embeddings: El carnet de identidad de tus datos

Si la Ventana de Contexto es nuestra "mesa de trabajo", los Embeddings son el sistema de archivado inteligente que nos permite no saturarla.

Para que una IA entienda la relación entre las ideas, utiliza estos "embeddings": una lista de números (vectores) que sitúa cada frase en un mapa gigante de miles de dimensiones. Para entenderlo como desarrolladores, bajémoslo a un ejemplo de solo 3 coordenadas: [¿Es software?, ¿Es una base de datos?, ¿Es un animal?]

• "PostgreSQL" → [0.9, 0.9, 0.0] (Mucho software, mucha DB, nada animal).
• "MySQL" → [0.9, 0.8, 0.0] (Coordenadas casi idénticas; están "pegados" en el mapa).
• "Delfín" → [0.0, 0.0, 0.9] (Vive en un barrio matemático totalmente distinto).

¿Por qué te importa esto en la práctica? Piensa en cuando subes un PDF a una IA. La IA no "lee" las 200 páginas cada vez que le preguntas algo. Lo que hace es:

1. Trocear el PDF en párrafos.
2. Generar el embedding (las coordenadas) de cada párrafo.
3. Cuando preguntas algo, busca qué trozos del PDF tienen las coordenadas más parecidas a tu duda y solo le pasa esos trozos a la Ventana de Contexto.

Es la base de lo que llamamos RAG: buscar por "sentido común" matemático para ahorrar tokens y ganar precisión.

4. Alucinaciones: Cuando la probabilidad falla

La IA Generativa es una máquina de predecir la siguiente palabra más probable. No tiene una base de datos de "verdades".

• El riesgo: Como está diseñada para ser coherente y elocuente, cuando no sabe algo, "rellena" el vacío con información que suena muy profesional pero que es falsa. No te miente por maldad; simplemente está cumpliendo su función de completar texto basándose en patrones.

• Mi consejo: Nunca la uses como fuente primaria para datos biográficos, leyes o fechas. Úsala para procesar datos que tú le entregues, no para que ella te los traiga de fuera.

5. Parámetros: El tamaño del "cerebro"

Seguro que has oído que X modelo tiene "billones de parámetros". Un parámetro es, básicamente, una conexión ajustable en la red neuronal (como los cables en un cuadro de conexiones).

• Más parámetros suelen significar más matices, mejor comprensión de la ironía y más "sabiduría" generalista.

• Sin embargo, un modelo con menos parámetros pero mejor entrenado (con datos de mayor calidad) puede ser mucho más eficaz para tareas específicas, como programar, y además será mucho más rápido y barato.

6. Temperatura: ¿Robot o Artista?

Aunque a veces está oculto en la interfaz, la mayoría de los modelos tienen un ajuste de Temperatura.

• Temperatura baja (Cercana a 0): La IA es conservadora y previsible. Es el modo "ingeniero": ideal para código, resúmenes técnicos o datos.

• Temperatura alta (Cercana a 1): La IA se arriesga más, elige palabras menos probables. Es el modo "creativo": ideal para lluvia de ideas o escribir ficción.

7. El RAG: ¿Cómo aprende la IA sobre tus datos?

Seguramente has probado herramientas como NotebookLM o le has subido un PDF a ChatGPT y te has sorprendido: de repente, la IA sabe todo sobre ese documento técnico de 50 páginas y sus respuestas se "acotan" estrictamente a lo que pone ahí. No se inventa cosas de internet, se centra en tus datos.

¿Cómo es posible? ¿Ha "estudiado" la IA tu documento y se lo ha aprendido para siempre? No. Lo que estás viendo en acción es una técnica llamada **RAG (Retrieval-Augmented Generation

Para entender el RAG, olvida la idea de que la IA "aprende". Imagina que la IA es un profesor superdotado que sabe de todo, pero al que le pides que haga un examen sobre un proyecto tuyo que él nunca ha visto.

1. Sin RAG (Entrenamiento): Sería como obligar al profesor a memorizar tu proyecto antes del examen. Es costoso, lento y, si mañana cambias una frase del proyecto, el profesor ya tiene información obsoleta en su cabeza.

2. Con RAG: Es como si el profesor fuera al examen con tus apuntes en la mano. No necesita memorizarlos; simplemente, cuando le haces una pregunta, él busca rápidamente en los apuntes, lee el párrafo relevante y te responde usando su inteligencia pero basándose solo en lo que pone el papel.

¿Cómo funciona el RAG por dentro?

Cuando subes ese PDF, el sistema hace tres cosas en milisegundos:

• Recuperación (Retrieval): Gracias a los Embeddings (los "carnets de identidad numéricos" que vimos antes), el sistema sabe qué párrafos de tu PDF están matemáticamente cerca de tu pregunta. Si preguntas por el "presupuesto", el sistema localiza instantáneamente la página donde están las cifras.

• Aumento (Augmentation): El sistema coge esos párrafos y los "pega" en un prompt invisible para ti que dice: "Aquí tienes estos fragmentos de texto. Úsalos como única fuente de verdad".

• Generación (Generation): La IA redacta la respuesta. Sigue usando su "cerebro" (su entrenamiento previo) para entender el lenguaje y redactar bien, pero los datos los saca exclusivamente de los fragmentos que le acabas de pasar.

¿Por qué herramientas como NotebookLM parecen "acotarse" tanto?

Te habrás fijado en que si le preguntas a NotebookLM algo que no está en tus archivos, a veces te dice: "No puedo responder porque esa información no aparece en los documentos".

Esto no es porque la IA se haya vuelto "tonta" o haya olvidado lo que sabía. Es porque el sistema RAG tiene una instrucción de seguridad muy estricta: priorizar siempre el libro que tiene abierto. Esto es lo que nos da la seguridad de que la IA no va a "alucinar" o inventarse datos basándose en información genérica de internet.

Capítulo 3. El Traductor Universal

Si has seguido los posts anteriores, ya tienes claro que la IA no es un oráculo, sino un procesador de patrones. Pero aquí es donde la cosa se pone interesante: ¿Cómo es posible que un "Modelo de Lenguaje" (LLM) sea capaz de escribir una función en Python, diseñar un mapa web en Leaflet o generar una imagen de un astronauta a caballo?

La respuesta corta es que, para una IA, todo es lenguaje. Pero vamos a desglosarlo un poco mejor, porque entender esto es lo que te permite pasar de "jugar" con la IA a usarla como una herramienta de ingeniería real.

1. El código como arquitectura lógica

Para nosotros, programar es crear lógica. Para un LLM, aprender a programar no ha sido muy distinto a aprender inglés o gallego. El código tiene una sintaxis, una gramática y, sobre todo, una estructura previsible.

La IA ha sido entrenada con casi todo el código público que existe (pensemos en el volumen de datos de GitHub). Lo que hace no es "entender" informática, sino entender la secuencia lógica. Sabe que después de un if suele venir una condición y, tras ella, una indentación con una instrucción. Al ser un entorno tan rígido y con reglas tan claras, a la IA le resulta más fácil ser precisa programando que escribiendo poesía.

2. ¿Por qué algunos modelos programan mejor que otros?

No es que unos sean "más listos" que otros, es una cuestión de dieta de datos.

• Los generalistas: Han leído de todo, incluyendo tutoriales obsoletos y código basura de foros olvidados. Por eso a veces te sugieren soluciones que "huelen" a 2010.

• Los especialistas (Fine-tuning): Son modelos que han pasado por un "posgrado". Se les ha entrenado específicamente con repositorios de alta calidad y se les ha refinado mediante humanos que les dicen: "Esta solución funciona, pero esta otra es más eficiente y segura". Es la diferencia entre un aprendiz y un senior.

3. Imágenes y Vídeo: Traduciendo palabras a píxeles

Aquí es donde ocurre lo que llamamos multimodalidad. Al principio, esto era como un juego de teléfonos descompuestos: tenías un modelo que entendía el texto y le pasaba la orden a otro que generaba la imagen.

Hoy, los modelos más potentes son nativos multimodales. Desde el minuto uno de su entrenamiento, han visto imágenes y han leído sus descripciones simultáneamente. Han aprendido que el concepto lingüístico "atardecer" está vinculado a ciertos patrones de color y degradados de píxeles. Ya no "traducen" de un idioma a otro; entienden el mundo en ambos formatos de forma nativa.

4. La trampa del dibujo: ¿Por qué la IA no sabe cuántos dedos tiene una mano?

Seguro que has visto esas imágenes con manos de seis dedos. Esto explica perfectamente por qué la IA no tiene un modelo mental de la realidad. Ella no sabe qué es una "mano" ni para qué sirve; solo sabe que en las fotos etiquetadas como "mano" suele haber formas alargadas de color carne. Si estadísticamente el patrón es confuso, el resultado visual también lo será.

5. ¿Por qué unos modelos son más rápidos que otros?

A veces te encuentras con modelos que parecen un rayo y otros que escriben a paso de tortuga. Esto depende del número de parámetros (el tamaño del "cerebro") y del hardware que tengan detrás.

• Modelos Flash/Mini: Pocos parámetros, muy rápidos, ideales para tareas sencillas.

• Modelos de razonamiento: Son deliberadamente más lentos porque están programados para "pensar antes de hablar", verificando sus propios pasos lógicos internamente.

Entender que la IA es un motor de razonamiento estadístico cambia la forma en la que le pides las cosas. Si le pides código, dale la estructura. Si le pides una imagen, describe los patrones. No estás hablando con un artista ni con un colega senior; estás interactuando con un traductor universal de patrones que es tan bueno como la información con la que lo alimentas.

Capítulo 4. Instrucciones operativas (Prompting)

Si has llegado hasta aquí, ya sabes que la IA no te "entiende" en el sentido humano de la palabra; lo que hace es procesar una instrucción y calcular la respuesta más probable basándose en su entrenamiento. Por eso, el "arte" de dar instrucciones (que algunos llaman pomposamente Prompt Engineering) no consiste en ser educado, sino en ser meticuloso.

En mi día a día con el código o los mapas, si una consulta SQL no devuelve lo que quiero, no me enfado con la base de datos; reviso la sintaxis. Con la IA hay que aplicar la misma mentalidad.

1. Rompe el espejo: De la conversación a la instrucción

El mayor error es tratar el chat como una charla de café. Escribir "Oye, ¿sería posible que quizás me ayudaras a resumir esto si no es mucha molestia?" solo añade ruido innecesario a la ventana de contexto.

La IA no necesita cortesía, necesita parámetros. Pasa de la "charla" a la instrucción operativa. Sé directo. Usa verbos de acción: "Resume", "Analiza", "Escribe", "Extrae".

2. La anatomía de un prompt profesional

Para que una instrucción sea robusta, yo suelo usar una estructura de tres capas:

• Rol (¿Quién eres?): Dile a la IA cómo debe comportarse. No es lo mismo pedirle algo a un "asistente genérico" que a un "ingeniero senior experto en PostgreSQL". Definir el rol acota el "espacio" de donde la IA sacará la información.

• Contexto y Tarea (¿Qué hacemos?): Sé específico. En lugar de "haz un resumen", usa "resume los 3 puntos clave de este texto técnico para un cliente que no sabe de tecnología".

• Formato de salida (¿Cómo lo quiero?): Define el output. ¿Quieres un JSON? ¿Una tabla Markdown? ¿Un párrafo de 50 palabras? Si no lo defines, la IA elegirá por ti, y probablemente no sea lo que necesitas.

3. La técnica de la "Cadena de Pensamiento"

Como vimos en el post anterior, algunos modelos programan mejor porque "piensan" antes de hablar. Tú puedes forzar ese comportamiento en cualquier modelo usando una técnica sencilla: pídele que razone paso a paso.

Si le lanzas un problema complejo de golpe, es más fácil que alucine. Si le dices: "Analiza el problema, desglósalo en pasos lógicos y, finalmente, dame la solución", la probabilidad de éxito aumenta drásticamente. Estás obligando a la red neuronal a seguir un camino lógico trazable.

4. El "Few-Shot": Enseñar con ejemplos

A veces, una descripción no basta. Si quieres que la IA escriba con un estilo concreto o clasifique datos de una forma específica, dale ejemplos.

• Ejemplo 1: Entrada -> Salida.
• Ejemplo 2: Entrada -> Salida.
• Ahora tú: Entrada -> ...

Es la forma más rápida de que la IA capte el patrón que buscas sin tener que escribir un manual de instrucciones infinito que sature los tokens de la sesión.

5. Itera: El prompt perfecto no existe a la primera

En el desarrollo de software, raramente algo funciona a la primera versión. Con el prompting es igual.

• Si el resultado es demasiado largo, pide que lo recorte.
• Si es muy técnico, pide que baje el nivel.
• Si ha olvidado una parte, es posible que hayas superado la ventana de contexto o que la instrucción fuera ambigua.

Dominar el prompting no es aprenderse "fórmulas mágicas", es aprender a comunicarte con una máquina de forma estructurada. Es, en esencia, volver a ser un poco artesano de la palabra para obtener resultados de ingeniería.

Capítulo 5. Las Herramientas de Desarrollo de Software

Si eres de los que, como yo, empezó usando la IA solo para preguntarle cómo centrar un div o para que te explicara una función compleja de PostgreSQL, tengo que decirte que te estás quedando en la superficie. En los últimos meses, el ecosistema ha dado un salto gigante: hemos pasado de "hablar con la IA" a "integrar la IA en nuestro entorno de desarrollo".

Como ingeniero, siempre busco soluciones que resuelvan problemas reales. Y aquí el problema real es la fricción: copiar código del chat, pegarlo en el editor, ver que falla porque la IA no conoce mi base de datos, y volver a empezar. Para resolver esto, han aparecido tres conceptos clave: Agentes, Skills y el protocolo MCP.

El Agente: El "Cerebro" con iniciativa

Un chat normal es pasivo: tú preguntas, él responde. Un Agente es un modelo de lenguaje al que le hemos dado un objetivo y autonomía para usar herramientas.

• Diferencia clave: Si le pides a un chat "arregla este bug", te dará el código. Si se lo pides a un Agente, él leerá el archivo, ejecutará el código para ver el error, buscará una solución y aplicará el parche.

• En resumen: Es un LLM que puede ejecutar un ciclo de: Pensar -> Actuar -> Observar el resultado.

MCP: El protocolo que lo cambia todo

Hace poco escribí en el blog sobre cómo conectar PostgreSQL a un agente de IA mediante MCP (Model Context Protocol). 

• ¿Qué es? Es un estándar abierto que permite que cualquier IA se conecte de forma segura a tus datos locales.

• ¿Para qué sirve? En lugar de copiar y pegar el esquema de tu base de datos en el chat (con el riesgo de seguridad y el gasto de tokens que eso supone), el agente "habla" directamente con tu base de datos a través de MCP.

• Utilidad real: Puedes decirle: "Busca en mi tabla de usuarios cuáles no han verificado el email y genera un script para enviarles un recordatorio". La IA consulta la estructura real, no se la inventa.

Los MCP son, en esencia, canales de comunicación entre los modelos de IA y herramientas externas.

Las Skills (Herramientas): Las "Manos" del agente

Una de las dudas más comunes es cómo "aprende" la IA a hacer cosas nuevas. Las Skills (o herramientas) no son algo que la IA traiga de serie (aunque algunas sí) por "saber mucho", sino funciones que tú, como desarrollador, tienes que habilitar o programar.

Podemos dividirlas en tres niveles según su origen:

1. Skills Nativas (Las que ya vienen "instaladas")

Muchas herramientas de IA (como ChatGPT, Claude o Gemini) ya traen herramientas de serie. Por ejemplo, el acceso a internet, la ejecución de código Python en un entorno seguro (Code Interpreter) o la generación de imágenes.

• Cómo se usan: No tienes que hacer nada. La IA decide usarlas cuando tu petición lo requiere.

2. Skills de Ecosistema (Marketplace de conectores)

Aquí es donde entra lo que comentábamos del MCP. Existe ya un ecosistema de servidores MCP creados por la comunidad.

• Cómo se instalan: Es muy parecido a instalar una dependencia en un proyecto. Te descargas un servidor MCP ya hecho (por ejemplo, uno para Google Drive, otro para Slack o el de PostgreSQL que mencioné en mi post ).

• Configuración: Simplemente editas un archivo de configuración en tu entorno (como el claude_desktop_config.json) y le dices dónde está ese servidor. A partir de ese momento, la IA "ve" esa nueva habilidad.

Los MCP dotan a los modelos de IA de nuevas Skills.

3. Skills a medida (Las que tú programas)

Si necesitas que la IA haga algo muy específico de tu flujo de trabajo (por ejemplo, "publicar este borrador en mi blog de Hugo"), tienes que crear la Skill tú mismo.

• Cómo se hacen: No es más que una función en Python o TypeScript.

• El "Contrato": Lo más importante no es solo el código, sino la descripción. Tienes que escribir un pequeño texto explicando a la IA para qué sirve esa función y qué parámetros necesita. La IA lee esa descripción y, cuando ve que tu petición encaja, "llama" a tu función.

¿Cómo encaja todo esto? (Ejemplo práctico)

Imagina que estás trabajando en un mapa con Leaflet. Quieres añadir marcadores desde una base de datos:

1. El Agente es tu interlocutor.
2. El MCP es el puente que le permite leer tu base de datos PostgreSQL local.
3. La Skill es la capacidad que le has dado para "escribir en el archivo mapa.js".

Tú solo dices: "Añade al mapa los puntos de la tabla 'eventos' de mi base de datos". El Agente usa el MCP para consultar la tabla, procesa los datos y usa su Skill de escritura para actualizar tu código.

Instrucciones persistentes: Los archivos .md y ficheros de configuración

Si estamos tratando de ser meticulosos y evitar la "charla" innecesaria, no tiene sentido repetirle nuestras preferencias a la IA en cada nuevo chat. Aquí es donde entran los archivos de configuración de contexto, como los ai.md, agents.md o los .cursorrules.

• ¿Qué son? Son archivos de texto plano que colocas en la raíz de tu proyecto. En ellos defines las reglas del juego: qué librerías prefieres (por ejemplo, Leaflet sobre OpenLayers ), cómo quieres que se estructure el código o qué estándares de seguridad debe seguir.

• Instrucciones del modelo (System Prompts): Muchos modelos permiten ahora adjuntar un archivo de "instrucciones personalizadas". En lugar de un prompt efímero, es un contrato permanente. Si en mi blog hablo de usar PostgreSQL con MCP, en mi archivo de agente definiré que siempre que consulte la base de datos, use ese protocolo específico.

• La ventaja técnica: Al tener estas instrucciones en un fichero .md, puedes versionarlas con Git. Si cambias tu forma de trabajar o añades una nueva Skill a tu flujo, el Agente se actualiza automáticamente al leer el archivo.

Capítulo 6. Estrategia de modelos: ¿A quién le pides cada tarea?

A estas alturas de la guía, ya tienes el entorno configurado y sabes cómo dar instrucciones. Pero te falta lo más importante para el día a día: saber qué modelo elegir. Hoy en día no hay una sola "IA"; hay un catálogo creciente de modelos con especialidades muy distintas.

Si intentas resolver un problema de lógica compleja con un modelo rápido, te dará una respuesta errónea con mucha seguridad. Si usas un modelo pesado para corregir una falta de ortografía, estás matando moscas a cañonazos. Vamos a poner orden en este ecosistema.

1. Modelos de Razonamiento (O-series / "Deep Thinking")

Estos son los modelos "lentos" por diseño (como la serie o1 o los nuevos modelos de pensamiento profundo). Su característica principal es que utilizan una cadena de pensamiento interna antes de escribir la primera palabra.

• Cuándo usarlos: Problemas de lógica pura, matemáticas, arquitectura de software compleja o cuando necesitas que la IA verifique su propia respuesta varias veces.

• La clave: Úsalos cuando el "qué" es difícil de resolver y requiere un plan previo. No esperes velocidad; espera acierto.

2. Modelos de Desarrollo (Coding Assistants)

Aunque los generalistas programan bien, existen versiones optimizadas para el código (como los que alimentan a Cursor o versiones específicas "Coder"). Estos modelos han tenido una dieta de entrenamiento basada en repositorios de alta calidad y entienden mejor la jerarquía de un proyecto.

• Cuándo usarlos: Para refactorizar código, crear tests unitarios o entender cómo una función en db.py afecta a tu mapa en index.html.

• El consejo: Úsalos dentro de tu IDE. Son modelos que brillan cuando tienen acceso a tu sistema de archivos.

3. Modelos "Flash" o Ligeros (Velocidad y Eficiencia)

Son los modelos pequeños (como GPT-4o-mini, Claude Haiku o Gemini Flash). Tienen menos parámetros, lo que los hace increíblemente rápidos y económicos en términos de tokens.

• Cuándo usarlos: Tareas mecánicas o de bajo razonamiento. Traducir un texto, resumir un hilo de emails, formatear un JSON o cambiar el tono de un párrafo.

• La ventaja: Su latencia es mínima. En el tiempo que un modelo de razonamiento empieza a "pensar", este ya ha terminado la tarea.

4. Modelos de Gran Contexto (La memoria infinita)

Hay modelos específicos que destacan por tener una Ventana de Contexto gigantesca (capaces de leer libros enteros o repositorios completos de una vez).

• Cuándo usarlos: Cuando tienes que analizar una documentación técnica de 500 páginas, buscar un bug en un proyecto antiguo con cientos de archivos o cruzar datos de múltiples fuentes.

• Ojo con: "Lost in the middle". Aunque puedan leer mucho, recuerda lo que vimos en el Capítulo 2: si el dato importante está en la mitad del texto, es mejor usar un modelo de razonamiento para asegurar que no se le pase por alto.

Capítulo 7. Conclusiones y el camino a seguir

Después de haber desgranado desde qué es un token hasta cómo orquestar agentes con MCP, toca hacer una pausa y mirar el mapa completo. Escribir esta serie me ha servido para poner orden a mis investigaciones, pero sobre todo para reafirmar algunas convicciones sobre cómo debemos afrontar este cambio quienes nos dedicamos a la tecnología.

Estas son mis conclusiones tras meses de "cacharrreo", pruebas y algún que otro error de concepto:

1. La comprensión es tu mejor herramienta

No basta con saber qué botones pulsar. Entender cómo funciona la IA por dentro, su naturaleza estadística, sus límites de contexto y por qué alucina, es lo que marca la diferencia entre quien se frustra y quien sabe trabajar con ella. Como en cualquier otra rama de la ingeniería, conocer los cimientos te permite construir estructuras mucho más sólidas. Si sabes por qué la IA se equivoca, sabrás cómo corregir la instrucción para que no vuelva a suceder.

2. Solo estamos rascando la superficie

Lo que hoy nos parece revolucionario, como el Model Context Protocol (MCP) que os comentaba hace unos días, probablemente sea solo el estándar básico de mañana. Estamos en una fase muy temprana de esta tecnología.

• Mi consejo: mantén la curiosidad activa.
• No te conformes con lo que aprendiste el mes pasado.
• Investiga, prueba modelos locales, experimenta con nuevos flujos de trabajo y, sobre todo, no te cases con una sola herramienta. La flexibilidad va a ser nuestra mayor ventaja competitiva.

3. Orquestación frente a monopolio

Si algo me preocupa de este "boom" es la tendencia a quedarnos atrapados en un solo ecosistema. Ahora más que nunca, es vital huir del vendor lock-in.

• Usa modelos diferentes según la tarea: razonamiento para la lógica, modelos flash para la velocidad y modelos de código para el desarrollo.

• Prioriza opciones que te permitan saltar entre proveedores. Herramientas como OpenRouter u OpenCode Zen, o incluso el uso de modelos Open Source en local no son solo una cuestión de preferencia técnica; son una cuestión de soberanía tecnológica. En un mundo donde los modelos cambian de la noche a la mañana, tener el control de tus fuentes de inteligencia es fundamental.

Reflexión final

La IA no ha venido a sustituir nuestra capacidad de pensar, sino a amplificar nuestra capacidad de hacer. Seguimos siendo artesanos e ingenieros de la tecnología , y nuestra labor sigue siendo la misma: resolver problemas reales con las mejores herramientas a nuestro alcance. La IA es solo un nuevo martillo, muy potente, pero que requiere una mano experta que sepa dónde golpear.

Espero que esta guía te haya servido para despejar un poco la niebla y empezar a usar estas herramientas con más criterio y menos miedo. Nos vemos en los próximos posts, seguramente probando alguna nueva "skill" o integrando mapas en algún flujo de trabajo que hoy ni siquiera imaginamos.

Me encontraba en una situación que probablemente te suene familiar. Tenía un proyecto antiguo, una aplicación web funcional que lleva años funcionando, alimentada por una base de datos PostgreSQL que... bueno, digamos que ha vivido su propia vida.

Cada cierto tiempo, el cliente pedía información que no se podía ver en la aplicación web, por lo que era necesario consultar directamente la base de datos. Y cada vez, me enfrentaba al mismo ritual:

1. Abrir el cliente de base de datos
2. Recordar qué tabla almacena qué información (la documentación estaba, sabes, "actualizada")
3. Escribir consultas SQL que parecían novelas de misterio con múltiples JOINs
4. Esperar varios minutos mientras la base de datos trabajaba
5. Formatear los resultados para que fueran comprensibles

No era técnicamente difícil, pero sí increíblemente lento y repetitivo. Y no nos engañemos, hacer consultas SQL no es divertido.

Primer Intento de solución: "IA, Ayúdame a Escribir SQL"

Como buen desarrollador del siglo XXI, mi primer pensamiento fue: "¿Puede la IA ayudarme con esto?". Empecé a usar chats con modelos de IA para generar las consultas SQL.

El proceso era algo así:

Yo: Necesito una consulta que me muestre estos datos.

IA: Aquí tienes la consulta SQL:

Funcionaba... hasta que no funcionaba. El problema fundamental: la IA no conocía mi base de datos. Tenía que explicarle constantemente:

"La tabla usuarios se llama realmente clientes" "Los campos de fecha están en formato timestamp" "La relación entre clientes y pedidos es a través de cliente_id, no usuario_id" "Ten cuidado que hay clientes inactivos en la tabla clientes_baja"

Cada consulta me llevaba más tiempo explicando el contexto que escribiendo SQL yo mismo. Era como tener que entrenar a alguien cada vez que quería hacer una pregunta, bueno, de hecho era literalmente así.

El Momento MCP: Cuando Todo Cambió

Investigando sobre cómo las IAs podrían conectarse directamente a bases de datos, apareció MCP (Model Context Protocol). Y fue como si se encendiera una bombilla.

MCP no es un modelo ni una IA nueva, es un protocolo que permite a los modelos interactuar con herramientas externas (bases de datos, APIs, sistemas locales) de forma estructurada.

¿Y si en lugar de explicarle a la IA cómo es mi base de datos, pudiera simplemente dejarla hablar con ella directamente?

Dejé de pensar en "cómo genero mejores consultas SQL" y empecé a pensar en "cómo conecto la IA directamente a mis datos".

La diferencia es sutil pero fundamental:

• Antes: yo → IA → texto SQL → yo → base de datos → yo → IA
• Ahora: yo → IA → base de datos → IA

Eliminaba el intermediario (yo) y con ello, toda la fricción.

Experimento #1: Gemini-cli y la Vía Fácil

Empecé con Gemini-cli porque descubrí que tenía un sistema de extensiones ya maduro. Entre ellas, una extensión oficial para PostgreSQL.

La instalación fue ridiculamente sencilla:

gemini extensions install https://github.com/gemini-cli-extensions/postgres

Configuré las variables de entorno, y en minutos, tenía una IA que podía consultar mi base de datos real. El momento mágico fue cuando pregunté (ejemplo figurado):

Yo: "Muéstrame todos los clientes de Madrid"

Gemini: "Tengo 3 clientes en Madrid: Ana García, Carlos López y María Pérez. Ana se registró hace 2 semanas y ya ha hecho un pedido."

No me devolvió una consulta SQL, me devolvió una respuesta basada en los datos. La IA había ejecutado la consulta, interpretado los resultados, y me los presentó de forma natural.

Ventajas de este enfoque:

• Super rápido de configurar
• Extensión oficial y bien mantenida
• Integración perfecta con PostgreSQL
• Resultados conversacionales inmediatos

🚀 Experimento #2: Opencode y el Camino Manual

Como últimamente estoy experimentando bastante con Opencode (una herramienta que me está encantando), quise ver cómo podía lograr lo mismo con ellos. Aquí la historia fue diferente.

Opencode no tiene un sistema de extensiones predefinido como Gemini-cli. En su lugar, utiliza MCP de forma más nativa, pero requiere que configuremos los servicios MCP manualmente.

El proceso fue:

1. Instalar postgres-mcp como paquete npm
2. Configurar opencode.json para que usara este MCP local
3. Ajustar las variables de entorno para que coincidieran

Aunque fue más manual que el enfoque de Gemini-cli, una vez funcionó, la experiencia fue igual de impresionante. La diferencia principal está en la filosofía:

• Gemini-cli: Tiene extensiones prefabricadas para todo
• Opencode: Te da las herramientas para construir tus propias conexiones

Este Repositorio No Es el Proyecto, Es Mi Guía

He creado un pequeño repositorio en mi cuenta de GitHub con la configuración y una base de datos de ejemplo para probarlo. Es principalmente una documentación para mi yo del futuro. Pero como compartir es vivir, ahí queda, por si a alguien le es útil o quiere hacer pruebas.

• Tiene una configuración para arrancar un PostgreSQL con Docker
• Tiene una base de datos de ejemplo (una tienda online con datos realistas)
• Está todo documentado paso a paso (para no perder horas configurándolo de nuevo)
• Incluye la configuración para ambas soluciones (Gemini-cli y Opencode)
• Funciona out-of-the-box (para que mi yo del futuro no sufra)

Conclusiones

Si no te gustan, tengo otras. Pero:

• La IA es el mayor avance en interfaces de usuario desde que se inventó el ratón. Los modelos pueden ser mejores o peores, acertar más o menos según su entrenamiento y sus capaciades, pero lo que es innegable es que la IA está cambiando la forma de relacionarnos con la tecnología. Ahora podemos hablarle a todo, incluído a una base de datos.

• "Me fío de todo el mundo pero desconfío del diablo que llevan dentro". Esta frase es de la película The Italian Job. Viene que ni al pelo. Los modelos de IA son lo que son, se basan en probabilidad, no hacen magia, recuérdalo siempre. En este ejemplo concreto, si conoces el dominio que estás consultando y algo te huele raro, revisa, es muy probable que la IA haya hecho mal. Coteja la información, revisa la SQL que ha usado, etc. sobre todo si la información es importante.

Definiendo nuestros datos GeoJSON

Para este ejemplo, definiremos los datos directamente en una variable de JavaScript. En una aplicación real, estos datos vendrían normalmente de una API o un fichero .geojson.

Añadiendo capas WMS

Además de las capas de teselas habituales (llamadas capas TMS o XYZ), Leaflet puede consumir servicios WMS (Web Map Service). Estos servicios son un estándar muy común en el mundo de los SIG. Para este ejemplo, usaremos el servicio de ortofotos del Plan Nacional de Ortofotografía Aérea (PNOA) de España. Se hace a través de L.tileLayer.wms:

var pnoa = L.tileLayer.wms('http://www.ign.es/wms-inspire/pnoa-ma', {
    layers: 'OI.OrthoimageCoverage',
    format: 'image/jpeg',
    transparent: true,
    attribution: 'PNOA cedido por © <a href="http://www.ign.es/ign/main/index.do">Instituto Geográfico Nacional</a>'
});

Marcadores personalizados con HTML, CSS y Font Awesome

Una de las formas más potentes de personalizar los marcadores es usando L.divIcon. A diferencia de L.icon que usa una imagen, divIcon nos permite usar código HTML y CSS, lo que abre la puerta a usar librerías de iconos como Font Awesome.

El proceso combina la lógica de JavaScript con los estilos de CSS.

En la parte de JavaScript, dentro de la función pointToLayer, decidimos qué icono y qué estilo aplicar a cada punto. Usamos un switch para elegir una clase de Font Awesome (ej: fa-tree) y una clase CSS propia (ej: parque) basándonos en las propiedades de los datos. Luego, pasamos estas clases al divIcon:

var customIcon = L.divIcon({
    className: 'custom-marker ' + markerColorClass, // Clases para el CSS
    html: `<i class="fas ${iconClass}"></i>`,      // HTML con el icono de Font Awesome
    iconSize: [30, 30]
});

A continuación, en el CSS, definimos los estilos. Tenemos una clase base, .custom-marker, que crea el círculo contenedor del icono. Luego, las clases específicas (.playa, .parque, .faro) establecen el color tanto del borde del círculo como del propio icono de Font Awesome que contiene.

.custom-marker { 
    background-color: rgba(255, 255, 255, 0.9); 
    border: 2px solid #333; 
    border-radius: 50%;
    /* ... más estilos ... */
}
.custom-marker.playa { border-color: #00aaff; color: #00aaff; }
.custom-marker.parque { border-color: #28a745; color: #28a745; }

De esta forma, el HTML y el CSS trabajan juntos para crear un marcador totalmente personalizado.

Creando un selector de capas

Para permitir al usuario cambiar entre diferentes mapas base y activar o desactivar capas de datos, usamos L.control.layers.

var baseMaps = {
    "Mapa": carto,
    "Ortofoto": pnoa
};
var overlayMaps = {
    "Puntos de interés": markers
};
L.control.layers(baseMaps, overlayMaps).addTo(map);

Ejemplo completo

El siguiente código HTML es un ejemplo completo y autocontenido.

<!DOCTYPE html>
<html>
<head>
    <title>Leaflet Avanzado: WMS y Control de Capas</title>
    <meta charset="utf-8" />
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <link rel="stylesheet" href="https://unpkg.com/leaflet/dist/leaflet.css" />
    <link rel="stylesheet" href="https://cdnjs.cloudflare.com/ajax/libs/font-awesome/5.15.4/css/all.min.css">
    <style>
        html, body { height: 100%; margin: 0; padding: 0; display: flex; flex-direction: column; }
        h1 { text-align: center; padding: 10px 0; margin: 0; }
        #map { flex-grow: 1; }
        .custom-marker { 
            background-color: rgba(255, 255, 255, 0.9); 
            border: 2px solid #333; 
            border-radius: 50%; 
            width: 30px; 
            height: 30px; 
            display: flex; 
            justify-content: center; 
            align-items: center; 
            box-shadow: 0 2px 5px rgba(0,0,0,0.3); 
            font-size: 16px; 
        }
        .custom-marker.playa { border-color: #00aaff; color: #00aaff; }
        .custom-marker.parque { border-color: #28a745; color: #28a745; }
        .custom-marker.faro { border-color: #ffc107; color: #ffc107; }
    </style>
</head>
<body>

<h1>Leaflet Avanzado: WMS y Control de Capas</h1>
<div id="map"></div>

<script src="https://unpkg.com/leaflet/dist/leaflet.js"></script>
<script>
    // 1. Definir capas base
    var carto = L.tileLayer(
        'https://{s}.basemaps.cartocdn.com/light_all/{z}/{x}/{y}{r}.png', 
        {
            attribution: '&copy; <a href="https://www.openstreetmap.org/copyright">OpenStreetMap</a> contributors &copy; <a href="https://carto.com/attributions">CARTO</a>'
        }
    );

    var pnoa = L.tileLayer.wms('http://www.ign.es/wms-inspire/pnoa-ma', {
        layers: 'OI.OrthoimageCoverage',
        format: 'image/jpeg',
        transparent: true,
        attribution: 'PNOA cedido por © <a href="http://www.ign.es/ign/main/index.do">IGN</a>'
    });

    // 2. Inicializar el mapa
    var map = L.map('map', {
        center: [43.35, -8.36],
        zoom: 13,
        layers: [carto]
    });

    // 3. Datos GeoJSON
    var geojsonData = {
      "type": "FeatureCollection",
      "name": "oleiros_puntos",
      "features": [
        {
          "type": "Feature",
          "properties": { "name": "Playa de Santa Cristina", "tipo": "Playa" },
          "geometry": { "type": "Point", "coordinates": [-8.378631, 43.339596] }
        },
        {
          "type": "Feature",
          "properties": { "name": "Parque de José Martí", "tipo": "Parque" },
          "geometry": { "type": "Point", "coordinates": [-8.378567, 43.336728] }
        },
        {
          "type": "Feature",
          "properties": { "name": "Faro de Mera", "tipo": "Faro" },
          "geometry": { "type": "Point", "coordinates": [-8.354416, 43.383347] }
        },
        {
          "type": "Feature",
          "properties": { "name": "Playa de Bastiagueiro", "tipo": "Playa" },
          "geometry": { "type": "Point", "coordinates": [-8.362489, 43.340981] }
        }
      ]
    };

    // 4. Capa de marcadores personalizados
    var markers = L.geoJSON(geojsonData, {
        pointToLayer: function (feature, latlng) {
            var iconClass, markerColorClass = '';
            switch (feature.properties.tipo) {
                case 'Playa': 
                    iconClass = 'fa-umbrella-beach'; 
                    markerColorClass = 'playa'; 
                    break;
                case 'Parque': 
                    iconClass = 'fa-tree'; 
                    markerColorClass = 'parque'; 
                    break;
                case 'Faro': 
                    iconClass = 'fa-lightbulb'; 
                    markerColorClass = 'faro'; 
                    break;
                default: 
                    iconClass = 'fa-map-marker-alt'; 
                    break;
            }
            var customIcon = L.divIcon({
                className: 'custom-marker ' + markerColorClass,
                html: `<i class="fas ${iconClass}"></i>`,
                iconSize: [30, 30]
            });
            var popupText = '<strong>' + feature.properties.name + '</strong>' + 
                            '<br>Tipo: ' + feature.properties.tipo;

            return L.marker(latlng, { icon: customIcon }).bindPopup(popupText);
        }
    }).addTo(map);

    // 5. Configurar el control de capas
    var baseMaps = {
        "Mapa": carto,
        "Ortofoto": pnoa
    };

    var overlayMaps = {
        "Puntos de interés": markers
    };

    L.control.layers(baseMaps, overlayMaps).addTo(map);

    // 6. Ajustar el zoom a los marcadores
    map.fitBounds(markers.getBounds());

</script>

</body>
</html>

Bonus final: Latitud y Longitud, el eterno debate

Un detalle importante a tener en cuenta es el orden de las coordenadas. Si te has dado cuenta el orden de las coordenadas es diferente cuando definimos el centro del mapa en leaflet, respecto de como se definen en el geojson. No existe un estándar único en el mundo de la información geográfica, lo que a menudo causa errores inesperados.

• Leaflet, en sus funciones principales como L.mapsetView() o L.marker(), generalmente espera el formato [latitud, longitud].
• El estándar GeoJSON, sin embargo, especifica el orden inverso: [longitud, latitud].

Esta inconsistencia es habitual entre diferentes herramientas, formatos y estándares del mundo SIG. Afortunadamente, en este caso, la función L.geoJSON() de Leaflet es lo suficientemente inteligente como para leer correctamente las coordenadas en el formato estándar de GeoJSON sin que tengamos que hacer ninguna conversión manual. Para quien quiera profundizar más en este curioso problema, el artículo Lon, lat is the right way de Tom MacWright lo explica de maravilla.

Esta filosofía tiene una ventaja importante: puedes empezar de forma simple y rápida, sin tener que aprender una API enorme o cargar funcionalidades que no necesitas. Y si tu proyecto crece, puedes ir ampliándolo con una extensa colección de plugins oficiales y de la comunidad que añaden todo tipo de capacidades: desde dibujar polígonos y medir distancias, hasta mostrar datos en 3D o integrar servicios de geocodificación.

En resumen: Leaflet es pequeño y fácil al principio, pero no se queda corto. Es como una navaja suiza a la que le puedes ir añadiendo herramientas a medida que las necesitas.

¿Por qué usar Leaflet?

• Ligera: el núcleo pesa menos de 50 KB.
• Compatible: funciona en la mayoría de navegadores y dispositivos móviles.
• Extensible: cuenta con multitud de plugins para añadir funcionalidades avanzadas.
• Fácil de aprender: ideal para principiantes y proyectos rápidos.

Ejemplo básico de mapa con Leaflet

El siguiente ejemplo muestra cómo crear un mapa centrado en unas coordenadas concretas, añadir un marcador y mostrar un popup. Solo necesitas incluir la librería Leaflet y un contenedor para el mapa.

<!DOCTYPE html>
<html>
<head>
    <meta charset="utf-8" />
    <title>Mapa con Leaflet</title>
    <meta name="viewport" content="width=device-width, initial-scale=1.0">

    <!-- CSS de Leaflet -->
    <link rel="stylesheet" href="https://unpkg.com/leaflet/dist/leaflet.css" />

    <style>
        #map {
            height: 500px;
        }
    </style>
</head>
<body>

<h1>Mi primer mapa con Leaflet</h1>
<div id="map"></div>

<!-- JS de Leaflet -->
<script src="https://unpkg.com/leaflet/dist/leaflet.js"></script>
<script>
    // Inicializar el mapa
    var map = L.map('map').setView([43.3336, -8.3174], 14);

    // Añadir capa base de OpenStreetMap
    L.tileLayer('https://{s}.tile.openstreetmap.org/{z}/{x}/{y}.png', {
        attribution: '&copy; <a href="https://www.openstreetmap.org/">OpenStreetMap</a> contributors'
    }).addTo(map);

    // Añadir un marcador
    var marker = L.marker([43.3336, -8.3174]).addTo(map);

    // Popup en el marcador
    marker.bindPopup("<b>Hola!</b><br>Este es un mapa de Leaflet centrado en Oleiros.").openPopup();
</script>

</body>
</html>

Cómo funciona el código

• Importamos Leaflet: a través de sus archivos CSS y JS desde un CDN.
• Creamos un contenedor #map: donde se dibujará el mapa.
• Inicializamos el mapa: con L.map() y lo centramos en un punto.
• Añadimos una capa base: usando L.tileLayer() con teselas de OpenStreetMap.
• Colocamos un marcador: y le añadimos un popup.

Entender qué significan estos conceptos te ahorrará muchos quebraderos de cabeza. Porque antes de representar datos geográficos en la web, hay que entender una idea clave: el planeta en el que vivimos no es fácil de convertir en un plano.

La Tierra no es una esfera perfecta. De hecho, se parece más a una patata: está achatada por los polos, algo abultada por el ecuador y llena de irregularidades causadas por la gravedad, las montañas y los océanos. Esa forma tan real pero complicada se llama geoide, y aunque describe bien cómo es el planeta, resulta imposible de usar directamente en los cálculos de un mapa.

Para simplificar las cosas, se utiliza una superficie más regular llamada elipsoide de referencia. Es una figura matemática que se ajusta al geoide, pero lo bastante sencilla para trabajar con ella. Existen varios elipsoides, pero hoy el más usado es el WGS84, el mismo que emplea el GPS y la mayoría de servicios de mapas en línea.

Con el elipsoide definido, necesitamos una forma de localizar puntos sobre él. Para eso se usan las coordenadas geográficas, que indican la latitud (posición norte-sur) y la longitud (posición este-oeste). Por ejemplo, 43.333°N, -8.317°O nos lleva a Oleiros, en Galicia. Es un sistema perfecto para referirse a lugares sobre el globo, pero poco práctico para dibujarlos en una pantalla, porque los ordenadores trabajan con coordenadas planas (x, y).

Y aquí llega el paso más importante: convertir una superficie curva en un plano. Este proceso se llama proyección cartográfica.Imagina intentar aplanar la piel de una naranja sobre una hoja de papel: tendrás que estirar, cortar o deformar algo. Con la Tierra pasa lo mismo. Cada proyección elige qué quiere conservar (las distancias, las áreas, los ángulos…) y qué está dispuesta a deformar. No hay una proyección perfecta, solo la más adecuada según el uso.

La proyección Web Mercator

En el mundo del webmapping, la proyección más común es la Web Mercator, una adaptación moderna de la proyección creada por Gerardus Mercator en el siglo XVI. Es la que utilizan Google Maps, OpenStreetMap, Bing Maps, y casi todos los visores actuales.

Su gran ventaja es que permite mostrar todo el planeta como una cuadrícula continua y realizar zoom progresivo sin interrupciones, lo que resulta ideal para aplicaciones interactivas. Internamente, Web Mercator transforma las coordenadas de latitud y longitud en metros usando el elipsoide WGS84, y “recorta” la Tierra a una latitud máxima de ±85°. Esto evita que las zonas cercanas a los polos se estiren infinitamente.

El inconveniente, claro, es la distorsión: los objetos cercanos a los polos se ven mucho más grandes de lo que son. Groenlandia parece casi tan grande como África, cuando en realidad África es unas 14 veces mayor. Por eso, aunque Web Mercator es práctica, no es la proyección adecuada para hacer cálculos de superficie o distancia.

Aun así, su sencillez y compatibilidad la han convertido en el estándar de facto en los mapas web. Cuando ves un mapa en línea, lo más probable es que esté en EPSG:3857, el código oficial de esta proyección.

Sistemas de referencia: el idioma de los mapas

Cada combinación de elipsoide, proyección y unidad de medida forma lo que se conoce como un sistema de referencia espacial. Podemos imaginarlo como el “idioma” que usan los datos geográficos para decirle al mapa dónde se encuentra cada punto.

Un sistema de referencia se compone, generalmente, de tres partes:

1. Datum o marco de referencia: define la forma y posición del elipsoide respecto a la Tierra real. Por ejemplo, el WGS84 es un datum global.
2. Proyección cartográfica: establece cómo se transforma la superficie curva del elipsoide en un plano (por ejemplo, Mercator, UTM, Lambert, etc.).
3. Unidades de medida: indican en qué se expresan las coordenadas (grados, metros, pies…).

Estas tres piezas juntas determinan cómo deben interpretarse las coordenadas de un archivo o servicio geográfico. Por ejemplo:

• EPSG:4326 → usa el datum WGS84, sin proyección (coordenadas en grados de latitud y longitud).
• EPSG:3857 → usa el mismo datum WGS84, pero proyectado con Web Mercator, y las coordenadas se expresan en metros.
• EPSG:25831 → corresponde al sistema UTM huso 31N sobre el datum ETRS89, habitual en España peninsular.

Saber en qué sistema están tus datos, y cuál usa tu mapa, es esencial para que todo encaje. Si no coinciden, los puntos aparecerán desplazados, a veces cientos de kilómetros fuera de lugar. Por suerte, la mayoría de librerías modernas permiten gestionar estos sistemas de forma automática.

¿Qué hacen las librerías web con todo esto?

Una buena noticia: no necesitas preocuparte demasiado por las transformaciones.
Librerías como Leaflet, OpenLayers o MapLibre están pensadas para que los datos “simplemente funcionen”.

La mayoría de los mapas en la web utilizan Web Mercator (EPSG:3857), pero muchos conjuntos de datos, APIs o servicios de datos abiertos vienen en EPSG:4326, es decir, con latitudes y longitudes en grados. ¿Cómo es posible que ambos se entiendan?

La clave está en que los dos sistemas comparten el mismo elipsoide, WGS84.
Eso significa que la relación entre coordenadas geográficas (grados) y proyectadas (metros) es directa y fácil de calcular matemáticamente. Cuando una librería como OpenLayers recibe datos en 4326, no necesita hacer una transformación geodésica compleja, sino una simple conversión de grados a metros en la proyección Web Mercator.

En la práctica, es como si el mapa y tus datos hablaran el mismo idioma con distinto acento: basta una pequeña traducción. Por eso puedes pasar coordenadas en 4326 y ver cómo se dibujan correctamente sobre un mapa base en 3857, sin que aparezcan desplazadas ni deformadas.

Ahora bien, cada librería gestiona esto de forma un poco diferente:

• Leaflet trabaja de forma nativa en Web Mercator y no incluye soporte interno para transformar entre sistemas distintos. Si tus datos están en otra proyección, tendrás que convertirlos antes o usar un plugin como Proj4Leaflet.

• OpenLayers integra el motor Proj4js y puede transformar coordenadas directamente entre sistemas definidos por su código EPSG. Esto la hace más flexible para trabajar con datos en diferentes proyecciones sin necesidad de preprocesarlos.

• MapLibre GL JS trabaja también en Web Mercator, pero con una particularidad: está pensada principalmente para mapas vectoriales. Su motor de renderizado asume que las coordenadas de los datos están en EPSG:4326 (grados) y las proyecta internamente a 3857 en tiempo real, aprovechando la GPU del navegador. Es decir, hace la conversión sobre la marcha de forma eficiente y transparente para ti. No incluye herramientas de reproyección entre otros sistemas, pero en la mayoría de los casos no las necesita.

En resumen, las tres librerías coinciden en que Web Mercator es su lenguaje común, y todas pueden mostrar datos en 4326 sin problemas. La diferencia está en cuánta ayuda ofrecen si trabajas fuera de ese “idioma estándar”.

En resumen

Cuando trabajas con mapas web, tus datos siguen un camino que va desde la forma real del planeta hasta el plano del navegador:

Tierra → Geoide → Elipsoide → Coordenadas → Proyección → Mapa

Comprender esta secuencia te ayudará a evitar errores y, sobre todo, a entender qué está ocurriendo “debajo del mapa”.

En siguientes artículos veremos cómo llevar estos conceptos a la práctica: cómo cargar datos, elegir proyecciones y crear tus propios mapas interactivos.

¿Qué son Leaflet, OpenLayers y MapLibre?

Para empezar, un poco de contexto. Leaflet es una librería nacida en 2011 que se ha ganado la fama por ser ligera, fácil de aprender y con una curva de aprendizaje muy amigable para principiantes. Su foco principal es facilitar la creación de mapas web sencillos, con funcionalidades básicas pero muy bien diseñadas, y una amplia variedad de plugins para ampliar sus capacidades.

Por otro lado, OpenLayers es un proyecto más antiguo (desde 2006) y mucho más completo y robusto. Está pensado para quienes necesitan hacer proyectos GIS avanzados con análisis espacial, soporte para múltiples formatos, proyecciones y operaciones complejas sobre datos geográficos. Su curva de aprendizaje es más pronunciada, pero a cambio ofrece una potencia y flexibilidad que pocas librerías pueden igualar.

Finalmente, MapLibre es relativamente más nuevo y nace como un fork abierto de Mapbox GL JS. Su especialidad son los mapas vectoriales renderizados con WebGL, lo que permite crear visualizaciones muy modernas, estilizadas y con gran rendimiento para datos complejos y dinámicos. MapLibre está ganando mucha popularidad especialmente para aplicaciones que buscan estética y rendimiento en mapas web.

Comunidad y desarrollo: ¿qué librería está más activa?

Al elegir una librería para tus proyectos, es fundamental conocer qué tan activa y saludable es su comunidad de desarrolladores, así como la frecuencia con la que se actualiza el proyecto. Esto afecta la calidad del software, la rapidez en corregir errores y la disponibilidad de nuevas funcionalidades.

Una métrica comúnmente citada son las estrellas en GitHub, que indican popularidad, pero no siempre reflejan la actividad real de desarrollo. Por eso, también es útil mirar otros datos como el número de contribuidores activos, la frecuencia de lanzamientos y el nivel de interacción en los issues y pull requests.

Leaflet tiene aproximadamente 43,000 estrellas en GitHub, lo que indica una comunidad muy amplia y extendida. El número de contribuidores totales es de más de 800 en total, aunque a lo largo del tiempo no se ha mantenido constante. La frecuencia de actualizaciones es moderada, con la última versión estable importante lanzada hace más de dos años. Aunque la comunidad es grande, el ritmo de desarrollo es algo pausado en la actualidad. Hay que tener en cuenta que el modelo de Leaflet es tener un núcleo pequeño, que es el repositorio del que se muestra la gráfica, y un ecosistema grande de plugins, a través de los cuales se dota de más funcionalidad.

OpenLayers cuenta con unas 13,000 estrellas en GitHub y alrededor de 400 contribuidores en total. A diferencia de Leaflet, el equipo de desarrollo lanza actualizaciones regularmente, con versiones nuevas casi cada mes. Además, la comunidad es muy técnica, lo que favorece un desarrollo continuado y la incorporación de funcionalidades complejas, muy valoradas en proyectos GIS profesionales.

MapLibre, con cerca de 8,500 estrellas, es la más joven de las tres pero destaca por su crecimiento rápido. Cuenta ya con más de 500 contribuidores en total y una actividad intensa en issues y pull requests, lo que refleja una comunidad vibrante y muy involucrada en mantener la librería actualizada con las últimas tecnologías, especialmente para mapas vectoriales con WebGL.

En resumen, si bien Leaflet sigue siendo la librería más popular, OpenLayers y MapLibre tienen comunidades muy activas y desarrollo frecuente, cada una con su enfoque particular.

Licencias: la tranquilidad de trabajar con software libre

Otro punto que siempre preocupa a quienes empiezan y también a quienes trabajan en proyectos profesionales es la licencia del software. Las tres librerías usan licencias permisivas BSD de 2 cláusulas, lo que significa que puedes usarlas, modificarlas y distribuirlas sin muchas restricciones, incluso en proyectos comerciales. Esto ofrece una gran tranquilidad y flexibilidad para tu trabajo.

¿Cuál librería elegir?

Si estás buscando algo sencillo, que te permita crear mapas rápidamente sin tener que lidiar con complejidades técnicas, Leaflet es sin duda la mejor opción para empezar. Su comunidad enorme y su ecosistema de plugins te facilitarán mucho el aprendizaje y la implementación.

Si tu objetivo es ir más allá y trabajar en proyectos GIS con análisis espaciales, múltiples capas y datos complejos, OpenLayers es la herramienta ideal. Su potencia y flexibilidad se reflejan en el nivel de detalle que puedes manejar en tus mapas.

Por último, si quieres crear mapas modernos, vectoriales y estilizados, que aprovechen WebGL para un rendimiento y estética superior, MapLibre es una opción muy interesante y actualizada, ideal para aplicaciones que buscan impactar visualmente sin perder rendimiento.

Conclusión

En resumen, las tres librerías tienen sus puntos fuertes y la elección depende mucho del tipo de proyecto que quieras hacer y tu nivel de experiencia. Leaflet es ideal para empezar rápido y sencillo, OpenLayers para proyectos GIS más avanzados y MapLibre para quienes buscan mapas vectoriales modernos y estilizados.

Este artículo ofrece una visión general basada en el estado actual de las herramientas y sus comunidades, pero no debe tomarse al pie de la letra. La mejor manera de aprender y decidir es explorando y probando por ti mismo cada una de ellas, ya que cada proyecto tiene necesidades y matices únicos.

Cuando comenzó a desarrollarse el mundo de la informática, los ordenadores eran aparatos muy caros que casi no cabían en una habitación. Un par de fabricantes se repartían el mercado de ese hardware, porque en aquel momento el software no valía nada por sí mismo. En ese momento el software era libre.

La cosa siguió avanzando, los ordenadores empezaron a cambiar de tamaño, cada vez eran más pequeños y su capacidad de procesamiento más grande. Llegamos a la década de los 70, aparece el PC, el personal computer, la posibilidad de llevar los ordenadores a los hogares. Al mercado del hardware empiezan a llegar más fabricantes, el software poco a poco empieza a ser compatible entre equipos y entonces se vuelve importante.

De repente alguien piensa que el negocio ya no está tanto en el hardware sino en el software, así que decide cogerlo y meterlo en cajas para venderlo. Junto con unos textos amplios y de tamaño de letra muy pequeña que establecen las condiciones bajo las que, una vez comprado, puedes hacer uso del mismo. Porque lo compraste, pero no es tuyo. Solo tienes una licencia de uso.

Desde ese momento llega una época oscura, en la que el software ya no es libre. Pero igual que en los cómics de Astérix, hay una aldea de irreductibles galos que no están dispuestos a dejarse conquistar por el imperio. Son el movimiento del Software Libre.

Gracias a ellos el software resistió y no todo se volvió privativo. Pero fueron tiempos difíciles, porque el imperio intentó acabar con estos valientes galos de muchas formas.

Finalmente, y como bien sabemos por la historia, todos los grandes imperios acaban cayendo, o cambiando. Hoy en día, esas grandes corporaciones que querían acabar con el software libre, son las que más contribuyen a su desarrollo. Cosas veredes.

Vivimos ahora en un tiempo donde el hardware está en la nube y el software se utiliza para crear servicios, que es donde está el negocio. El software dejó de ser un fin para ser un medio y, por tanto, ya puede ser libre de nuevo. No hay mal que por bien no venga.

Pero si otra cosa nos enseñó la historia es que, de una forma u otra, todo se repite. Cuando un imperio cae, otro ya está empezando a crecer. Por eso ahora que el software vuelve a ser libre, no podemos bajar la guardia. En nuestras manos está lograr que esta situación perdure. No venció la filosofía, sino la conveniencia, y por lo tanto este statu quo es aún frágil.

En nuestras manos está hacer ver que este modelo funciona, que se puede hacer negocio liberando el software, que puede ser igual o incluso más seguro a pesar de que el código fuente sea público, que facilita y potencia mucho más la innovación. En definitiva, que es el modelo que nunca se debió abandonar.

Porque el software siempre fue libre.

--
Editorial publicada en el portal Mancomún.

Las calles o carreteras, aquí es difícil diferenciar una cosa de la otra, no están especialmente bien mantenidas. La política de ya se harán las aceras las vecinas cuando construyan su casa, hace que las calles, o carreteras, tengan formas irregulares, que haya postes de alumbrado o telefonía en medio de los caminos, o que los tramos de acera estén inconexos. A todo eso se le suma un firme, en la mayoría de los casos en bastante mal estado.

No sería un sitio que animase mucho a salir a dar un paseo, salvo por la ventaja del poco tráfico, que al final hace que puedas salir y caminar casi por el medio y medio de las calles, o carreteras. Siempre le he dado vueltas a cual es el motivo de esta falta de mantenimiento de lo público, por parte de un ayuntamiento que en realidad tiene un gran presupuesto. La primera pregunta que me viene a la cabeza es... ¿son conscientes de qué esto esta así?. En realidad es una pregunta bastante ingenua, porque la respuesta es que sí lo son, obviamente. Pero me da pie a hablar de la gestión de datos cartográficos en los ayuntamientos, que es de lo que va este post en realidad.

Los ayuntamientos, hablando en general, no suelen hacer un gran uso de la información geográfica como apoyo a sus tareas de gestión. En muchos casos ni siquiera disponen de buenas fuentes de información. En el mejor de los casos tendrán algo de cartografía proveniente del PXOM -el Plan Xeral de Ordenación Municipal- que estará en formato CAD y será una foto fija del momento de su elaboración. Algunos ayuntamientos parten de esa información para generar, e intentar mantener actualizado, un callejero municipal, y poco más.

Para encontrar una fuente de información geográfica municipal el siguiente nivel es buscar en las Diputaciones, que con el encargo de realizar la EIEL -Encuesta de Infraestructuras y Equipamientos Locales- sí disponen de algo de cartografía a nivel municipal, que se va actualizando, más o menos.

Buscando información sobre las calles, o carreteras, de mi pueblo, encontré la información correspondiente de la EIEL, que se puede ver en la captura del visor de mapas del Ministerio. Uno de los parámetros de información que se recoge es el estado del pavimento, así que podemos "tematizar" el mapa por él. Los resultados no encajan exactamente con mi experiencia de usuario, demasiado verde para la realidad del estado del pavimento actual. Los datos en teoría están actualizados a diciembre del 21, ya que la EIEL se realiza de forma anual. Por mi experiencia habiendo trabajado durante varios años en varias "eieles", sé que actualizar todas las infraestructuras, de todos los municipios, todos los años, es inviable con los recursos que se destinan. Y en realidad hacerlo implicaría destinar una cantidad de recursos enorme. Por eso, cada año se priorizan zonas, tipos de infraestructuras, etc. Así que la realidad es que la información es fiable a medias. Habrá casos en los que concuerde con la realidad, pero otros, como el que tenemos delante, que para nada.

Las administraciones públicas sólo conocen, simplificando, una forma de hacer las cosas, los contratos públicos. Para eso hace falta presupuesto, y estos no son infinitos, así que hay que estar haciendo equilibrios entre gastar en una cosa, dejar de hacerlo en otra, sacar de aquí y poner allá. La colaboración ciudadana está poco o nada explorada, al menos en ciertos ámbitos. A quienes siempre habéis vivido en una ciudad, os parecerá raro el hecho de tener que hacer mantenimiento de las infraestructuras municipales, para eso está el ayuntamiento y su personal. Pero en el rural es algo más habitual. Aquí se asumen trabajos que corresponderían al ayuntamiento, pero que no hace, a veces por falta de recursos, otras simplemente por dejadez o porque el rédito electoral es bajo y no compensa. Cierto es que esta colaboración ciudadana se va perdiendo poco a poco, cada vez exigimos más, para eso pagamos nuestros impuestos. En otras épocas era más habitual que las vecinas arrimasen el hombro para tener el pueblo limpio y lustroso. Aquí en Galicia en realidad hay muchos ejemplos de gestión ciudadana de lo común, comunidades de montes, de agua, mantenimiento de caminos vecinales. Hoy en día, en muchos casos, si hay malas hierbas delante de tu casa, las quitas, a riesgo de que te invadan por una parte, y por otra, porque lo que tenemos que ver todos los días, cada vez que entramos y salimos de casa, nos gusta que esté como mínimo curioso. Pero es que los seres humanos somos así, nos gusta identificarnos y hacer nuestro aquello que nos es familiar. Hablamos de "nuestra calle", "nuestro barrio", "nuestro pueblo" o "nuestra ciudad", como si nos perteneciesen. Nos gusta sentir que somos parte de algo y si hay que contribuir lo hacemos.

Ese sentimiento humano en realidad está poco explotado en algunos ámbitos. En el lado de la gestión de lo público las experiencias que se han hecho aquí en España suelen ir por la recopilación de incidencias reportadas por la ciudadanía. Estos son claros ejemplos de mal uso de la tecnología. El problema no es poner una aplicación móvil a servicio de la ciudadanía para que ésta reporte farolas sin luz o baches en las calles y aceras. Eso siempre se hizo llamando al ayuntamiento o en los pueblos diciéndoselo directamente al alcalde o concejales cuando les ves. El problema y el reto está en canalizar la respuesta a esos problemas y ser capaz de solucionarlos. Pero volviendo al caso particular de la información geográfica, tenemos ya un proyecto muy consolidado de cartografía colaborativa, como es OpenStreetMap, que podría ser una alternativa para administraciones locales que no cuentan con muchos recursos para generar por sí mismas una cartografía propia y mantenerla. Incluso para entidades que sí los tienen, también es una opción. El ayuntamiento de Nueva York experimentó con ello hace años, uno de sus técnicos lo explica en este vídeo. ¿Por qué no seguir experimentando por esta vía?, ¿Por qué no darle una oportunidad a la cartografía colaborativa?. Para ciertas actividades de gestión es una fuente de información perfectamente válida, y complementaria a que para otros usos se siga necesitando otro tipo de cartografía más profesionalizada.

Por ejemplo, como ciudadano preocupado por la gestión de lo público, hice el experimento de tratar de conseguir, por mis medios, una cartografía actualizada, y más acorde con la realidad, de las calles de mi pueblo. Gracias a OSM la parte de conseguir la cartografía de las calles fue fácil, ya está ahí, libre para su uso. En su base de datos, con la etiqueta smoothness podemos establecer el estado. Aunque está pensada para definir como son las vías respecto al paso de vehículos, nos vale perfectamente para clasificar el estado del pavimento, desde excelente hasta muy mal, pasando por bueno, regular o malo. Con la parte tecnológica cubierta, conseguir el mapa de esta segunda imagen, me costó un pequeño paseo para revisar alguna calle por la que no paso tan a menudo y pongamos media hora de edición delante del ordenador.

De esta forma es muy sencillo poder visualizar en un mapa el estado de las calles, actualizado por quien todos los días está pasando por ellas. Con una fuente de información cartográfica, que para este tipo de uso, cumple holgadamente en términos de calidad. Aquí sí, el uso de tecnología es un medio para ayudar a resolver un problema. Tecnología libre además, y datos libres, como debería de ser todo lo relacionado con la gestión de lo público. Tenemos una ciudadanía, en su mayoría, sensibilizada y comprometida con la gestión de lo público. Si por parte de las administraciones se hiciesen y se planteasen las cosas bien, con transparencia, se podrían canalizar todas esas ganas de contribuir. El reto no está en conseguir la colaboración ciudadana, sino en que quienes gestionan las administraciones entiendan este tipo de cosas.

Bonus extra

Con este pequeño notebook de Jupyter, se visualiza la información actualizada de las calles obteniéndola directamente de la de la base de datos de OSM, a través de la API de Overpass. Puedes adaptarlo para hacer el ejemplo con tu pueblo, barrio, etc. De esa manera contribuirás a mejorar la base de datos de OpenStreetMap.