velardev

Promptly 07 - Perfil y licencia

2026-11-06T11:06:25Z

Promptly 01 - El arranque del proyecto
Promptly 02 - Listar prompts
Promptly 03 - Ejecutar un prompt
Promptly 04 - Publicar un prompt
Promptly 05 - Importación de prompts
Promptly 06 - Búsqueda de prompts
Promptly 07 - Perfil y licencia

Sesión 7

Punto de partida

Objetivos

El producto ya tiene un valor, desde mi punto de vista. Le podríamos agregar muchas más features, claro, pero considero que ya puede ser una herramienta sencilla y util para gestionar prompts. En este punto, creo que lo interesante antes de invertir más esfuerzo es sacarlo y recibir feedback.

Solo hay un aspecto último que me gustaría añadir antes a nivel funcional, y es una pequeña página de perfil del usuario + un selector de licencia al publicar los prompts. Si los usuarios quieren usar la app, aun manteniendo en privado su email, parece que tiene sentido que mantengan su pequeño espacio, que les identifique claramente como autores, y permita reconocimiento / enlaces a otros lugares que ellos manejen (por ejemplo, un enlace a una web de un profesor que escriba prompts para su asignatura).

Por otro lado, la propia licencia de los prompts me parece otro aspecto importante. Muchas veces los prompts son breves, y se comparten tal cual, sin esperar reconocimiento de ningún tipo. Otras veces, sin embargo los prompts son colecciones o razonamientos mucho más elaborados, a los que los autores quieren seguir vinculados... Ambas cosas se pueden resolver con el perfil de usuario + selector licencia prompt, así que las agrego a la lista y me pongo a implementarlas, como últimas features antes de lanzar la aplicación.

Tareas

Dejamos para el futuro otras ideas de features, pendiente de ver con los usuarios si son interesantes:

Ajustes de prompt (idioma de salida, tono, etc.)
Likes de prompts
Fork de prompt
etc.

Acciones

Perfil de usuario

Actualmente los usuarios se registran con 3 elementos: nombre de usuario, email (privado) y contraseña. Lo más flexible para dar voz (espacio en la UI) a los autores, es dejarles un espacio. Como me encanta la simplicidad y potencia del markdown (texto, enlaces, imágenes...), voy a añadir un espacio al registro que permita una pequeña "Bio" con .md. Y de paso, voy a ofrecer la posibilidad de cambiar dicha Bio y el Username, desde un espacio para editar el perfil.

Para acceder al perfil de un usuario (url tipo /profiles/promptly), se puede acceder desde la vista individual del prompt. He aprovechado para agregar también la búsqueda de prompts en el catalogo de un usuario y he linkado ambas vistas. La feature de forma conjunta se ve tal que así:

🔝para el render he usado la librería react-markdown , que siempre me ha dado buenos resultados.

Licencia de prompts

De nuevo, nos podríamos complicar aquí, pero vamos a ir una lista cerrada de licencias: las Creative Commons (CC), que me parecen las más adecuadas para prompts. Y para cubrir casos especiales, simplemente agregaremos una opción cajon de sastre "Otra", donde el usuario pueda escribir lo que desee (por ejemplo "MIT", pero en modo texto abierto, para simplificar).

La selección de tipo de licencia, desde la edición de prompts (modo privado) se ve tal que así:

Resumen

Vamos a sacar https://promptly.es y ver cómo se desarrolla 😄

Promptly 06 - Búsqueda de prompts

2026-11-06T11:06:25Z

Sesión 6

Punto de partida

Objetivos

Sin cambios

Tareas

Como ya señalamos en sesiones previas, el manejo de tags parece un elemento importante, lo trabajaremos en esta sesión. Sin embargo, vista la experiencia actual del listado de prompts, no parece que tenga sentido mostrar toda la info y las acciones en el listado de prompts (por claridad, por rapidez en las consultas...). Sería mejor mostrar esa info desde el detalle del prompt individual; así que voy a hacer primero algunos ajustes, simplificando la lista de prompts.

Acciones

Lista mejorada de prompts + username!

Solo nombre, autor y fecha del prompt en la lista sería lo ideal; solo hay un pequeño problema 😄: con el registro actual (email y clave), no hay nombre de usuario, solo email.

En este punto, creo que es razonable que se pida como input y se guarde al registrar al usuario, como el típico username único de toda red social. No creo que sea adecuado mostrar, por privacidad, el email de las personas que se registran; este solo es requerido para validar el signup / sign-in y si lo compartes, puede acabar en spam o correos no deseados.

Tiro un poco de ChatGPT, lo suficiente para averiguar que Supabase no da la feature tal cual, hay que currárselo un poco y saber lo que se quiere (precisamente porque exponer email u otros datos de los users es delicado). Me tropiezo con esta referencia, que a su vez apunta a la guia recomendada de Supabase para user-data y sigo su enfoque: básicamente un trigger y una nueva tabla para mantener users y sus nombres separados pero sincronizados.

[!info]
Por cierto, me he dado cuenta, al ir a mirar unos cambios WIP, que no tengo debugger para el lado server-side (sí para cliente, con chrome). Siguiendo la guía de NextJS se pueden poner ambos en VS Code: https://nextjs.org/docs/pages/guides/debugging#debugging-with-vs-code, y con esto en el proyecto es más fácil trabajar.

Esta es la vista simplificada:

Colecciones de prompts con tags / buscar

Las tags son un elemento central, pero en compañía de estas y para tener un buen catálogo, hay ciertos elementos que sí o sí deberían estar en el producto, así que con algo de ayuda de ChatGPT y GPT-4.1 en VSCode, implemento las siguientes features:

1. paginación
2. búsqueda por título
3. búsqueda por tag
4. ordenación (asc / desc, por título y fecha)

UX de la búsqueda

Como el objetivo al final es poder compartir fácilmente prompts, es interesante persistir el estado en la url, lo cual permite compartir búsquedas fácilmente...

Durante un rato le he estado dando vueltas también a la experiencia de uso de los tags. Por ejemplo:

he considerado que la búsqueda por tag no sea exacta, sino case insensitive
distintas formas de seleccionar las tags por UI
...

Después de revisar experiencias de otros productos, he decidido adoptar un enfoque que me gusta mucho y es sencillo, que son las labels en github: básicamente en la caja de búsqueda se permite escribir una sintaxis muy sencilla (label:nombreLabel) y esto permite de forma cómoda agregarlas a la búsqueda; en mi caso lo implemento, con tag:miTag. Este mismo sistema es extrapolable a otras propiedades en el futuro (por ejemplo, búsqueda por usuario, con user:username).

Por otro lado, para aplicarlas, basta con hacer clic en la tag, cuando aparecen asignadas (permitiendo algo como "buscar similares"): caja de búsqueda - url irán siempre acompasadas. Para el filtro, juego un rato con la UI y me decido por un dropdown sencillo, a la derecha de la caja de búsqueda.

La experiencia de este bloque se ve algo como:

Compartir prompt

Una vez la búsqueda está resuelta bien, la página clave es la vista pública del prompt. Una página sencilla, de solo lectura, para mostrar el prompt en sí, que implemento de forma rápida. La url será /prompts/[id_prompt]

Como está pensada como página pública, para compartir un prompt por ejemplo en una red social, es interesante dotarla de los metadatos en el servidor, basados en un estándar como OpenGraph. NextJS permite fácilmente usar su función generateMetadata para que se generen las previsualizaciones adecuadas al compartir.

Resumen

El producto va teniendo forma... Se incluye:

Promptly 05 - Importación de prompts

2026-11-06T11:06:25Z

Sesión 5

Punto de partida

Objetivos

No cambian.
Sin embargo, conforme trabajo en el proyecto, más claro tengo que si quiero que sea realmente útil tiene que tener algunos buenos contenidos de origen, es decir, un catálogo de prompts base, aunque luego la gente vaya agregando los suyos. Por esto mismo, he decidido buscar e importar prompts al sistema, antes de avanzar más en nuevas features, y agrego esto a la lista de tareas.
Hasta ahora he utilizado las urls 'autogeneradas' / aka feas pero gratuitas de Vercel. Pero está claro que un dominio propio es preferible. Agrego la tarea de configuración de dominio a mi lista.

Tareas

Acciones

Importación de prompts

La licencia Creative Commons CC0 en awesome-chatgpt-prompts permite una importación libre, y ChatGPT nos ayuda a generar un script para ello, en base a nuestras indicaciones de mapeo de campos. Me siento cómodo con el scripting en python, así que voy a ello (en este punto, aprovecho también para configurar el entorno con pyenv en local, requirements.txt y un fichero .env para las credenciales).

import pandas as pd
import psycopg2
import os

# Parámetros de conexión
conn = psycopg2.connect(
    host="TU_SUPABASE_HOST",
    dbname="TU_BD",
    user="TU_USER",
    password="TU_PASSWORD",
    port=5432,
    sslmode='require'
)

cur = conn.cursor()

# Cargar CSV desde URL
df = pd.read_csv('https://raw.githubusercontent.com/f/awesome-chatgpt-prompts/refs/heads/main/vibeprompts.csv')

# Función de transformación de cada fila
def transform_row(row, user_id):
    tags = []

    # Añadir contributor como tag si existe
    if pd.notna(row.get('contributor')):
        tags.append(row['contributor'].strip())

    # Añadir techstack separados por coma
    if pd.notna(row.get('techstack')):
        tech_tags = [tech.strip() for tech in row['techstack'].split(',') if tech.strip()]
        tags.extend(tech_tags)

    # Añadir el extra tag 'vibeprompt'
    tags.append('vibeprompt')

    return (
        row['app'],             # title
        row['prompt'],          # content
        tags,                   # tags (Postgres ARRAY)
        user_id                 # user_id
    )

# USER_ID: debes establecer tu UUID de usuario
USER_ID = "el-id-usuario-del-usuario-creado"

# Insertar cada fila transformada
for idx, row in df.iterrows():
    title, content, tags, user_id = transform_row(row, USER_ID)
    cur.execute("""
        INSERT INTO public.prompts (
            title, content, tags, user_id
        ) VALUES (%s, %s, %s, %s)
    """, (title, content, tags, user_id))

conn.commit()
cur.close()
conn.close()

print("Importación completada correctamente 🚀")

Por cierto, el hecho de que Supabase sea realmente un postgres accesible, que permita una conexión directa desde mi equipo local, es sin duda una gran ventaja. Normalmente los proveedores SaaS que montan sobre una DB no conceden acceso directo, por protección / seguridad o voluntad explícita, pero no es así en este caso, y es muy de agradecer,

Configuración de dominio

La compra del dominio la realizo en godaddy.com, donde tengo otros dominios. Encuentro libre promptly.es, en buenas condiciones de precio, así que voy a por ello.

Es sencillo y rápido de configurar el dominio con Vercel (básicamente es factible hacer una autoconfiguración desde su panel)

Resumen

Empieza a haber contenidos interesantes (yo mismo exploro la colección y veo algunas cosas curiosas). Estado:

Promptly 04 - Publicar un prompt

2026-11-06T11:06:25Z

Sesión 4

Punto de partida

Objetivos

Los mismos, principalmente de aprendizaje mientras se crea una herramienta sencilla pero útil.

Tareas

Registrarse para crear una cuenta
Logarse después
Persistir y recuperar prompts
Ejecutar un prompt
Copiar un prompt al portapapeles
Compartir un prompt
Catálogo de prompts públicos
Colecciones de prompts con tags
Ajustes de prompt (idioma de salida, tono, etc.)

Acciones

Compartir un prompt

Todos los prompts son privados por defecto, es decir que la app puede funcionar como un simple repositorio personal de prompts si se desea. Pero es innegable que compartir los prompts hará la experiencia mucho más valiosa, así que explotemos esto y desarrollemos la/s features necesarias para compartir un prompt públicamente.

Tener un prompt público se descompone en varios pasos o subtareas. Será necesario:

Indicador de privacidad: mostrar claramente en la lista de prompts si un un prompt es público o privado
Cambio de privacidad: permitir cambiar su privacidad fácilmente
Vista pública de prompt: preparar una página sencilla, que no requiera usuario, y permita ver el detalle del prompt, incluyendo al autor
- Si es público se muestra
- Si es privado, no funciona (404)

(1) Indicador de privacidad

Aprovecho la necesidad de editar la lista de prompts para refactorizar un foco y limpiar el componente. Con ayuda de Copilot y algunos toques manuales (+ pruebas, por ejemplo con el movil conectado)... avanzo hasta tener algo como:

(2) Cambio de privacidad

A golpe de prompt voy desarrollando la acción para Editar todo el prompt. Creo que es un buen primer paso: dejar editar todo en una nueva página (y no solo la privacidad en el listado, eso puede venir más adelante si es útil).

Un ejemplo del tipo de prompt que uso:

Que los botones ChatGPT y Copy no floten, sino que vayan dentro de un espacio común, llamado actions o similar, dentro de cada list-item. Que a ese espacio se le agregue una nueva acción, en forma de enlace llamado Edit. Que ese Edit abra una nueva página dashboard/edit-prompt (que se agregue como const en routes.ts). Que la pagina de Edit sea una versión que tome como base la página actual para 'create-prompt', dejando en no editable lo que corresponda (eg. created_at).

Previamente había ajustado un poco el formulario de create-prompt, para tener más espacio y una acción de Cancel. Para la edición, el modo Agente de Copilot en VS Code funciona perfectamente, y tras algunos ajustes visuales, queda una experiencia bastante completa.

Para simplificar, elimino de momento del modelo el campo 'description', pues diría que un buen title es suficiente, y ya era opcional. Aplicaré el cambio manualmente también en la DB.

Prompts

(3) Vista pública de un prompt

En realidad, el orden lógico diría que es programar primero el listado de prompts públicos (página /prompts) y luego el detalle (página /prompts/id). Para que funcione lo primero, el deberemos agregar otra Policy en la DB, donde cualquier usuario pueda leer aquellos prompts que sean is_public

CREATE POLICY "Enable read access for all users on public prompts"
ON public.prompts
AS PERMISSIVE
FOR SELECT
TO PUBLIC
USING (
  is_public
);

Y así conseguimos avances, especialmente en el primer bloque: La home muestra ya un enlace al catalogo, se puede usar leyendo los últimos 20 elementos (de momento sin búsquedas, filtros por tag, etc.)

Resumen

Promptly 03 - Ejecutar un prompt

2026-11-06T11:06:25Z

Sesión 3

Punto de partida

Objetivos

Los mismos, principalmente de aprendizaje. Pero hoy decido investigar un poco más y pensar más en detalle en los usuarios del producto, antes de avanzar más en la construcción.

¿Que existe similar?

Si esta iniciativa fuera un negocio, hubiera comenzado por aquí claro 😄... Viendo cosas similares en el mercado, parece que existen algunos "marketplace", para la compra-venta de prompts (como Promptbase o FlowGPT...), y también un listado gratuito e interesante de prompts en inglés, llamado awesome-prompts. Se ve interesante, pero contribuir prompts a golpe de commit no parece un flujo sencillo para usuarios no técnicos.

Sobre este último repo y listado existe http://prompts.chat, una app gratuita que los lista y también permite ejecutarlos, pasándoselos como parámetro a varios LLM y abriendo pestañas a los modelos online (eg: https://github.com/copilot).

Esto último, la forma de ejecutar rápidamente un prompt desde la app, abriendo una ventana nueva sí me parece una feature clave, así que la voy a desarrollar. Era evidente, pero no le había prestado interés inicialmente porque pensaba que me iba a requerir ejecución en línea, o lo que es lo mismo, tener api keys para los modelos (= añadir costes), pero como pasarela me encaja perfectamente.

Algunas ideas sobre el producto

Compartir
La gente crea prompts y los comparte ya... y esa tendencia irá a más. ¿Cómo lo hace ahora mismo? Pues con un modo manual, de hecho 100% manual, el creador le pasa el texto a alguien por mensaje, en red social, etc...

(+) Ventajas
- es sencillo y funciona
(-) Inconvenientes
- En el "Modo manual" se pierde la "autoría original"
- No hay un lugar para el feedback
- la catalogación queda del lado del receptor (si quiere volver al prompt más adelante, y volverlo a ejecutar, tendrá que gestionarlos por su cuenta). En el mejor de los casos, el historial de la herramienta le permitirá recuperarlo, pero a día de hoy (por ejemplo en ChatGPT), esto es un lio, más si la persona (como yo) le gusta probar varios prompt, y va saltando de uno a otro (muchas veces porque agota los niveles free tier de cada plataforma).
- Si se usa el 'share chat' nativo de la app, el prompt queda ligado a la herramienta. En general, y como norma para todo: mantén el control de tu información, y que pueda circular por varias herramientas (en este caso, varios LLM, fácilmente), evita el vendor lock-in...
- En general, la experiencia puede ser mejor

Colecciones y aprendizaje
Algunos pensamientos en alto:

(a) series de prompts: un prompt es muy útil, pero generalmente es solo el punto de partida, lo interesante suele ser una serie más elaborada, con preguntas enlazadas. ¿Tendría sentido relacionar unos prompts con otros linealmente en colecciones pensadas para ejecutarse en orden?
(b) aprendizaje: los prompts pueden servir para trabajo, para ocio... pero sin duda una de los usos principales que yo le veo es el aprendizaje (autónomo o guiado). ¿Tendría sentido hacer colecciones de prompts de aprendizajes sobre un tema?

El modelo de datos podría hacerse más grande y contemplar cosas como 'colecciones ordenadas de prompts', por ejemplo. Pero de nuevo... ¿que es lo más sencillo que puede funcionar?. Pues diría que los tags; ya hemos incorporado el campo al prompt en la DB y pueden servir como la formula más sencilla de agrupación de prompts, así que será el siguiente elemento en el que trabajaremos (después de la ejecución del prompt) . Además, si se quiere orden, pues puede ser tan fácil como usar un tag, por ejemplo "curso-programación" y luego usar nombres tal que "01 - Primer tema", "02 - Segundo tema", etc.

Tras esta parte de brainstorming / investigación, las tareas y su orden quedarían en algo como este mini-roadmap:

Tareas

Acciones

Ejecutar / copiar un prompt

Desde la app y fácilmente. Seguro se puede usar el API (pidiendo primero las credenciales al usuario y guardando su API-KEY en supabase, ofuscado), pero...¿cuál es la opción más sencilla? pues abriendo una nueva ventana externa con ChatGPT con el texto del prompt. Esto es trivial, usando la url que permite pasárselo como queryParam: https://chatgpt.com/?prompt=elPrompt. Más fácil imposible 😋.

En algunos casos, al usuario le vendrá mejor copiarlo para ejecutar de otra forma (ej. en una app local), así que programemos también un Copiar al portapapeles, que es trivial.

Resumen

En este punto, la app es funcional y se ve así:

Sobre la lista de tareas, este es el estado al terminar la sesión:

Promptly 02 - Listar prompts

2026-11-06T11:06:25Z

Sesión 2

Punto de partida

Objetivos

Se mantienen tal cual.

Tareas

Registrarse para crear una cuenta
Logarse después (gestión de la identidad)
Persistir y recuperar prompts

Los 3 elementos previos apuntan a que la app debe persistir los datos y hacerlo de forma segura (que los prompts sean de cada usuario y privados por defecto). Lo que es lo mismo, que un usuario liste y vea solo sus prompts y otro usuario los suyos. Esto se consigue de 2 formas tradicionalmente: una base de datos propia (cuando el usuario está por ejemplo en un entorno dedicado, o bien la plataforma crea una para cada cuenta) o la misma base de datos / tablas pero un sistema robusto de RLS (Row Level Security) que aisle los datos de cada cliente. Habitualmente lo 2º es más sencillo y eficiente en términos de costes, así que iremos por ese camino.

🔝Es claro que los requisitos funcionales (gestionar los prompts), van acompañados necesariamente de requisitos de otro tipo. En un enfoque de mínimos, comenzaremos por una seguridad / usabilidad básica... pero más adelante, si la cosa crece, habría que revisar otros como el rendimiento del sistema o su mantenibilidad.

Acciones

Persistencia

Crear tabla de prompts

Seguramente la estructura evolucionará, pero en una primera versión, y con ayuda de ChatGPT, esta es la estructura propuesta, con una sola tabla

CREATE TABLE prompts (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    title TEXT NOT NULL,
    content TEXT NOT NULL,
    description TEXT,
    tags TEXT[],
    is_public BOOLEAN DEFAULT FALSE,
    created_at TIMESTAMP WITH TIME ZONE DEFAULT now(),
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT now()
);

En Supabase no hay una tabla public.users, para hacer la FK. En la sección Authentication > Users muestra que existe sin embargo, con los campos UID, Display name, Email, Provider type, etc. Esta tabla se encuentra en realidad bajo auth.users, así que omitiremos el FK explícito, pero habrá que tenerlo en cuenta para manejar la integridad de los datos (con algún tipo de borrado manual en cascada). Reemplazamos pues: user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE con un simple user_id UUID NOT NULL

Privacidad de datos

Usaremos RLS. Inicialmente Supabase (mediante un asistente con AI por cierto para los SQL muy útil), sugiere unas reglas que tienen bastante sentido, para limitar, via CREATE POLICY las operaciones a nivel de SELECT, INSERT, UPDATE, DELETE. Si más adelante incluimos el is_public, crearemos otra policy para ver los prompts compartidos

-- RLS basica
CREATE POLICY "Authenticated users can view their own prompts" 
ON public.prompts 
FOR SELECT 
TO authenticated 
USING ((select auth.uid()) = user_id);

CREATE POLICY "Authenticated users can insert prompts" 
ON public.prompts 
FOR INSERT 
TO authenticated 
WITH CHECK (true);

CREATE POLICY "Authenticated users can update their own prompts" 
ON public.prompts 
FOR UPDATE 
TO authenticated 
USING ((select auth.uid()) = user_id) 
WITH CHECK (true);

CREATE POLICY "Authenticated users can delete their own prompts" 
ON public.prompts 
FOR DELETE 
TO authenticated 
USING ((select auth.uid()) = user_id);

🔝Supabase tiene una UI para definirlo, pero el SQL Editor es más flexible para crearlos.

Realizar unas inserciones de prueba / datos seed y pruebas

Hay librerías custom para generar datos 'semilla' de prueba, y muchas formas de hacerlo, pero lo más sencillo es pasarle el create table a un LLM cualquiera y pedirle N filas, con las restricciones que apliquen, por ejemplo:

sql
CREATE TABLE prompts (
    id UUID PRIMARY KEY DEFAULT gen_random_uuid(),
    user_id UUID NOT NULL REFERENCES users(id) ON DELETE CASCADE,
    title TEXT NOT NULL,
    content TEXT NOT NULL,
    description TEXT,
    tags TEXT[],
    created_at TIMESTAMP WITH TIME ZONE DEFAULT now(),
    updated_at TIMESTAMP WITH TIME ZONE DEFAULT now()
);


Generame 10 ejemplos de prompt para la tabla previa, para el usuario con id='18e3e69f-9723-462f-8e5f-edfca2e1232b', teniendo en cuenta que estoy utilizando Supabase, sobre un PostgreSQL 15.8

🔝Por cierto, este sería un buen ejemplo de un prompt a almacenar en la plataforma, como un ejemplo de generador de mocks de postgres. ChatGPT genera un snippet compacto, con generate_series, algo como:

-- Enable pgcrypto if not already enabled
CREATE EXTENSION IF NOT EXISTS pgcrypto;

-- Insert 10 random prompts
INSERT INTO prompts (user_id, title, content, description, tags)
SELECT
  'el-id-del-usuario-que-toque'::uuid,
  'Prompt #' || gs AS title,
  'Escribe un texto creativo sobre ' || 
    (ARRAY[
      'el futuro de la inteligencia artificial',
      'una conversación entre dos árboles',
      'una ciudad sumergida',
      'el último pensamiento de un robot',
      'un experimento fallido de viaje en el tiempo'
    ])[floor(random() * 5 + 1)] || '.' AS content,
  'Prompt auto-generado para hacer pruebas. Ref: ' || md5text AS description,
  ARRAY[
    (ARRAY['creatividad', 'tecnologia', 'ficcion', 'historia', 'misterio'])[floor(random() * 5 + 1)],
    (ARRAY['filosofia', 'futuro', 'ia', 'naturaleza', 'distopia'])[floor(random() * 5 + 1)]
  ] AS tags
FROM generate_series(1, 10) AS gs;

🔝Y esto se ejecuta sin problema en Supabase. Bien Supabase, bien 💌

Se puede tal vez agregar un tag extra, para borrarlos más adelante. Prompt en el propio Supabase, que tiene un interfaz en modo texto llamada "Assistant": Actualiza todo registro en "prompts" y agrega un tag "random_mock", respetando las tags actuales... mmm parece que ahora mismo no funciona bien (dicen que está en Alpha), vamos a ChatGPT y genera un SQL que funciona bien:

UPDATE prompts
SET tags = array_append(tags, 'random_mock')
WHERE NOT ('random_mock' = ANY(tags));

UI básica para prompts

Listar prompts
Ya tenemos datos de prueba, con 10 prompts para un usuario, así que podemos empezar por listarlos y ver el detalle de 1 de ellos.

Es muy sencillo con el cliente server-side para Supabase, las instrucciones en la template y un poco de ayuda de Copilot en VSCode para las clases de TailwindCSS, el resultado:

General: Modificar la UI para eliminar las referencias a la plantilla

Lo mínimo es eliminar algunos botones y referencias a la template. Aun quedará dead-code y cosas a limpiar en el futuro, pero sirve para avanzar. Vamos a usar como "nombre del proyecto": Promptly

Formulario para registrar el prompt

Se necesita un usuario logado, y otra página, por lo que es un buen momento para considerar por primer vez las "rutas" de forma más general, y los caminos que seguirán los usuarios.

Rutas

Hasta ahora tenemos estas rutas (cada una correspondiendo con un page.tsx de NextJS):
Actual

/: la "home", de momento con el contenido de la plantilla y solo para usuarios no logados. Seguramente modificaremos la lógica, pues idealmente los usuarios podrán obtener valor de la app, aun sin registrarse (pero también tras hacerlo: ejemplo últimos prompts subidos, búsqueda por tags, votos, etc.).
/sign-up: para crear la cuenta. Inicialmente activo solo el modo usuario & clave. Más adelante consideraremos social-login con Auth.
/sign-in: para logarse
/forgot-password: para recuperar el pwd via email
/protected: información privada del usuario. En este punto solo el listado de prompts del usuario
/protected/reset-password: para rellenar ese flujo relacionado con la clave.

Y considerando lo que queremos hacer, esta podría ser una buena estructura. Por simplicidad, dejemos fuera cuestiones en el diseño de las urls como paginación, filtros, etc. (que veremos más adelante).

(a) Rutas públicas

Ruta	Descripción
/	Home pública
/prompts	Catálogo público de prompts. Navegable, con filtros por tags, nombre, etc.
/prompts/[id]	Detalle de un prompt específico. Accesible sin login.
/sign-up	Registro de usuario.
/sign-in	Login de usuario.

(b) Rutas privadas

Ruta	Descripción
/dashboard	Página principal del usuario logado. Puede listar sus prompts, perfil, etc.
/dashboard/prompts	Listado de prompts del usuario logado (tipo /protected actual).
/dashboard/prompts/new	Crear nuevo prompt.

Home con logo

Limpieza básica de Home y su componente "Hero" (+ permitir que no fuerce la redirección a dashboard)
Cambiamos el texto y creamos un logo con ayuda de ChatGPT

Hazme un logo sencillo, en SVG que diga "Promptly", con la P más destacada, tomando como referencia algo similar a este de NextJS:

--y-le-pego-el-SVG-tal-cual-de-NextJS (omitido)

Y nos genera algo para empezar...

Vale sí, es bastante feo, pero sirve para empezar. Además, como es un SVG con el fill="currentColor", se adapta también a la feature de theme de la template (tema oscuro), por lo que de momento👌.

Crear y listar prompts

Nueva estructura para la zona privada (componentes y esbozo de interfaz)

Las rutas son algo importante y en lo que es fácil cometer errores. En la plantilla actualmente las rutas están hardcodeadas, y repetidas en varios lugares. Vamos a crear un fichero "routes.ts" para tenerlas controladas y poder cambiarlas después sin romper.

Tras varios refactor, con algo de ayuda de ChatGPT / Copilot se puede avanzar y tener una app funcional para el flujo básico: guardar y listar prompts de un usuario en modo privado.

Resumen

En este punto, ya tenemos:

Una home básica, con una hero section + logo, adaptada al proyecto, bautizado con Promptly
Una estructura básica de UI para las distintas páginas
La capacidad de hacer los flujos básicos de un usuario: sign-in / sign-up / forgot-password, con tipo usuario-password
La feature de crear un Prompt con sus campos básicos y que se persista
La feature de listar los Prompt de un usuario, gracias a Row Level Security.

Si revisamos la lista de tareas tenemos:

Registrarse para crear una cuenta
Logarse después (gestión de la identidad)
Persistir y recuperar prompts

Promptly 01 - El arranque del proyecto

2026-11-06T11:06:25Z

Con este post inicio una serie sobre la construcción de un side-project que he llamado Promptly, para la gestión de prompts de IA. Iré enlazando aquí los posts conforme los vaya publicando, para que sea más fácil navegar entre ellos.

Si simplemente prefieres probarlo, ve a https://promptly.es. Si tienes curiosidad cómo lo he creado, sigue leyendo.

Objetivos

Problema / Oportunidad

Realizar buenas preguntas a los modelos de IA (generalmente a través de interfaces como ChatGPT, Claude, etc.) es a veces complejo.
Los LLMs que los soportan son muy potentes, pero también muy abiertos y aún existe poca experiencia colectiva sobre cómo usarlos.
Partir de una pregunta / prompt puede ayudar mucho y servir de inspiración para explorar / profundizar siguiendo ese modelo.
La gente comparte, cada vez más, sus prompts (por ejemplo en Twitter, LinkedIn, etc.)
Existen varias alternativas online para almacenar prompts, pero la mayoría siguen un modelo de marketplace (y además son en Inglés, lo que supone una barrera para algunas personas).

Reto

Crear un lugar donde gestionar los prompts y poder compartir, descubrir y probar de forma sencilla otros nuevos puede ser muy útil.
Construir algo así, pero también describir el proceso y las decisiones, me parece una experiencia interesante profesionalmente, así que voy a hacerlo a través de varios post sucesivos, describiendo lo realizado, sesión a sesión (de forma orientativa, una sesión puede ser un bloque aproximado de tiempo de 1 a 2 horas aprox).

Proceso

En cada post iré recogiendo el proceso de construcción y seguiré un esquema parecido:

1. Punto de partida: los requisitos en ese punto (que irán cambiando conforme avancemos)
1. Acciones: cosas concretas hechas esa sesión para avanzar en la construcción del proyecto
1. Balance: un balance de la sesión, revisando los resultados

Sin más dilación, vamos a ello, con la primera sesión de trabajo.

Sesión 1

Punto de partida

Objetivos

A alto nivel estos serían los objetivos actuales del proyecto:

Quiero permitir guardar prompts para poder gestionarlos / usarlos mejor.
Quiero a la vez hacer involucrarme en un proyecto que me permita aprender más sobre algunas tecnologías (NextJS, TailwindCSS y otras)
Quiero usar lo que sea más sencillo y rápido / barato.

Tareas

Vamos a sacar una lista primera de tareas (o requisitos si se quiere), para construir el proyecto. Lo que quiero es dejar al usuario guardar sus prompts, pero para conseguir esto, se necesita un mínimo de elementos previos (infraestructura):

Registrarse para crear una cuenta
Logarse después
Persistir un prompt

Y todo esto debe ser seguro, claro: que los prompts sean de cada usuario y privados por defecto.

Venga, pues con este punto de partida, vamos a ponernos manos a la obra.

Acciones

Elección de plataforma

Firebase

Una forma que conozco y seguramente funcionaría bien es Firebase; ya lo he usado para algunos proyectos en el pasado, incluyendo la gestión de la autenticación y la persistencia de JSON (su motor Firebase es NoSQL) y los updates en tiempo real, y funciona muy bien, sin duda. Seguramente podría probar el nuevo Firebase Studio... pero me gustaría más usar un motor SQL estándar... así que voy a ver otras opciones en GCP.

PostgreSQL en GCP

He trabajado con muchos tipos de base de datos: SQL Server, Oracle, Postgres, ClickHouse... pero como lei en alguna ocasión: "en caso de duda, usa postgres". Así que he echado un ojo a mi cuenta Google Cloud Platform (GCP), y veo que actualmente una instancia gestionada de Postgres 16, con 2 vCPU y 8 GB + 10 GB SSD cuesta (en Iowa) $0.14/hora, lo que vendría a ser aprox $102 dólares al mes (en Europa GCP es más caro, y sobre un coste unitario de $0.17 hora, se iría hasta casi $125 mes, pero para un prototipo / side-project la latencia no me preocupa demasiado).

A pesar de que tengo un descuento disponible en GCP, la verdad, 0 € para arrancar me sonaría mejor, y me apetece probar algo menos enterprise que GCP.

Supabase

Y así he llegado hasta Supabase, que se vende como una alternativa open-source a Firebase e incluye Postgres y un plan inicial de $0 / mes. así que le voy a dar una oportunidad.

Creación de proyecto "promptly" en region West Europe

[!info]
El plan en Supabase tampoco es para tirar cohetes, veremos después como se comporta. Se trata del plan Nano = $0 / hour (up to 0.5 GB de memoria y una CPU Shared) + Disk size: 1 GB

Creación de la app

Hoy en día existen muchas fórmulas, pero me apetece profundizar más en NextJS. Un proyecto NextJS "normal", puede ser creado en local fácilmente con

npx create-next-app@latest

Pero también se admiten 'templates' o plantillas pre-configuradas. Este es el caso de Supabase, ya que existe una plantilla oficial que facilita el arranque:

Creación del proyecto NextJS con la plantilla oficial de supabase

npx create-next-app@latest -e with-supabase

La plantilla

Parece que la template tiene buena pinta, con instrucciones claras en la página principal para tener el proyecto bien conectado al entorno e incluso un formulario de sign-up integrado + Sign in.

El proyecto incluye:

Una home que se loga y verifica que tiene acceso al proyecto
Una cabecera con el típico Sig In / Sign out
Un formulario para Sign up
Una pagina privada (/protected)

Técnicamente, la plantilla incluye este stack:

dependencies:
- next: latest (hoy 15.3.1)
- react: 19.0.0
- @supabase/ssr: latest (hoy 0.6.1)
- @supabase/supabase-js: latest (hoy 2.49.4)
- @radix-ui/react-\*: varios paquetes paquetes de UI. Ver aquí
dev
- typescript: 5.7.2
- tailwindcss: 3.4.17

Y existe un .env que puede fácilmente usarse de plantilla para conectar al proyecto supabase real desde local (env.local), simplemente rellenando estas variables:

NEXT_PUBLIC_SUPABASE_URL=https://tu-url-de-proyecto-en.supabase.co
NEXT_PUBLIC_SUPABASE_ANON_KEY=tu-clave-para-conectar-ver-dashboard-en-supabase

Configuración del proyecto NextJS contra Supabase y creación del primer usuario
Para probar la plantilla y la parte privada, procedo a crearme un usuario. La aplicación se puede ver en local y jugar con ella fácilmente, como en cualquier otro proyecto NextJS

npm run dev

Primer despliegue

Ok, arrancamos con la plantilla tal cual, sin modificaciones, pero siempre gusta ver el producto en funcionamiento en un entorno real. Se podrían usar varios entornos, pero el más natural para NextJS sigue siendo Vercel, tal y como aconseja la plantilla. Como ya tengo una cuenta gratuita de Vercel, procedo a enlazar mi proyecto git local con estos pasos:

Subir proyecto git a Github (enlazar y subir el repo local, inicializado por la template)
Configurar el proyecto en Vercel, importando ese proyecto de github (en este caso, llamo al proyecto de Vercel de la misma forma que el repo: "promptly").
Para que todo funcione ok en otros entornos (más allá de localhost:3000) es preciso configurar las redirecciones de URLs adecuadas a los dominos usados.

La propia template detecta y propone las URLs, lo cual es un muy buen detalle de devX por parte de Supabase:

This particular deployment is"production" onhttps://promptly-m15aqmuuq-velardev-projects.vercel.app.

You will need to [update your Supabase project](https://supabase.com/dashboard/project/_/auth/url-configuration) with redirect URLs based on your Vercel deployment URLs.

- http://localhost:3000/**
- https://promptly-gilt.vercel.app/**
- https://promptly-gilt-*-[vercel-team-url].vercel.app/** (Vercel Team URL can be found in [Vercel Team settings](https://vercel.com/docs/accounts/create-a-team#find-your-team-id))

Resumen

En este punto, tenemos:

Un proyecto "promptly" en Supabase, inicialmente vacío
Un repo privado "promptly" en Github, con el proyecto NextJs de plantilla de supabase
Un proyecto "promptly" en Vercel, vinculado a Github, para el hosting de la app.
El proyecto desplegado por primera vez en una url pública

Sobre la lista inicial de tareas, terminamos la sesión con algo como:

Registrarse para crear una cuenta
Logarse después
Persistir y recuperar prompts

Con la IA tu trabajo es aprender

2026-10-14T00:00:00Z

Con la IA tu trabajo desarrollando software es más que nunca aprender. Aprender lo que necesita tu usuario y aprender de tu propio sistema.

Tradicionalmente, mientras escribías los ficheros fuente o resolvías un bug complicado, construías en tu cabeza un conjunto de modelos mentales. El resultado era siempre doble: uno tangible (los fuentes y sobre todo el sistema en ejecución) y otro más intangible, interno, en forma de aprendizaje y heurísticos, del que seguramente no te dabas cuenta.

Ahora el proceso de escritura del código (y de resolver bugs, y de cada vez más cosas) lo delegas en la IA, un cambio que ha sucedido muy rápidamente (recuerdo ser un poco escéptico al principio, cuando leía que Boris Cherny de Anthropic desinstaló su IDE, pero desde luego no lo soy, en 2026 es realidad al 100%). Y un problema derivado es que esos modelos mentales dejan de formarse naturalmente en tu cabeza. O ya los tenías o te toca currártelo. Esto es importante para todos, pero especialmente para desarrolladores más junior, que no han tenido experiencia durante la era pre-IA.

Vamos a partir de la premisa que este aprendizaje será siempre gradual, y también que quieres ser lo más productivo lo antes posible. Así que hablemos de los pasos mínimos para poner una feature en producción y algunos consejos en cada paso.

Aprender a navegar

Créate un esquema visual del sistema

Si empiezas con un sistema nuevo (o en una nueva empresa) y el sistema no es trivial (spoiler, casi nunca lo será), quieres tener un mapa mental para poder navegarlo. Pídeselo a tu LLM de referencia y que produzca un resultado visual, pero luego no lo dejes ahí, revísalo un buen rato (tómate un café y analízalo bien): pregunta sobre la arquitectura, los componentes más complejos, los puntos que no te convenza su diseño...

Debes tener claras al menos 2 vistas: la vista lógica del sistema + la vista real de los componentes que se despliegan en tu cloud.

Que el trabajo de exploración sea iterativo: ve realizando preguntas al LLM y mejorando poco a poco los diagramas / notas que tomes. Si no tienes nada claro qué preguntar… háztelo mirar :). Y si tienes algún sistema organizado para tomar tus notas, en algo como Obsidian / un cerebro digital, +100 puntos.

Lógicamente, si alguien ha escrito algo previo al respecto o puede darte un paseo en una reunión, pues te va a venir muy bien, aprovéchalo. Pero idealmente haz el trabajo antes y ve ya con preguntas a esa persona: ¿por qué se ha hecho esto así? ¿Cuáles son las partes más complejas, que funciona mal y queremos cambiar pronto?

Esto aplica a menor escala también, claro, lo puedes aplicar con distinto nivel de zoom a piezas más pequeñas como un subsistema.

Aprende del Producto

La feature que te toque: entiéndela. Para qué sirve y por qué es importante para el usuario. No, de verdad, ¡entiéndela!. Muchas veces los desarrolladores han programado soluciones sin entender realmente lo que hacían. Y si ya la entiendes, intenta crecer ese conocimiento en temas relacionados (¿qué viene después?¿cómo encaja esto en el flujo general?¿se puede mejorar algo?)

Conforme avances en tu conocimiento, crecerá la calidad de lo que haces y tu impacto.

Crear la feature con IA

No tengas skill-itis

Tener una subscripción a Claude o ChatGPT debería bastar. Hay un montón de ruido en línea sobre mejoras, skills, prompts… pero mi consejo es que no tengas “skillitis”, y te vuelvas loco con mil historias (que lo más probable es que contaminen el contexto si no están claras y ordenadas). La tendencia parece ser que conforme los modelos crecen más en potencia, las skills son menos necesarias, pero al menos siempre habrá un mínimo sobre “cómo os gusta hacer las cosas en tu equipo”, osea que algo podrás afinar.

Ten un proceso básico de desarrollo

En mi experiencia, la clave no son las skills sino tener claro el proceso de desarrollo que quieres seguir y cuáles son los puntos clave donde encajas tú como humano vs lo que hace la IA. Esto puede cambiar en función de tu equipo, experiencia, hábitos… no hay una bala de plata, pero es bueno que al menos haya un consenso básico en el equipo.

Dicho esto, y si aun no tienes un proceso claro, te animo a probar cosas como las de Addy Osmani Agent Skills, un tipo listo que ahora además se ha ido a trabajar de Google a Antrophic, algo sabrá.

Los dos puntos más importantes: que la especificación inicial esté clara y que esté claro cómo vas a probar que lo desarrollado lo cumple.

Estilo de desarrollo flexible

Aprende a leer el contexto de tu empresa para saber el estilo de desarrollo que te toca en cada caso. A veces toca ir lo más rápido posible, cuando se trata de validar una idea. No tiene sentido invertir en alta calidad (aún) si es un sólo un prototipo para 1 o 2 clientes, bajo feature flag. La inversa aplica también, si por ejemplo trabajas en un proyecto con una pasarela de pagos para cobros automatizados, invierte en calidad o te morderá en producción, y no querrás estar ahí.

Revisar la feature en equipo

Hazte CR

Con LLM, a mano, como quieras, pero por respeto: no le lances algo a un compañero un PR sin haberlo mirado tú antes con ojos críticos. Antes los PRs los ‘esculpías’ paso a paso, tenías 100% claro lo que incluían, cada línea, cada IF... Ahora si vas deprisa y no te das cuenta, lo mismo metes en el PR un tema secundario que toca 10 ficheros (porque lo discutiste con el agente y no quedó claro si iba en scope).

Si tenéis alguna acción de revisión automática con IA en el CI, mírala antes de que te diga lo mismo un compañero, no?

Cuida la descripción de tus PR

Ya sabemos que los modelos abren y cierran PRs como locos, pero también que luego a veces es imposible entender eso de forma clara desde el otro lado. La comunicación clara es un punto esencial.

Yo trabajo bastante con interfaces así que +100 a usar imágenes o un pequeño video explicativo de los cambios, siempre ayuda mucho. Si son APIs, pues mete unos curl de prueba / descripción de payload: todo lo que facilite el trabajo al revisor. Ojo, que puedes pedirle pantallazos, videos, planes de pruebas… a tu LLM. No digo que hagas todo a mano, pero sí que te leas / entiendas / modifiques a tu criterio todo antes de que llegue a una persona.

Del otro lado, como revisor, siempre espero algo como una explicación clara en 2 líneas de lo que hace el PR y un soporte gráfico de lo que hace (pantallas, diagrama de arquitectura…) / listado áreas que toca. Si el creador no te lo da, pues ya sabes, se lo puedes pedir al LLM cuando empieces lo primero.

Prueba bien la feature

Ya, ya, que pruebas a cada paso, en tu local, que tienes tests unitarios, de integración, de e2e… pero hombre prueba bien lo que has hecho al final (generalmente en el entorno dedicado asociado al PR).

Bonus, si te grabaste un mini-video (tipo Loom) y/o si le pediste a tu LLM unas pruebas de aceptación contra el dedicado.

Llevar la feature a producción

Decide para qué clientes / entornos se activa

Aquí los feature flags y las estrategias de despliegue son la pieza clave. Si no has trabajado con estos sistemas, pruébalos, ya!, merecen cada hora invertida.

Vigila las migraciones

Una buena gestión del modelo de datos, y en especial de las migraciones, es una de las claves de cualquier puesta en producción. Revísalas, pruébalas a fondo. Durante la CR dedica especial tiempo a ese bloque.

La IA podrá ayudarte más adelante a cambiar el código, pero no inventarse datos críticos de negocio que no generaste o perdiste por un bug.

Piensa la observabilidad desde el principio

La observabilidad es una cualidad clave del sistema, no algo que se añade al final. Diseña desde el principio cómo se va a ver la feature en producción y cómo la vas a poder observar (tú o un agente, claro).

Eso implica desarrollar teniendo especialmente en cuenta las trazas. Algunas cosas que puedes hacer:

Antes de escribir código, pregúntate (o pregúntale a tu LLM): ¿cómo voy a saber en producción que esta feature funciona y que la usan?. Apunta 2 o 3 señales: un evento al completar el flujo, un contador de errores, el tiempo de la operación nueva...
Mételo en la especificación: pide trazas en los puntos clave, con el identificador del cliente, para que nazcan con el código y no se añadan después.
Antes de mergear, con las métricas ya activas en desarrollo o integración, pídele a tu herramienta (por ejemplo Honeycomb) el dashboard de la feature y comprueba que cuenta lo que esperabas.

La IA es una gran revolución, sin duda, y las técnicas van a seguir cambiando: lo que hoy es una skill mañana será una capacidad más del modelo. Pero muchos principios se mantienen, y a mí me parecen especialmente importantes tres:

Comunicación: que cualquiera (tu compañero, el revisor, tú mismo dentro de seis meses, el agente…) entienda qué hace el sistema y por qué.
Vigilancia de los pasos clave: delegar la escritura en la IA no es delegar la responsabilidad. Hay puntos donde sigues tú: la especificación, tu propia CR, la prueba final y sobre todo lo que pasa en producción.
Valor al cliente: el código siempre es un medio. Lo que cuenta es que lo que has construido le sirva a alguien.

Y por debajo de los tres, la premisa de todo el post: tu trabajo es aprender. La IA puede escribir el código, pero no puede aprender por ti. Úsala para aprender más y mejor, no para dejar de hacerlo.

Con la IA los programadores ya vivimos en SimCity

2026-04-13T00:00:00Z

Si has jugado alguna vez SimCity, ya conoces a buen seguro algunas cosas de las que te voy a hablar. Si no, mejor échate una partida primero (aunque sea casual y en el móvil…) y luego vuelve por aquí a leer el post 😄

Si eres buen jugador de SimCity, te las arreglarás bien con la IA en los próximos años

Hay un momento en SimCity en el que dejas de intentar controlarlo todo al milímetro y empiezas a entender el juego.

No construyes las casas con tus propias manos. No conduces los coches de la gente. No llevas cubos de agua para apagar un incendio. Lo que haces es diseñar el sistema: zonas, infraestructuras, políticas, flujos… Y luego dejas que la ciudad funcione y crezca, ayudado por tus asesores. Tu papel es guiar y monitorizar todo, para intervenir y mejorar la ciudad (y ahí es cuando juegas y te diviertes, vaya)

Si en algún momento has liderado un equipo de ingeniería, estoy seguro que te suena.

Andy Grove (Intel) formuló la clave con precisión hace décadas: el output de un manager es el output de su equipo, más el de los equipos bajo su influencia. El manager no es el que más produce individualmente, es el que diseña el entorno donde otros producen más y multiplica su impacto.

Y estoy convencido que exactamente lo mismo aplica hoy al desarrollador que trabaja con agentes de IA. Tu rol es hacer que el sistema para desarrollar software en tu empresa funcione y produzca lo mejor posible.

El problema de la multitarea (propia)

La multitarea es una trampa bien documentada. El coste de cambio de contexto es real, el foco se fragmenta y el resultado final es siempre peor que si hubieras hecho una cosa a la vez.

Pero hay otro tipo de multitarea que nadie critica: la de los demás trabajando en paralelo para ti, de forma bien coordinada.

En SimCity, mientras tú lees un informe de tráfico, los bomberos apagan un fuego, los obreros terminan una carretera y los ciudadanos van al trabajo. No estás haciendo nada de eso en primera persona: tú estás pensando en el siguiente movimiento estratégico o bien atendiendo algún problema puntual urgente que solo tú puedes resolver.

Eso es exactamente lo que ocurre cuando tu equipo de software funciona bien. Y es exactamente lo que ocurre cuando los agentes de IA funcionan bien en tu proyecto: eres capaz de hacer más a la vez, porque delegas trabajo sustancial a los agentes de IA. Usa esa capacidad y los agentes, hasta el punto en el que sientas que controlas lo que haces (vigila tu carga cognitiva y nivel de energía), y esfuérzate en aprender cómo ampliar tu radio de impacto.

Gas Town y la IA

En SimCity es habitual, como en el Urbanismo en general, diseñar un distrito industrial, especializado en producir energía y recursos para el resto de la ciudad. De nuevo, tú no gestionas cada tubería o conducción eléctrica hacia él, solo te aseguras de que la zona esté bien conectada, financiada y sin conflictos con las zonas residenciales.

Y no creo que sea casualidad que a principios de 2026 Steve Yegge haya creado un software llamado Gas Town, un sistema para fabricar software con múltiples agentes IA orquestados, que pretender ser una alternativa a los IDEs tradicionales.

Gas Town sigue unos principios similares a SimCity: un alcalde que coordina a otros agentes (también antropomorfizados), hay factorías, refinerías... y tú trabajando con el sistema en un plano de control, necesariamente cada vez más abstracto y estratégico (como por otra parte siempre ha sucedido en el ámbito de la Informática).

Gas Town es (aún o tal vez será para siempre...) una herramienta bastante caótica y compleja y es una ciudad (perdón sistema) que gasta muchos tokens... Pero estoy convencido que varias de sus ideas guiarán las herramientas de creación de software en el futuro. Si te suena interesante, creo que merece la pena probarlo al menos y luego leer esta revisión crítica de Maggie Appleton, del área de innovación en GitHub: https://maggieappleton.com/gastown

El plano de control

En SimCity, el alcalde tiene un dashboard. No ve todo el tiempo cada tramo de tubería de gas, ve los indicadores que importan: tráfico, criminalidad, satisfacción ciudadana, presupuesto... Y actúa cuando algo requiere su atención directa e inmediata. Y probablemente el alcalde no se conforma con que su ciudad simplemente siga igual, sino que siempre tendrá uno o dos proyectos ambiciosos, para los que está preparando un plan y buscando financiación… así que trabaja en multitarea, repartido entre lo estratégico a medio largo plazo y lo operativo del día a día

Y yo en mi día a día como desarrollador siento algo parecido: interactúo con agentes de IA y compañeros, buscando esas señales correctas para actuar y a la vez mantener un buen equilibrio entre la multitarea y sacar bloques sólidos de trabajo (sea un plan para una nueva feature, un bug en producción o una actualización rutinaria de seguridad).

Actualmente uso herramientas variadas como la terminal con tmux (si algo en tech lleva casi 20 años vivo y la gente lo sigue usando, merece la pena echar un ojo, efecto Lindy en estado puro), Claude Code web / desktop, Craft Agents, MCPs contra Honeycomb, Postgres o Slack, y mi uso del IDE se ha reducido mucho (ahora uso Cursor, pero todos son similares)… pero siento que aún no he encontrado la configuración / herramienta ideal. Sigo buscando y se aceptan sugerencias, por cierto...

Estoy convencido que la industria de la IA y el desarrollo de software en general avanzarán en este plano de control pronto, es muy necesario.

Pero también estoy seguro que las señales para la acción, los dashboard de indicadores clave, mejorarán mucho con la IA: de simples dashboard técnicos con cientos de variables y gráficos no relevantes + dashboards de negocio con datos del trimestre pasado, a dashboards generados por agentes, con datos en tiempo real y mucho menos ruido y más señal:

No "El sistema funciona".
No "Hay 200 errores en el log", y búscate la vida...

Sino algo como "Esta es el Top 4 de los problemas de esta semana en tu SaaS", realizada con ayuda de agentes IA, por ejemplo:
- la latencia en la API XXX ha empeorado un 15% los últimos 10 días, y hay previsto el onboarding de un cliente grande a finales de mes, ¿arrancamos un proyecto de mejora?
- ¿Priorizamos la resolución de estos 5 bugs concretos, dado que afectan a 2 clientes con riesgo de churn que renuevan este mes?
- El tiempo medio de onboarding del último cliente ZZZ ha sido casi el doble de la media...¿ha comunicado algún problema concreto a customer success / ha habido algún bug o caída puntual de la plataforma que haya podido afectar a su experiencia?
- La competencia ha sacado esta feature el mes pasado, ¿merece la pena lanzar un prototipo rápido en nuestra plataforma para ver si somos capaces de incorporarla?

La crisis del programador, una cuestión de identidad

Hay algo de lo que quizá no se habla suficientemente en esta conversación sobre IA y el futuro del trabajo técnico: la identidad del trabajador inmerso en estos cambios. Tendemos a identificarnos con lo que hacemos: soy programador. Y cuando lo que hacemos cambia radicalmente, la pregunta se vuelve incómoda: si ya no programas línea a línea, ¿qué eres?

El término programador tiene un anclaje muy concreto y una tradición histórica amplia: escribir código todo el día. Si el código lo generan ahora los agentes, el anclaje se rompe. Y con él, parte de tu identidad. Por eso mucha gente se siente perdida, con pena o incluso miedo a los cambios de la IA.

Creo que se trata simplemente de abrir el foco y ver donde están ahora los verdaderos problemas, donde está "el juego". Y los problemas grandes ya no están tanto en programar algo o aprender un lenguaje para crear un sistema; están en planificarlo, diseñarlo con una visión humana y sobre todo comprobar que funciona y sacarle valor a escala.

Si necesitamos etiquetas, creo que hay otros términos que encajan mejor en esta etapa: ingeniero o simplemente desarrollador:

ingeniero, en su sentido original, el de "ingeniárselas para resolver problemas".
desarrollador: el creador de una solución técnica, de una idea de negocio... en definitiva de un sistema que funciona.

Los ordenadores nos dan la base para abordar problemas cada vez más complejos. Pero lo que importa es sobre todo lo que construyes, no el ritual específico o herramienta con la que lo construyes.

Creo que la IA no elimina al desarrollador. Elimina al programador cuyo valor está solo en teclear. El que sobrevive y prospera es el que entiende sistemas, toma decisiones y sabe orquestar las herramientas IA disponibles hacia un resultado tangible y útil.

Cuando lleguen los incendios...

Eso sí: prepárate. Porque de vez en cuando llegarán los incendios. En SimCity, los desastres no avisan. Incendio, terremoto, tornado o monstruo marino. De repente todo el sistema que habías diseñado necesita intervención directa, urgente y manual.

Con los agentes de IA pasa igual. Habrá momentos en que el contexto falle, la coordinación se rompa o el output sea basura. Y ahí tienes que estar tú, con las manos en el código y un conocimiento suficientemente profundo de lo que tienes entre manos, como para operar y corregir el sistema.

El objetivo no es desaparecer del sistema. Es tener el sistema lo mejor construido posible, y que tu intervención sea la excepción, no la regla.

[!Aprendizaje]
El conocimiento aplicable tradicionalmente se ha forjado "en las trincheras", mediante la práctica de la construcción de esos sistemas de forma más manual... si eso no se produce ahora durante la producción, hay que aprender igualmente; consejo: lee, experimenta, pregunta y re-pregunta... usa la propia IA para aclararte cualquier duda que puedas tener sobre lo que tus compañeros o tú mismo estáis generando en el código. Si te saltas ese proceso, alguien pagará el coste.

Todo lo que vivimos ahora mismo en el mundo del software no es sino la avanzadilla de lo que en breve inundará toda profesión y no creo que tenga sentido tenerle miedo o intentar postponer lo inevitable.

Una de las personas que más admiro en el mundo del software es Kent Beck (creador de XP, TDD...). Bueno, pues este señor, con 65 años no para de experimentar y publicar cómo trabaja cada día mejor con la IA (o como el la llama "the Genie") para potenciar su trabajo... así que no hay excusas.

Abraza el cambio que supone la IA, el impacto de lo que vas a poder hacer se va a multiplicar, no tengas miedo.

Obsidian como herramienta para un cerebro digital

2025-02-19T00:00:00Z

Me gusta anotar cosas, es así. Y se podría decir que le dedico, según la temporada, un cierto esfuerzo. Tanto a hacerlo como a revisar o mejorar cómo lo hago (qué escribo, con que herramientas, cómo organizo mis notas…).

¿Por qué lo hago?

Bueno pues simplemente porque creo que pienso más y mejor cuando escribo. En general no escribo cosas muy largas, ni tampoco “literarias” (ya me gustaría… ¿a lo mejor algún día?). Se trata de notas generalmente no muy extensas, sobre algo que me interesa, proyectos/tareas, investigaciones técnicas, notas sobre un libro que me gusta… y, cada vez más, "notas reflexivas” sobre lo que pienso y que me ayudan a tomar decisiones.

A veces tener algo escrito y a la mano me sirve para contestar o compartir algo de interés con otros, es cierto, pero la mayoría de las veces escribo para mi. Escribir me centra, a veces me desahoga y me sirve para cosas del trabajo, cosas de casa, cosas más personales… y estoy descubriendo poco a poco lo potente que es releer / reescribir / completar / borrar cierto tipo de notas… (sí, también borrar, no me seas Diógenes).

Lo de “cerebro digital” suena un poco a marketing barato la verdad, quizá me gusta más algo como “sistema de notas”, pero es el término por el que puedes buscar más info al respecto si te interesa el tema.

Pero bueno, este post pretende recoger un par de consejos sobre una herramienta y un sistema / libro, más que hablar de las bondades de escribir, así que al grano.

Obsidian

En los últimos años he pasado por distintas herramientas (Evernote, Notion, libretas en papel…). Todas han tenido para mi su momento y sus ventajas, pero he ido migrando. Hace años pasé de Evernote a Notion, buscando más flexibilidad y features, pero al final ambas comparten muchos principios: modelo cloud de subscripción anual, formatos cerrados, búsquedas, tablas... Por cierto, la migración de notas de una a otra fue un dolor y tuve que invertir bastante tiempo en revisar / importar manualmente cosas; esto no es casual claro, las apps quieren mantenerte cautivo.

¿Por que Obsidian?
Como programador, la herramienta encaja bien con mi modelo mental y los principios de control / libertad / flexibilidad que valoro, porque respeta en gran medida el principio de separación modelo vs. vista.

Las notas serían el modelo, en un formato markdown que no me tiene cautivo en la herramienta (las puedo editar sin problema con otro software y sobre todo sigo teniendo en mi equipo, en claro, todos los ficheros y carpetas, bajo una carpeta base (que se identifica como “vault”). La aplicación (y sus muchos plug-in gratuitos) serían la “vista” y proporcionan todo tipo de features extra (búsquedas, etiquetas, tablas, tareas, calendario, hasta publicación web por ejemplo para crear un blog…), pero lo hacen sin contaminar las notas, por encima de ellas. Sobre la parte específica de publicación quizá escriba en el futuro, porque es de hecho lo que estoy utilizando para escribir y publicar este post, de forma 100% gratuita.

¿La desventaja principal? Obsidian es gratuito pero no software libre. Hay una empresa detrás que lo mantiene, y monetiza con un servicio propio de sincronización entre dispositivos. Si lo fuera, sería 10 de 10. Aún así, parece que hay bastante comunidad activa alrededor y me parece que le quedan muchos años por delante. Lo que es seguro es que si algún día migro a otra cosa, mis notas serán muchísimo más fáciles de portar.

Plugins
Hay un montón de Community plugins, pero los imprescindibles para mí son (la mayoría tienen nombres auto-explicativos):

Advanced Tables (by Tony Grosinger)
Automatic Table of Contents (by Johan Satgé)
Calendar (by Liam Cain)
Dataview (by Michael Brenan). Una pequeña joya para generar listas y tablas de forma flexible y automáticamente a partir de otras notas, mediante una sintaxis parecida a un mini-sql
Excalidraw (by Zsolt Viczian). Para todo tipo de diagramas, aunque si te gusta más el formato Mermaid es aceptado tal cual por Obsidian
Importer. Lo usé para migrar de Notion a Obsidian y me funcionó de maravilla.

Sincronización / dispositivos
Esto también me gusta, porque hay varias opciones. Hay una opción de pago del propio Obsidian, para móviles, tablets… pero no la he probado. En mi caso particular estoy utilizando la sincronización que ya pagaba por otro lado de iCloud (así que me ahorro el pago a Notion); a veces es un poco lenta... pero me arreglo. Se que también hay opciones para usar Google Drive, e incluso git.

Sistema de notas: “cerebro digital”

Lo quieras o no, si escribes mucho acabarás necesitando algún tipo de sistema. En mi opinión no hace falta hacerse un máster, montar catedrales, ni tampoco aplicar a ciegas algo que un tipo de USA te dice que es lo mejor. Lo mejor es ir poco a poco y crear algo que te funcione a ti. Ahora bien, leer un poco al respecto no te hará mal, no eres la primera persona en el mundo organizando notas digitales y hay mucha gente lista por ahí.

En mi caso particular, leí un libro que recomiendo bastante. Se trata de “Aprende a tomar notas con tu Cerebro Digital: Leer es perder el tiempo si luego no puedes recuperar esa información” de Marcos Emowe. Título un poco largo, pero libro bastante claro y con buenas ideas.

Estas son algunas:

No guardés lo que no vayas a usar (como en bases de datos 😄). Parece obvio, pero luego no lo es tanto.
Lo que sirve es lo que haces con las notas, no las notas (el conocimiento y la acción). Para los que se detienen más en afilar el hacha que en cortar.
El sistema de notas es distinto a la herramienta (no los mezcles!). Mantente lo más autónomo posible y en control de tu información.
Dale más peso a las conexiones entre notas (modelo “cerebro”). Esto complementará a los modos que seguramente ya te sean más naturales a la hora de tomar notas: modelo ”biblioteca” (títulos, jerarquía, tipo apuntes-libro…) y modelo ”rejilla” (tablas, datos numéricos…).
Procura hacer notas modulares. Hay varias referencias interesantes al sistema llamado Zettlekasten. Por cierto, este es otro principio que aplica al diseño de software, por eso me gusta :).
Tipos de notas
Como tomar notas y mejorarlas.

Algunas quizá te pueden parecer obvias, otras seguramente son nuevas… pero si te planteas un cambio en tu sistema / herramienta te lo recomiendo.

Working effectively with legacy code

2018-01-29T00:00:00Z

Hace poco he terminado de leer Working effectively with legacy code, de Michael Feathers, un libro clásico de programación y, como me ha gustado mucho, me he decidido a compartir unas notas sobre él, por si a alguien le pica el gusanillo de leerlo. Forma parte de la colección "Robert C. Martin Series", en el que existen otros libros muy interesantes.

Es un libro muy práctico, especialmente si programas con orientación a objetos, pero su título quizá es poco afortunado. En realidad, se trata de un libro que habla sobre todo de Tests y Refactoring, y de cómo usar ambas técnicas para trabajar con Legacy Code ("código legado"), algo que muchos programadores tratan de evitar siempre que pueden.

El libro está organizado en tres bloques:

Las mecánicas del cambio: en el que presenta unos conceptos generales y herramientas de trabajo.
Cambiando el software: un "catálogo de recetas" ante problemas concretos
Técnicas para romper dependencias

Las mecánica del cambio

El libro comienza hablando de las causas principales que motivan los cambios en un software: añadir una funcionalidad, corregir un error, mejorar el diseño u optimizar el uso de un recurso.

De aquí me quedo con una reflexión que hace el autor, que me parece muy valiosa, y es que da igual la causa final, probablemente el mayor reto para el programador será mantener el comportamiento existente, algo que ilustra con esta imagen

Sobre la forma en la que habitualmente hacemos los cambios, el autor critica lo que ya conocemos: muchas veces se usa el arriesgado "Edit and Pray" (editar el código y rezar porque nuestro esfuerzo sea acertado), cuando lo más adecuado sería aplicar "Cover and Modify", es decir cubrir primero el código con tests y, solo después, comenzar a modificarlo.

Los test cumplen aquí una doble misión: actuar como red de seguridad y proporcionar un feedback rápido sobre nuestro conocimiento del sistema, el cual crecerá con ellos.

De hecho, la definición de "Legacy Code" por parte del autor es "un código Legacy es aquel que no tiene tests" (y por tanto es difícil de modificar), algo que si nos paramos a pensar tiene todo el sentido del mundo. Tener buenos tests en un proyecto es una señal de su salud, pero la realidad es que muchas veces no existen y que añadirlos no es fácil. Entonces ¿cómo comenzar a trabajar con un código sin tests e incorporarlos?

El libro sugiere seguir estos pasos:

1. Identificar los puntos de cambio: busquemos primero donde debemos cambiar el código para cumplir nuestros objetivos.
2. Encontrar puntos donde crear tests: hay que valorar los más adecuados para probar los cambios en marcha (no podemos empezar probando todo indiscriminadamente).
3. Romper las dependencias: éstas suelen ser el principal obstáculo para crear los tests. Para eliminarlas, los objetos de tipo fake / mock pueden sernos muy útiles. Nos servirán no solo para separar las clases que queremos probar sino también para sentir a través de ellos que el comportamiento del objeto bajo test es el adecuado.
4. Escribir los tests: si se trata de cubrir primero código existente, con un comportamiento no evidente, podemos crear tests de caracterizacion, que simplemente describen lo que hace actualmente ante unos inputs y nos permitirán detectar si cambiamos involuntariamente su comportamiento más adelante. Otro concepto interesante para los tests es el de "costura" o s__eam: un lugar en el que se puede "modificar" el comportamiento de un método sin tocar su código. Por ejemplo si el método recibe como parámetro un objeto e invoca un método suyo, podríamos en un test pasar una instancia de ese objeto en el que el método haya sido reescrito, a conveniencia del test.
5. Hacer cambios y refactorizar, apoyados en herramientas de refactoring automático.

Cambiando el software

Este bloque del texto sigue un modelo de "recetas", planteando consejos y técnicas de refactoring a una lista extensa de problemas. Por citar algunos de los ejemplos:

¿Cómo añado una funcionalidad?
Necesito hacer un cambio, pero no se qué tests escribir
Mi aplicación es todo llamadas a un API
¿Cómo sé que no estoy rompiendo nada?
...

Técnicas para romper dependencias

Presenta varias técnicas de forma detallada y con código de ejemplo, algunas adaptadas del libro Refactoring, de Martin Fowler. Técnicas que, una vez aplicadas, rompen dependencias y favorecen la creación de tests.

Algunas de ellas son por ejemplo:

Extraer interfaz: si una clase existente es conflictiva para un test, podemos derivar de ella un interfaz y acoger selectivamente algunos de sus métodos. De esta forma, luego podremos sustituirla por otra clase que implemente ese mismo interfaz, pero que incluya las modificaciones del comportamiento que nos interesen.
Parametrizar un constructor: si una dependencia se crea dentro de un constructor, una solución sencilla es exponer ese objeto como parámetro. Esta misma técnica puede generalizarse también a métodos comunes.
Crear una subclase y sobreescribir un método: es una técnica potente, basada en usar herencia dentro de un test, para anular o modificar con una subclase la porción de comportamiento que nos interese. Personalmente me parece una técnica muy útil y que no conocía.

—-

En resumen, creo que el libro merece la pena por el mensaje que trasmite: Legacy no es "un código que otro ha hecho mal hace mucho tiempo", puede ser un módulo que acabamos de escribir nosotros mismos sin crear unos tests asociados. Y es valioso también por el catálogo de recetas del segundo bloque, algo a lo que personalmente seguro que volveré buscando consejo en el futuro.

Si te enfrentas a actualizar un sistema antiguo, sin duda éste es un libro muy útil para ti.

Saludos

Jornadas SIG Libre Girona

2017-06-05T00:00:00Z

La semana pasada tuve la suerte de poder acudir de nuevo a las Jornadas de SIG Libre de Girona, en su edición nº 11, esta vez presentando un desarrollo técnico, mi plugin para Leaflet, llamado Leaftlet.CanvasLayer.Field, para pintar rasters y campos vectoriales.

Your browser does not support the video tag.

Aquí está el programa completo de las Jornada, como referencia: http://www.sigte.udg.edu/jornadassiglibre/programa/ (colgarán más adelante los vídeos de las ponencias). Estaba revisando mis notas, para hacer balance y compartirlo con mis compañeros, pero he pensado que quizá sería más interesante hacerlo públicamente, así que aquí están.

Ponencias plenarias

Tras la apertura oficial por parte de la Universidad, comenzaron las Jornadas con la presencia de Rosa M. Badia (Barcelona Supercomputing Center - BSC). Dejando de lado las cifras brutales de cálculo previstas para el Mare Nostrum 4, lo que me llamó la atención fue la importancia que le prestaba no al hardware, sino a los modelos de programación y cómo indicaba la mezcla progresiva, en enfoques y herramientas, entre Supercomputación y BigData. Aunque no hubo referencia alguna a temas geoespaciales, Rosa citó PyCOMPSs un framework libre en Python para favorecer el desarrollo de modelos en paralelo en estos entornos, el cual parece interesante.

A continuación Lluís Sanz (Instituto Municipal de Informática del Ayuntamiento de Barcelona) hizo un repaso general de la estrategia Barcelona Ciudad Digital. En el ámbito SIG, ya en la parte final, comentó que están en un proceso de migración de bases de datos y herramientas diversas a QGIS, en un proyecto que se llama QVista y que será liberado este año, lo cual es una gran noticia. Si esto se cumple, podríamos disponer de un código aplicable también a otros ayuntamientos.

Terminó el bloque de plenarias David Comas, de Nexus Geographics, todo un referente en los SIG. Con una visión muy clara, lanzó algunas ideas-clave: (1) lo generalista en los SIG ya está solucionado, hay que especializarse y (2) los SIG, con interfaces de alto valor, deben responder preguntas concretas y sencillas y así brindar tiempo al usuario experto para resolver él los temas complejos.

Comunicaciones

Frederic Bartumeus (CREAF) presentó Mosquito Alert, una plataforma de ciencia ciudadana para la lucha contra el mosquito tigre y las enfermedades que transmite. Muy interesante caso de cómo ligar ciudadanos, científicos y gestores públicos gracias a una aplicación de base geoespacial. Creo que en el futuro se desarrollarán muchas más iniciativas de este tipo y ojalá que parte de su código sea reutilizable para ello (github)
Tras él, María Arias de Reyna habló sobre las pocas mujeres, y en general poca diversidad, que existe en el ámbito tecnológico y cómo esto supone una clara pérdida de riqueza y variedad de enfoques. Presentó como luchar contra esta situación gracias a iniciativas como @pingmujeres y llamó la atención sobre los aspectos educativos, señalando la necesidad de despertar más vocaciones STEM en niñas y adolescentes.
Ramiro Aznar (Carto), mostró después 3 casos tipo en los que la representación con mapas es habitualmente difícil y los resultados obtenidos generalmente malos, junto con propuestas para mejorarlas: * muchos puntos, de distintas categorías, generando "empaste" por estar próximos y/o superpuestos. Cuando esto sucede, aconseja reducir las categorías y jugar con la ordenación visual (categorías menos abundantes arriba) y la transparencia (los registros más escasos, arriba, más transparentes). * puntos en el mismo lugar. Para hacer visible lo oculto se pueden usar varias alternativas, como mapas de calor, clusters, stacking chips o agregación de puntos. * muchos campos para un solo registro. Aquí es conveniente pensar no en un mapa estático, sino en visualizaciones interactivas, en las que con controles como los de Builder se pueda aplicar de forma rápida y sencilla filtrado y estilos dinámicos. La verdad es que en esto Carto brilla especialmente.
Santiago Higuera presentó después el estado de OpenStreetMap España y cómo el proyecto sigue con impulso, con unos 100-110 usuarios activos al día y aprox. 30.000 nodos/día modificados en España.

Tras la pausa para la comida, continuaron las sesiones. A partir de aquí había doble 'track' así que sólo recogeré el bloque al que acudí (llamado "Investigación"):

Víctor Olaya (Boundless) presentó algunos consejos interesantes para los profesionales del SIG, tanto desarrolladores como usuarios / analistas. Básicamente, se centraban en la construcción por parte de cada uno de un "portfolio" público, perdiendo el miedo a la vergüenza, en el que se demuestren las capacidades e intereses, sea a través de foros, listas de correo, blogs o repositorios github.
Iván Sánchez mostró después las posibilidades que se abren al aplicar WebGL a mapas teselados en Leaflet. Un trabajo innovador y que muestra una gran velocidad de pintado pixel a pixel, abriendo la puerta a visualizaciones y análisis raster en el navegador. Creo que el futuro del pintado de mapas en web pasa claramente por trabajos con WebGL como este.
Eduard Suñé (IDESCAT) explicó con detalle cómo crear grids de población útiles, mediante quadtrees, a la vez que se protege el necesario secreto estadístico. Un ámbito que profesionalmente no conozco, pero que me hizo reflexionar sobre el esfuerzo necesario para encontrar un equilibrio entre dato geográfico de máxima calidad y el derecho a la privacidad de las personas.
Santiago Higuera dió luego un repaso a las opciones de referenciación lineal, ejemplificando en la red de carreteras españolas; se repasaron algunos aspectos de la ISO19148 y las opciones presentes en SIG de escritorio libres y PostGIS.
Jose Gómez Castaño (INSPIDE), autor de la app Comobity, describió la arquitectura de su plataforma Singularity para la DGT, donde tecnologías de Big Data como Spark, Hadoop, Flume o Kafka sirven para explotar datos en tiempo real y contribuir a una mayor seguridad en las vías públicas. Creo que ésta es una línea muy clara de futuro del sector geo: aplicaciones geográficas en un mercado vertical muy claro, con grandes volúmenes de datos y productos geográficos (no solo mapas) en tiempo real.
César Díaz (Tracasa Instrumental) mostró por su parte cómo utilizan unas tecnologías SIG muy contrastadas para crear mapas temáticos, en el Ayuntamiento de Pamplona (OpenLayers + Geoserver + PostGIS, con vistas parametrizadas, WMS & SLD); sin duda un 'stack clásico', pero muy efectivo.

Por la tarde, continué en las charlas del track "Desarrollos técnicos":

Roger Veciana (Meteocat), presentó algo novedoso: cómo aplicar D3js como herramienta de render de datos raster meteorológicos, permitiendo eliminar el proceso de generación automática de tiles en el servidor cada día. Con esto el cliente web gana en flexibilidad y capacidad de cambiar estilos al vuelo. Una desarrollo muy interesante, como lo es blog de su autor geoexamples.
Después de Roger, nosotros presentamos el trabajo que hemos hecho en el IHCantabria: Leaflet.CanvasLayer.Field, un plugin para crear animaciones de viento / corrientes y que también renderiza raster, esta vez sobre Leaflet.
Aquí la presentación completa.

Y tras nosotros, el mismo Roger, esta vez a título personal, presentó una extensión llamada d3-composite-projections, la cual permite visualizar áreas disjuntas en un solo mapa (p.ej. Canarias 'cerca' de la Península). Muy práctica, p.ej. para mapas electorales.
Ernesto Martínez (Carto) dió por su parte un repaso a las novedades de esta plataforma en 2017, siendo la principal la migración a Builder para todos los usuarios free. Otro aspecto que personalmente me llamó la atención fue la creciente importancia de los datos pre-cargados en la plataforma para enriquecer los análisis (Data Observatory).
Josep Lluís Sala (Giswater Association) contó el estado de la aplicación y de la red de asociados a este proyecto. Es un mercado en el que parece que la solución, basada en QGIS, PostGIS y modelos hidráulicos libres, parece estar convirtiéndose en estándar, lo cual es una gran noticia.
Ivan Sánchez presentó después una llamativa charla, llamada "Índices Miriahédricos Fractales Cuaternarios Para Fenómenos Geográficos", que escondía un curioso uso de palabras como índices geográficos (básicamente un what3words, pero con tacos).
Y finalmente María Arias de Reyna mostró el estado de GeoNetwork, un CMS 'geográfico' con mucha solera para trabajar con metadatados, al que claramente le han dado un buen empujón en lo visual.

Talleres

Además de las comunicaciones, tuve la oportunidad de acudir a dos talleres:

El primero sobre Docker, impartido por Joana Simoes y Jorge de Jesús. Docker parece una herramienta muy interesante para facilitar la gestión de servicios en producción, no solo para gente "de sistemas", sino también para desarrolladores. Me gustó la iniciativa que presentaron, geocontainers, con algunos servicios SIG empaquetados y preparados para usar, y una herramienta visual para el control de contenedores llamada portainer.
El segundo taller, sobre desarrollo de plugins para QGIS, fue impartido por Luigi Pirelli. Estuvo centrado en las herramientas necesarias para iniciar este camino: la consola básica, IPyConsole, Plugin Builder, Remote Debug y Plugin Reloader. Existen documentos que ayudan en el cambio de la v2 a la v3, para ayudar en el proceso de migración de plugins. Como consejo interesante: está previsto liberar QGIS 3 para finales de 2017 y parece bueno dejar aún madurar un poco las APIs.

Resumen

A modo de resumen, diría que tengo la sensación que el mercado SIG Libre, y con él las Jornadas, ha madurado, con empresas, tecnologías y usuarios consolidados. Quizá eché en falta alguna presentación más sobre JavaScript o nuevas tendencias como BigData, drones... pero creo que los contenidos en general han sido buenos, la organización y el ambiente inmejorables, y espero poder repetir el próximo año.

¡Saludos!

Brackets un editor ágil para desarrollo web

2017-02-28T00:00:00Z

En los últimos años ha habido una explosión de editores de texto, especialmente en el ámbito del desarrollo con JavaScript: Sublime, Atom, Code o el propio Brackets.

Todos excepto Sublime son software libre y gratuito y tienen un enfoque similar: editores rápidos y con menos funciones "de serie" (comparados con grandes IDE tradicionales, como p.ej. Eclipse, Visual Studio...). Estos editores poseen además un ecosistema de plugins y temas muy amplio, para que cada uno personalice a su gusto sus funciones y apariencia.

Después de usarlo en varios proyectos, Brackets me parece una opción interesante, así que comparto aquí la lista de plugins que utilizo actualmente por si os resulta útil:

Brackets-Git: manejo de git
Beautify: formateo automático de HTML, JS y CSS
Indent Guides: como guía visual para seguir la apertura-cierre de secciones
Minimap: guía del documento en pequeño, para desplazarse por él
Newline: para controlar el uso de CRLF <-> LF como fin de línea (windows / linux)
WordCount: nº de palabras
Brackets Css Color Preview: mostrar el color escrito en un CSS
EMMET: agilizar la escritura de HTML
Markdown Preview: para visualizar ficheros .md
Brackets Tree Icons: para otorgar un icono a cada fichero según su tipo
Brackets File Tabs: para complementar el árbol lateral con pestañas

Visor de terremotos del USGS con OpenLayers

2016-01-20T00:00:00Z

En este post se presenta un pequeño ejemplo de visor, en el que se muestran los terremotos más recientes en el mundo, usando la biblioteca OpenLayers 3.

Los terremotos se leen de un origen remoto, en formato Geojson, y se actualizan automáticamente, gracias a un estupendo servicio feed del USGS

El visor puede verse funcionando, gracias a bl.ocks.org aquí: http://bl.ocks.org/VictorVelarde/raw/5021e3679dad1305d570/
Y en cuanto al codigo HTML y JavaScript, es sencillo y puede verse en este gist: https://gist.github.com/VictorVelarde/5021e3679dad1305d570

<!DOCTYPE html>
<html>

<head>
    <meta charset="UTF-8">
    <title>Ejemplo sencillo con OL3</title>
    <link href="http://fonts.googleapis.com/css?family=Open+Sans|Dosis:400,800" rel="stylesheet" type="text/css" />

    <!-- Versión específica vs. master | min vs. debug -->
    <link rel="stylesheet" href="http://openlayers.org/en/v3.12.1/css/ol.css" type="text/css">
    <script src="http://openlayers.org/en/v3.12.1/build/ol-debug.js"></script>

    <style>
        /* General */
        
        h1 {
            font-family: 'Dosis', sans-serif;
            font-weight: 400;
            font-size: 40px;
            line-height: 46px;
            margin-bottom: 10px;
            color: #E50275;
        }
        
        body {
            font-family: 'Open Sans', sans-serif;
            background-color: #F7FBFF;
        }
        
        .ficha {
            color: #03A1C4;
        }
    </style>
</head>

<body>
    <h1>Mapa de terremotos significativos el último mes (USGS)</h1>

    <div id="mapa" style="height: 400px; border: 2px gray solid;"></div>
    <div id="seleccion" style="margin-top:10px"></div>

    <!-- JavaScript -->
    <script>
        var mapa = new ol.Map({
            layers: [new ol.layer.Tile({
                source: new ol.source.OSM()
            })],
            target: 'mapa',
            view: new ol.View({
                center: [0, 0],
                zoom: 2
            })
        });

        mapa.addControl(new ol.control.OverviewMap());

        // carga de datos
        var urlTerremotos = 'http://earthquake.usgs.gov/earthquakes/feed/v1.0/summary/significant_month.geojson';
        var capaTerremotos = new ol.layer.Vector({
            source: new ol.source.Vector({
                url: urlTerremotos,
                format: new ol.format.GeoJSON()
            })
        });
        mapa.addLayer(capaTerremotos);

        // interacción capa vectorial
        var seleccion = new ol.interaction.Select();
        mapa.addInteraction(seleccion);
        seleccion.on('select', function (e) {
            // ol.interaction.SelectEvent
            var div = document.getElementById('seleccion');
            var seleccionados = e.target.getFeatures();
            var html = '';
            seleccionados.forEach(function (t) {
                html += '<div class="ficha"><ul>';
                html += '<li><strong>Lugar</strong>: ' + t.get('place') + '</li>';
                html += '<li><strong>Magnitud</strong>: ' + t.get('mag') + '</li>';
                html += '<li><strong>Fecha</strong>: ' + new Date(t.get('time')).toLocaleDateString() + '</li>';
                html += '</ul></div>';
            });
            div.innerHTML = html;
        });
    </script>

</body>
</html>

Sobre gist & bl.ocks: * gist. Se trata de un servicio gratuito de github, para alojar pequeños codigos de ejemplo, que se persisten sobre un repositorio git. Gracias a ello son accesibles para su modificación desde cualquier equipo con un cliente git. * bl.ocks.org. Un servicio, del creador de D3, que siguiendo unos pocos convenios en el gist, permite el acceso a su código en vivo, junto a su fuente, permitiendo mini-proyectos autodocumentados.

Nota: Este ejemplo se presenta en el último video de la serie de seminarios sobre JavaScript, elaborada para geospatialtraining.com (ver Videos de introducción a JavaScript)

Video explicativo

6 videos de Introducción a JavaScript

2016-01-12T00:00:00Z

Hola a todos,

En esta entrada os presento los 6 vídeos gratuitos de un curso introductorio a JavaScript, realizado en colaboración con http://geospatialtraininges.com/

Los vídeos no asumen conocimientos previos en la materia y están orientados a personas del mundo SIG que quieren iniciarse en la programación web.

Espero que os sean útiles.

Saludos!

Módulo I: Variables y datos (41 min) https://www.youtube.com/watch?v=\_qFvPJHGuCw&feature=youtu.be
Módulo II: Funciones y Bucles (1h) https://www.youtube.com/watch?v=UEQpIkrQv78&feature=youtu.be
Módulo III: Arrays y objetos (1h 12min) https://www.youtube.com/watch?v=1kVJDyx5FK8&feature=youtu.be
Módulo IV: DOM (1h 3min) https://www.youtube.com/watch?v=UQXEmqSOQK8&feature=youtu.be
Módulo V: Bibliotecas y frameworks (43 min) https://www.youtube.com/watch?v=TW7lr0QDNd0&feature=youtu.be
Módulo VI: APIs SIG de JavaScript (1h 23min) https://www.youtube.com/watch?v=23X7GqLi5oQ&feature=youtu.be

Recursos para aprender QGIS

2015-02-24T00:00:00Z

QGIS es uno los software SIG de escritorio más pujantes en la actualidad. Libre, gratuito y extensible mediante plugins, tiene un potencial de evolución grande y una comunidad de usuarios creciente.

Por esta razón cada día más gente se acerca a su aprendizaje, bien mediante cursos o de forma autónoma. Y en este proceso inicial toda guía o recopilación de enlaces suele resultar útil, así que voy a listar aquí algunos que he ido recopilando recientemente.

Enlaces básicos

Página QGIS: El sitio oficial, con multitud de recursos y enlaces derivados.
QGIS Planet: Un agregador de varios blogs que recoge unificadamente artículos técnicos sobre QGIS (como p.ej. los publicados en Free and Open Source GIS Ramblings, de Anita Graser)
QGIS Plugins: Listado oficial de plugins
QGIS Hub: Wiki oficial del proyecto, donde p.ej. se reportan los bugs y recogen peticiones para futuras funcionalidades.
QGIS API: Documentación del API oficial, un recurso básico para programadores.
QGIS en stackexchange: Artículo en stackexchange donde se listan varios recursos.
QGIS en gis.stackexchange: Consultas sobre QGIS en gis.stackexchange

Tutoriales gratuitos

QGIS Training Manual: Manual de aprendizaje de QGIS, en formato de curso con ejercicios prácticos (incluye p.ej. apartados sobre uso de la base de datos espacial PostgreSQL/PostGIS o GRASS). Como complemento a este material existe un conjunto de videos en español, que aparece listado en la siguiente wiki
A gentle introduction to GIS: Una introducción práctica y breve a los SIG que no asume conocimientos previos. Está basada en el tutorial original Introducing GIS worksheets
QGIS in under 10 minutes: Videotutoriales cortos con operaciones habituales en QGIS (serie de 17 vídeos, en inglés)
Curso de QGIS Valmiera: Videotutoriales QGIS, versión 2.2 (serie de 10 vídeos, en castellano).
GST 101: Introduction to Geospatial Technology. Curso de introducción a SIG, usando QGIS 2.2
GST 102: Introduction to Geospatial Technology. Continuación del curso previo, más centrado en la parte de análisis espacial con QGIS.

Saludos y espero que resulten útiles.

Cómo utilizar datos geográficos públicos de la NASA (SRTM) con un software libre como QGIS

2015-01-23T00:00:00Z

Si en una entrada previa mostrábamos algunos ejemplos de uso de datos vectoriales libres, procedentes de OpenStreetMap, en este caso vamos a revisar una valiosa fuente de datos cuasi-mundial con la altitud del terreno denominada Shuttle Radar Topography Mission (SRTM).

Dentro del mundo SIG, a estas fuentes de datos se las denomina Modelos Digitales del Terreno (MDT) y recogen, generalmente en forma de fichero, una estructura numérica de datos que representa la distribución espacial de una variable, sea en forma vectorial (contornos o TIN) o más frecuentemente raster (matrices regulares o quadtrees). Si esta variable es la altitud, entonces hablamos de Modelos Digitales de Elevaciones (MDE).

Para profundizar en las bases conceptuales de los MDT, recomiendo los estupendos materiales de A.M. Felicísimo en http://www6.uniovi.es/~feli/CursoMDT/

La SRTM que nos ocupa es una misión comandada por la NASA desarrollada en el año 2000, que mediante su transbordador espacial Endeavour y un radar aerotransportado tomó datos en detalle sobre la elevación terrestre, entre los 60º de latitud norte y los 56º de latitud sur (más detalles técnicos de la misión en la página oficial SRTM). Si bien algunos de sus datos son públicos desde hace varios años, desde septiembre de 2014 han comenzado a liberarse por primera vez los lotes más detallados, con la resolución original de aproximadamente 30 metros (1 arco-segundo), antes solo disponibles en USA.

En esta entrada veremos algunas posibilidades del uso combinado de un software SIG libre como QGIS y los datos de esta fuente.

¿Cómo empezar a trabajar con QGIS y SRTM?

Asumiendo que ya tenemos QGIS correctamente instalado (instrucciones aquí), procederemos primero a la descarga de datos SRTM Basic.

Para la descarga usaremos una herramienta interactiva proporcionada por el USGS (Servicio Geológico de Estados Unidos) llamada EarthExplorer (http://earthexplorer.usgs.gov/). Desde ella se puede descargar no solo la SRTM, sino una gran variedad de fuentes. Antes deberemos registrarnos como usuarios aquí (un proceso gratuito, aunque nos llevará un par de minutos).

Luego seguiremos los sencillos pasos marcados por el asistente:

1. Enter Search Criteria: en nuestro caso navegaremos en el mapa hasta encuadrar el ámbito de la Bahía de Santander, en Cantabria.

Fig.1: Selección del ámbito de interés en EarthExplorer\

2. Select Your Data Set(s), donde indicaremos la palabra clave 'SRTM' para filtrar los datos y poder llegar al producto 'SRTM 1 Arc-Second Global'

Fig.2: Filtro de dataset SRTM

Al pulsar en la búsqueda aparecerán las hojas disponibles en el apartado 4. Search Results. En nuestro caso son dos hojas y procederemos a la descarga de la identificada como SRTM1N43W004V3, en formato GeoTIFF.

Fig.3: Descarga de hoja SRTM 1 Arc-Second Global

El fichero descargado n43_w004_1arc_v3.tif podremos ya cargarlo en QGIS.

Para ello bastará con utilizar la opción del menú Capa - Añadir capa raster y se visualizará con la escala de colores por defecto, en tonos grises. Podremos también consultar la altitud del terreno registrada en cada punto, haciendo clic con la herramienta Identificar.

Fig.4: MDE de SRTM en QGIS, con paleta gris unibanda

Una vez cargados los datos, podemos comenzar a explotarlos utilizando distintas herramientas de QGIS. A continuación mostraremos brevemente 3 ejemplos.

Ejemplo 1. Usar SRTM como mapa base

El MDE de la SRTM constituye una gran base para la visualización topográfica, y puede servir como mapa de fondo sobre el que representar después nuestra información geográfica particular (p.ej. una ruta tomada con el GPS). Una forma rápida de dar un estilo mejorado a la capa raster, es mediante Raster - Análisis del terreno - Relieve, que genera una capa con visualización de sombreado y tintas hipsométricas simultáneas.

Fig.5: MDE SRTM sombreado en QGIS

Ejemplo 2. Usar SRTM para una visualización 3D

QGIS dispone de un plugin muy interesante para la visualización en 3D de un MDE en un simple navegador web. El plugin se llama Qgis2threejs, que utiliza internamente la librería de JavaScript threejs. Con multitud de opciones para explorar, es una herramienta de visualización / publicación web de resultados muy interesante.

Fig.6: MDE SRTM en vista 3D con Qgis2threejs

Ejemplo 3. Usar SRTM para un análisis de ubicación óptima

El hecho de conocer la altitud en cada celda (cada 30 metros), unido a las capacidades analíticas de QGIS para datos raster, permite usar SRTM en potentes análisis geográficos. Por ejemplo, es posible modelizar el flujo del agua y estudiar cómo se configuran las cuencas hidrográficas o calcular las horas potenciales de insolación anuales en un punto...

En el siguiente vídeo mostraremos otro ejemplo aplicado a un problema SIG clásico: la búsqueda de la mejor ubicación, apoyados en la calculadora raster de QGIS:
http://vimeo.com/112688478

Esta entrada es una colaboración en el blog iNFoRMáTICa++, perteneciente a los Estudios de Informática, Multimedia y Telecomunicación (EIMT) de la Universitat Oberta de Catalunya (UOC). Publicada originalmente en: http://informatica.blogs.uoc.edu/2015/01/15/como-utilizar-datos-geograficos-publicos-de-la-nasa-srtm-con-un-software-libre-como-qgis/

3 lenguajes de programación para SIG

2015-01-07T00:00:00Z

A lo largo de los años dentro del mundo SIG es habitual, para un analista o usuario avanzado, encontrarse en la posición de tener que decidir: ¿en qué tecnología/s formarme? O dicho de otra forma ¿a qué dedico mi valioso (y probablemente escaso) tiempo-presupuesto? ¿aprendo a manejar un nuevo SIG de escritorio, a gestionar un servidor SIG... o a qué?

Esta primera pregunta hoy día tiene una sólida y clara respuesta: primero aprende a programar (y si ya sabes, aprende a programar mejor). Tomando las palabras de James Fee (al que recomiendo seguir en su blog): "GIS analysis has become programming and development", así que la cuestión es más bien... ¿en qué lenguaje/s de programación invierto?

Aunque la lista de lenguajes candidatos es potencialmente extensa, para obtener el máximo retorno del esfuerzo lo más adecuado hoy día es centrare en SQL, Python y JavaScript.

¿Por qué estos lenguajes y no otros?

Structured Query Language (SQL)

SQL (1974): lleva cuarenta años con nosotros y sigue vigente. Aunque estrictamente no es un lenguaje de programación, sino un 'lenguaje de consultas estructurado', lo importante es que todo SIG lleva un motor de consultas interno que permite, en mayor o menor medida, aplicar SQL. Si sabes bien los fundamentos, te será mucho más fácil aplicar luego los operadores espaciales disponibles para enriquecerlo con la componente "geo". Acabarás teniendo un SHP, una plataforma en la nube como CartoDB, un PostGIS o un miserable Access, pero lo que es seguro es que si trabajas con SIG tendrás que manejar con soltura SQL.

Python

Python (1991): el lenguaje para muchos más adecuado para iniciarse en la programación, con librerías que facilitan el trabajo en prácticamente todo tipo de ámbitos (interfaces, multimedia, bioinformática...). En el mundo SIG la decisión ya está tomada hace un tiempo, desde el momento en que potentes librerías como GDAL/OGR crearon sus envoltorios para Python y ESRI & QGIS lo adoptaron como lenguaje de geoprocesamiento. Python es hoy el lenguaje por excelencia para trabajar con SIG, especialmente a nivel de geoprocesamiento y en equipos de escritorio (otro tema es la construcción de soluciones web en servidor, donde el entorno Java con ejemplos como Geoserver-GeoTools aún sigue vigente).

JavaScript

JavaScript (1995): Tiene la capacidad de dotar de interacción a las páginas web e incorporar mapas y otras funciones SIG en ellas mediante bibliotecas (como OpenLayers, Leaflet, etc.), hasta conseguir aplicaciones SIG completas en el navegador web. Prácticamente toda la revolución de la "neogeografía", que tanto ha beneficiado a los SIG estos últimos años, ha venido de su mano (primero con GoogleMaps, y más recientemente con bibliotecas como las de CartoDB, Mapbox...). De hecho, ahora comienzan a aparecer librerías JavaScript como Turf para algo impensable hace unos años: realizar cálculos SIG en el navegador web (buffer, intersección, isolíneas...), sin tener que recurrir a un servidor dedicado de respaldo como ArcGIS Server o Geoserver.

JavaScript no "viaja solo": en la práctica hay que considerar un lote de 3 lenguajes, puesto que lleva aparejado lidiar con sus dos lenguajes 'hermanos': HTML y CSS, que lo apoyan para construir aplicaciones web.

Haz tu mix

Si cada uno de estos lenguajes ya es útil por si sólo, lo son más en combinación. Aprovechar las sinergias que surgen entre ellos permite explotar y construir sistemas SIG más potentes (p.ej. usar Python en ArcGIS o QGIS y realizar filtros SQL contra una base de datos PostGIS, usar JavaScript y realizar consultas SQL a través de un API contra una tabla remota en CartoDB, etc.).

Así que mi consejo es: 1. aprende los fundamentos básicos de los 3 lenguajes 2. dedica el tiempo a profundizar en ellos y en nuevas bibliotecas de funciones que los enriquezcan. 3. mejora durante el proceso tus habilidades generales de programación (algoritmos, diseño, herramientas y prácticas ágiles...).

Cómo utilizar datos geográficos públicos de OpenStreetMap con un software libre como QGIS

2014-12-18T00:00:00Z

Analizar datos espaciales y generar con ellos mapas atractivos para el usuario es la gran fortaleza de los Sistemas de Información Geográfica (SIG). Y si hace unos pocos años el software SIG y los datos de calidad estaban sólo al alcance de unos pocos (grandes corporaciones, militares, universidades...), hoy cualquier profesional bien formado tiene en su mano la posibilidad de usarlos de forma rápida y gratuita. En esta entrada veremos algunas posibilidades del uso combinado de un software SIG libre como QGIS y los datos, también libres, de OpenStreetMap.

¿Cómo empezar a trabajar con QGIS y OSM?

Instalando en nuestros equipos la última versión de QGIS Desktop dispondremos de un software SIG de escritorio completo, gratuito y extensible mediante plugins (instrucciones de instalación detalladas de la v2.6, para Linux, Windows y Mac, en http://www.qgis.org/es/site/forusers/download.html).

OpenStreetMap (OSM) no es sólo un mapa: es una base de datos mundial con más de 30 GB de datos geográficos vectoriales de información muy diversa y detallada (carreteras, caminos, edificios, restaurantes, parques naturales...). En las últimas versiones QGIS integra de forma nativa la opción de descarga de datos OSM, desde su menú Vectorial - OpenStreetMap (OSM) - Descargar Datos. Esto simplifica y agiliza la descarga de una porción de datos OSM, en forma de fichero vectorial .osm (XML).

En este ejemplo, utilizaremos datos de la ciudad de Santander, dentro del área geográfica definida manualmente por las siguientes coordenadas: xmin:-3.8313931 ymin: 43.4449263 | xmax:-3.7658341 ymax: 43.4784917

QGIS también permite descargar datos OSM dentro del encuadre de una capa preexistente o a partir del zoom actual por pantalla. En cualquier caso, es importante que el sistema de referencia sea WGS84 Longitud / Latitud (EPSG: 4326) o el proceso no funcionará correctamente. Esto es debido a que internamente el complemento hace uso del API Overpass, que recibe como parámetros las coordenadas del encuadre en este sistema.

Una vez descargados los datos OSM (en un fichero santander.osm, de aprox. 5 MB), se pueden cargar directamente en QGIS, mediante la opción de menú Capa - Añadir capa - Añadir capa vectorial (y luego seleccionando points / lines / multipolygons).

Fig.1: Datos OSM con los estilos por defecto en QGIS

Una vez obtenidos los datos podemos comenzar el proceso de explotación y análisis, utilizando distintas herramientas de QGIS. A continuación mostraremos brevemente 3 ejemplos ilustrativos:

Ejemplo 1. Usar OSM para generar un map

Es posible tomar los datos OSM y generar con QGIS un mapa 100% personalizado, seleccionando cada entidad a mostrar, su etiquetado, su estilo... hasta obtener un mapa base o mapa temático a nuestra medida.

QGIS proporciona un mecanismo para persistir reglas de visualización mediante ficheros de estilos reutilizables (.qml). Por ejemplo, existen algunos .qml públicos que permiten dar una apariencia 'googlemaps' a un lote de datos .OSM y si los aplicamos a nuestras capas OSM (menú de capa Propiedades - Cargar estilo) el resultado es un mapa base como el siguiente:

Fig.2: Mismos datos OSM, con los estilos osm_spatialite_googlemaps_.qml, tomados de https://github.com/anitagraser/QGIS-resources/tree/master/qgis2/osm\_spatialite\

Los .qml usados son ficheros para la versión 2.4 de QGIS y no se contemplan todos los tipos de objetos OSM, como p.ej. 'playas' (categoría natural:beach), con lo cual para un resultado óptimo deben trabajarse más los estilos.

Ejemplo 2. Usar OSM para un análisis de redes

OSM incluye un subconjunto especialmente relevante de datos que es la red viaria. OSM recoge el grafo conectado de autopistas, carreteras, caminos, calles... y permite por tanto aplicar los algoritmos propios del análisis de redes: camino más corto, estimación de tiempos para recorridos, etc.

Aunque existen herramientas más sofisticadas, QGIS proporciona una práctica utilidad para calcular la ruta más corta en una red, mediante su complemento Grafo de rutas.

Antes de usar el complemento hay que cargar la capa de líneas y luego configurar el plugin, mediante Vectorial - Configuración del complemento Grafos de rutas. En ese apartado de configuración se puede fijar p.ej. la velocidad media de los tramos. Para ver los datos de tiempo y velocidad correctamente, será necesario usar una proyección que utilice metros como unidad, así que aplicaremos antes una reproyección al vuelo (en este caso, a la zona le corresponde ETRS89-UTM30N: EPSG:25830).

Si fijamos una velocidad media de 50 km/h a toda la red, podemos calcular por ejemplo la distancia y tiempo estimado del camino más corto entre la estación de tren de RENFE y los Jardines de Piquío en el Sardinero.

Fig.3: Los datos de la red de transporte OSM utilizados para un cálculo de camino más corto

Ejemplo 3. Usar OSM para la búsqueda de vivienda

Los datos OSM pueden usarse también para análisis de otra índole, encadenando sobre ellos operaciones espaciales sucesivas (área de influencia, intersección, etc.). P.ej. para la búsqueda de la mejor ubicación para alquilar una vivienda, en base a una serie de requisitos previos tales como p.ej. la proximidad a una escuela, cercanía a vías de comunicación rápidas, etc.

En el siguiente vídeo puede verse un análisis vectorial sobre datos OSM en esta línea:
https://vimeo.com/112687753

Esta entrada es una colaboración en el blog iNFoRMáTICa++, perteneciente a los Estudios de Informática, Multimedia y Telecomunicación (EIMT) de la Universitat Oberta de Catalunya (UOC). Publicada originalmente en: http://informatica.blogs.uoc.edu/2014/12/15/como-utilizar-datos-geograficos-publicos-de-openstreetmap-con-un-software-libre-como-qgis/

Instalación de librerías NetCDF + Python en un sistema Windows

2013-06-25T00:00:00Z

La instalación adecuada de Python + NetCDF es algo muy extendido y documentado en sistemas Linux, pero no tanto en sistemas Windows. En esta entrada el objetivo es recoger los pasos necesarios para conseguirlo, a modo de referencia rápida con las instrucciones y enlaces oportunos.

NetCDF es un formato binario de fichero (.nc) orientado a arrays, que facilita el manejo de varias dimensiones (x, y, z, tiempo...) de forma eficiente y flexible. Por esta razón está muy extendido en la comunidad científica, por ejemplo para guardar datos del medio como temperaturas, corrientes, viento, salinidad, etc. obtenidos mediante sensores o modelado.

De forma indisoluble con el formato, existe un conjunto de librerías para NetCDF que facilitan el acceso a sus datos desde varios lenguajes (C, Fortran, Java, etc.) y que son la pasarela con la que trabaja el programador. Python es por su parte el lenguaje de scripting más potente y posee multitud de librerías para ampliar su campo de acción (para el manejo de datos SIG, cálculo intensivo, gráficos, etc.), por lo que juntos forman una buena combinación en el ámbito científico.

Los pasos para configurarlos de forma integrada en una plataforma Windows de 32 bits son:

(A) Python 2.7. Si aún no lo tenemos, la última versión disponible para la rama 2.x (la más extendida) es actualmente la 2.7.5, descargable aquí
(B) NetCDF4. Las librerías base están escritas en C y para usarlas es necesario descargarlas y compilarlas o, algo más práctico, obtener directamente los binarios. Siguiendo la segunda vía, aquí está el instalador con la última versión para netCDF4. Para una descripción más detallada del procedimiento con estos binarios, ver este enlace
(C) Acceso a las librerías NetCDF. Para un enlace posterior a las librerías, es necesario agregar al PATH los siguientes directorios, generados por el instalador: C:\Program Files\netCDF 4.3.0\bin y c:\Program Files\netCDF 4.3.0\deps\shared\bin
(D) Numpy. El acceso a los datos de los ficheros NetCDF se realizará de forma efectiva con esta librería para Python, especializada en el manejo de arrays. La última versión disponible hoy, la 1.7.1, para Python 2.7 está disponible aquí
(E) Interfaz de Python para netcdf4. Ésta es la librería Python que permite leer y escribir en los netcdf desde scripts .py, actuando de pasarela hacia las librerías base previamente configuradas (C). El instalador para la 2.X está en este enlace
(F) Validación. Finalmente, para probar que todo está correcto, ejecutaremos un pequeño script de Python, leyendo un netcdf cualquiera (fichero testNC.py). P.ej. estos datos de la NASA muestran las anomalías térmicas sobre la superficie terrestre y es posible descargarlos en formato netCDF desde aquí en un fichero "nmaps.nc". Como nota útil, señalar que para visualizar de forma rápida el netcdf se puede usar un visor como Panoply o un software SIG como gvSIG, que en su versión más reciente incluye soporte a este formato

testNC.py

# -*- coding: utf-8 -*-
import netCDF4 as nc
import numpy as np

'''
Prueba de acceso a netCDF en Python Win32.
Abre un fichero .nc y obtiene el valor mínimo de una variable conocida ('TEMPANOMALY')
'''

print('TEST netCDF en Python')

rutaFichero = "c:/users/admin/nmaps.nc"
fichero = nc.Dataset(rutaFichero)

print("* Variables disponibles en el fichero:")
for v in fichero.variables:
    print(v)

datos = fichero.variables["TEMPANOMALY"][0]
print("* Mayor anomalía de temperatura negativa: {0} K".format(min(datos)))

Nota: como los datos de la variable vienen en un array con "máscara" (para indicar dónde hay 'huecos' sin datos), es posible utilizar las clases de numpy específicas y hacer algo como:

minimo = np.ma.MaskedArray.min(fichero.variables["TEMPANOMALY"][:])
maximo = np.ma.MaskedArray.max(fichero.variables["TEMPANOMALY"][:])

Algunos otros ejemplos de uso de ficheros .nc en Python

Materiales curso OpenLayers e Ikimap - DGSIG 2013

2013-06-15T00:00:00Z

Materiales desarrollo app geográficas web

En este post incluyo los materiales completos de la asignatura "Desarrollo de aplicaciones geográficas web", que he estado impartiendo los últimos 3 años en el Curso de Experto en DGSIG de la Universidad de Cantabria. Son los utilizados en la última edición presencial del curso (enero de 2013) y tienen licencia Creative Commons. Creo que puede ser útil a personas que comienzan en este ámbito, como recurso para el aprendizaje autónomo.

Se trata de una versión mejorada respecto a la que ya se publicó aquí hace un tiempo, aportando una revisión general a los materiales de OpenLayers (versión 2.12), algunos nuevos contenidos sobre Ikimap y los ejercicios del curso. Se incluye:

0 - Guía de la asignatura .- descripción de los objetivos y materiales
1 - Materiales de apoyo.- contenidos teóricos básicos (neogeografía, programación web, plataformas de publicación y OpenLayers)
2 - Presentación en el aula.- soporte visual de los contenidos.
3 - Ejercicios.- carpeta con los enunciados y sus soluciones.

Los materiales se pueden descargar aquí: ![[dgsig_2013.zip]]

Formación OpenLayers

Me preguntan de forma esporádica por correo electrónico sobre formación en OpenLayers, generalmente por Internet. Al margen de la formación presencial, cursos en línea (en español) con contenidos de OpenLayers conozco en dos lugares (si alguien conoce más opciones, por favor que me lo diga y las incluyo):

Geospatialtraining-ES: http://geospatialtraininges.com/pagina-1/
UNIGIS: http://www.unigis.es/Oferta-Formativa/Cursos-Especializacion/Programacion-Aplicaciones-Web-Map-ce

También existen una serie de materiales en abierto en varios lugares, útiles para auto-formación. Por ejemplo:

Y por supuesto, en inglés existen bastantes más recursos.

Saludos!

Nuevas tendencias los SIG en la nube

2012-10-13T00:00:00Z

Hoy se dispone de un abanico amplio de opciones para publicar información geográfica en Internet. Generalmente cuando un profesional se plantea esta tarea suele considerar alguna de estas vías

Preparar un servidor propio con software privativo, como el de la empresa ESRI (ArcGIS Server), de calidad alta pero modelos de licencia accesibles para pocos.
Montarlo con software libre, que ha ganado mucho en madurez y cuyo uso sigue extendiéndose, con productos como Geoserver y OpenLayers.
No utilizar software SIG y delegar en servicios web de mapas externos y sus APIs para programadores (como el archiconocido GoogleMaps).
Configurar un entorno híbrido, con elementos combinados de las opciones previas.

En general, las dos primeras opciones funcionan bien en organizaciones con personal cualificado, capaz de crear y mantener entornos tecnológicos complejos y siempre que se haga una inversión decidida de recursos, lo cual no siempre es fácil (grandes empresas, administraciones... los clientes SIG tradicionales, vaya). La tercera vía es mucho más ágil y con menos barreras de entrada para pequeñas empresas, asociaciones, particulares... que cada vez lo usan más y para usos más variados (es lo que algunos llaman "neogeografía").

Sin embargo, hay más opciones a considerar... y es que en los últimos tiempos está emergiendo una tendencia denominada computación en la nube. Ésta implica la aparición de hardware, plataformas y servicios web mediante los que se externaliza a empresas especializadas parte de las labores informáticas de organizaciones e individuos. Y dentro de estas plataformas existen ya varias que permiten el almacenamiento y publicación de información geográfica.

Algunas de estas interesantes plataformas son: IkiMap, GeoCommons (recientemente adquirida por Esri), Google Fusion Tables o CartoDB. Se trata de espacios en la nube donde almacenar y publicar datos geográficos en forma de mapas, que además prestan especial atención a la facilidad de uso para el usuario, las redes sociales y el buen diseño. Además, son plataformas que generalmente incluyen un API para programadores, con lo que sus posibilidades de uso e integración con otras herramientas se amplían notablemente.

Sin duda se trata de plataformas potencialmente utilizables por un número muy alto y variado de individuos y organizaciones, especialmente en los casos en los que las "vías tradicionales" no sean aplicables. Por ejemplo, un medio de información local podría fácilmente ubicar en un mapa las noticias que suceden en su municipio (p.ej. obras en marcha o planificadas, actos culturales, animales perdidos...), incrustar ese mapa en su blog y permitir la participación de los ciudadanos y la difusión de sus mapas en redes sociales.

Por ejemplo, el siguiente mapa ha sido creado en la plataforma Ikimap, autodenominada la "red social de los mapas". Crear un mapa como este es una labor rápida y sencilla. En páginas webs y blogs que lo admitan, también se puede embeber un mapa interactivo, a partir del código para crear un iframe que proporciona la plataforma

Sin ninguna duda, en los proyectos de publicación de información geográfica, las plataformas SIG en la nube son una opción muy a tener en cuenta ...

Aplicaciones geográficas web móviles

2011-12-04T00:00:00Z

Este es un tema que considero de gran interés y futuro: el desarrollo de aplicaciones web teniendo en mente los nuevos dispositivos móviles, tales como smartphones y tablets (iphones, teléfonos android, ipads, etc.).

Presentación para Geoinquietos

Recientemente hablamos de este tema en geoinquietos Cantabria.

Esta fue la presentación que compartí con ellos:
Geoinquietos: La web movil está aquí...

Si no conoces la iniciativa geoinquietos, infórmate en osgeo y busca tu grupo más cercano.

Herramientas de desarrollo

Frente al desarrollo en entornos nativos (p.ej. con Java y eclipse para android), la programación web estándar (HTML, Javascript y CSS + un lenguaje de servidor como ASP o PHP) puede resultar una opción muy interesante.

Sobre la base de estas herramientas habituales de programación web están apareciendo varios complementos para el desarrollo móvil, sobre todo en forma de librerías javascript. De ellas, las dos que me parecen más reseñables son Sencha Touch [1] y jQuery Mobile.

Personalmente, dada la expansión de su hermana mayor jQuery, creo que la segunda es una opción que merece la pena probar.

Las capacidades de su API pueden estudiarse en la página oficial y varios ejemplos reales de su uso se pueden ver en la jqmgallery.

Además, existe una buena capacidad de integración entre jquery mobile y OpenLayers en su última versión, como puede verse p.ej. en este enlace. Esta es una gran combinación para realizar aplicaciones geográficas web móviles.

Saludos a todos.

OpenLayers y pestañas con jQuery

2011-04-21T00:00:00Z

En este artículo vamos a ver cómo incluir pestañas de jquery (jqueryui tabs) dentro de un popup de OpenLayers.

jQuery

jQuery se ha convertido en la librería por antonomasia para extender el javascript estándar en las páginas web modernas. Si desarrollas para la web, tienes que conocerla. Pero... ¿cómo trabajar con jQuery + OpenLayers?

Hay algunos intentos de desarrollar un plugin para jQuery que permita trabajar con OpenLayers, como MapQuery, que antes se denominaba GeoJQuery. El proyecto lleva poco tiempo, pero habrá que seguir sus pasos; quizá pronto sea una alternativa a GeoExt.
Mientras tanto es más frecuente que tengamos en marcha un proyecto con OpenLayers y queramos utilizar puntualmente jQuery, especialmente algún componente visual o widget de jqueryui, como las pestañas (tabs) o un acordeón (accordion)

Vamos a ver cómo hacer en el caso 2, con un ejemplo sencillo.

Código completo

<!DOCTYPE html>
<html lang="es">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Pestañas de jQuery en OpenLayers</title>
    
    <!-- Estilos de jQuery UI -->
    <link rel="stylesheet" href="https://code.jquery.com/ui/1.12.1/themes/base/jquery-ui.css">
    
    <!-- Librerías necesarias -->
    <script src="https://code.jquery.com/jquery-3.6.0.min.js"></script>
    <script src="https://code.jquery.com/ui/1.12.1/jquery-ui.js"></script>
    <script src="https://openlayers.org/api/OpenLayers.js"></script>
    
    <style>
        #mapa {
            width: 512px;
            height: 512px;
            border: 1px solid #ccc;
        }
    </style>
</head>
<body>
    <div id="mapa"></div>
    <script>
        // Función para preparar el contenido del popup con pestañas
        function prepararFicha(ciudad) {
            var div = $("<div>");
            var contenido = $("<div id='popupConTabs' style='font-size: 9px;'>");

            var titulos = $("<ul>")
                .append("<li><a href='#tab-1'>Atributos</a></li>")
                .append("<li><a href='#tab-2'>Wikipedia</a></li>");

            contenido.append(titulos);

            // Pestaña 1 - Información de la ciudad
            var p1 = $("<div id='tab-1'>").append(
                $("<p>").html(
                    "<b>Nombre:</b> " + ciudad.attributes.Nombre + "<br/>" +
                    "<b>Habs.:</b> " + ciudad.attributes.Habitantes
                )
            );
            contenido.append(p1);

            // Pestaña 2 - Enlace a Wikipedia
            var p2 = $("<div id='tab-2'>").append(
                $("<p>").html("<a href='" + ciudad.attributes.Wikipedia + "' target='_blank'>Wikipedia</a>")
            );
            contenido.append(p2);

            div.append(contenido);
            return div.html();
        }

        // Definiciones de proyecciones
        var WGS84 = new OpenLayers.Projection("EPSG:4326");
        var MERCATOR = new OpenLayers.Projection("EPSG:900913");

        // Definir el encuadre inicial del mapa
        var peninsula = new OpenLayers.Bounds(-18.0, 26.0, 6.0, 44.0).transform(WGS84, MERCATOR);
        var mapa = new OpenLayers.Map("mapa");
        mapa.addLayer(new OpenLayers.Layer.OSM());
        mapa.zoomToExtent(peninsula);

        // Crear una capa vectorial y añadir una ciudad
        var ciudades = new OpenLayers.Layer.Vector("Ciudades");
        mapa.addLayer(ciudades);

        var geometria = new OpenLayers.Geometry.Point(-3.8, 43.46).transform(WGS84, MERCATOR);
        var atributos = {
            Nombre: "Santander",
            Habitantes: 181589,
            Wikipedia: "http://es.wikipedia.org/wiki/Santander_(Espa%C3%B1a)"
        };

        var santander = new OpenLayers.Feature.Vector(geometria, atributos);
        ciudades.addFeatures([santander]);

        // Control de selección de elementos en el mapa
        var controlSeleccion = new OpenLayers.Control.SelectFeature(ciudades);
        mapa.addControl(controlSeleccion);
        controlSeleccion.activate();

        // Variables para los popups
        var popup;

        // Evento cuando se selecciona una ciudad
        ciudades.events.on({
            featureselected: function (e) {
                var ciudad = e.feature;
                var html = prepararFicha(ciudad);

                popup = new OpenLayers.Popup.FramedCloud(
                    "Info ciudad",
                    ciudad.geometry.getBounds().getCenterLonLat(),
                    null,
                    html,
                    null,
                    true,
                    function () {
                        controlSeleccion.unselect(ciudad);
                    }
                );

                popup.minSize = new OpenLayers.Size(300, 100);
                ciudad.popup = popup;
                mapa.addPopup(popup);

                // Activación de las pestañas de jQuery UI
                $("#popupConTabs").tabs();
            },
            featureunselected: function (e) {
                var ciudad = e.feature;
                if (ciudad.popup) {
                    mapa.removePopup(ciudad.popup);
                    ciudad.popup.destroy();
                    ciudad.popup = null;
                }
            }
        });
    </script>
</body>
</html>

http://jsfiddle.net/VictorVelarde/DbCgt/

Menu contextual sobre mapa - API Javascript ESRI

2011-02-08T00:00:00Z

Lo siguiente es una pequeña guía de algo que me parece muy útil: generar un menu contextual asociado al botón derecho cuando estás sobre el mapa. Al margen de tener la típica barra superior de herramientas, con este tipo de menú podremos tener más a mano cualquier acción invocable desde javascript que nos interese, como p.ej. hacer zoom más en un punto o recoger las coordenadas del clic y usarlas para otra acción como p.ej. un geocoding.

El resultado final sería algo como esto:

Para el menu vamos a usar la librería de Javascript dojo y el mapa estará realizado con el API ESRI de Javascript.

Tomaremos como base un ejemplo de ESRI para mostrar un mapa topográfico. Y ahora a ese codigo vamos a añadirle la funcionalidad del menu emergente.

Para ello:

dojo.require("dijit.Menu");

b) Añadimos el marcado en el HTML

Añadimos al HTML de la pagina el código de marcado del diálogo (también se podría crear al vuelo con javascript). Los atributos son importantes para vincularlo correctamente al mapa y cada entrada del menu tiene asociada la función de javascript que queramos:

<div dojotype="dijit.Menu" id="menu" contextmenuforwindow="false" 
     style="display: none;" targetnodeids="map">
    <div dojotype="dijit.MenuItem" onclick="Foo();">Foo</div>
    <div dojotype="dijit.MenuSeparator"></div>
    <div dojotype="dijit.MenuItem" onclick="Bar();">Bar</div>
</div>

c) Captura del evento de clic derecho

Y finalmente la captura del evento 'clic botón derecho' y el guardado del punto del mapa. De manera automática y justo a continuación de la gestion del evento, dojo se encargará de mostrar el menu emergente y ya podremos usar en nuestras funciones el último valor de la variable lastPoint.

dojo.connect(map, 'onMouseDown', this, function(evt) {
    if (evt.button !== 2) return; // solo botón derecho
    lastPoint = evt.mapPoint;
});

d) Código completo

El código completo sería algo como:

<!DOCTYPE html>
<html lang="en">
<head>
    <meta charset="utf-8">
    <title>Topographic Map</title>
    <link rel="stylesheet" type="text/css" 
          href="http://serverapi.arcgisonline.com/jsapi/arcgis/1.6/js/dojo/dijit/themes/tundra/tundra.css">
    
    <style>
        html, body {
            height: 100%;
            width: 100%;
            margin: 0;
            padding: 0;
        }
    </style>

    <script type="text/javascript">
        var djConfig = { parseOnLoad: true };
    </script>

    <script type="text/javascript" 
            src="http://serverapi.arcgisonline.com/jsapi/arcgis/?v=1.6">
    </script>

    <script type="text/javascript">
        dojo.require("dijit.layout.BorderContainer");
        dojo.require("dijit.layout.ContentPane");
        dojo.require("esri.map");
        dojo.require("dijit.Menu");

        var map;
        var lastPoint;

        function Foo() {
            alert("x: " + lastPoint.x + " y: " + lastPoint.y);
        }

        function Bar() {
            alert('Bar');
        }

        function init() {
            var initExtent = new esri.geometry.Extent({
                "xmin": -13635568,
                "ymin": 4541606,
                "xmax": -13625430,
                "ymax": 4547310,
                "spatialReference": { "wkid": 102100 }
            });

            map = new esri.Map("map", { extent: initExtent });

            var basemap = new esri.layers.ArcGISTiledMapServiceLayer(
                "http://services.arcgisonline.com/ArcGIS/rest/services/World_Topo_Map/MapServer"
            );

            map.addLayer(basemap);

            var resizeTimer;

            dojo.connect(map, 'onLoad', function (theMap) {
                dojo.connect(dijit.byId('map'), 'resize', function () {
                    clearTimeout(resizeTimer);
                    resizeTimer = setTimeout(function () {
                        map.resize();
                        map.reposition();
                    }, 500);
                });
            });

            dojo.connect(map, 'onMouseDown', this, function (evt) {
                if (evt.button !== 2) return; // Only right button
                lastPoint = evt.mapPoint;
            });
        }

        dojo.addOnLoad(init);
    </script>
</head>

<body class="tundra">
    <div dojotype="dijit.layout.BorderContainer" 
         design="headline" 
         gutters="false" 
         style="width: 100%; height: 100%; margin: 0;">
        
        <div id="map" 
             dojotype="dijit.layout.ContentPane" 
             region="center" 
             style="overflow: hidden;">
        </div>
    </div>

    <!-- Right-button menu -->
    <div dojotype="dijit.Menu" id="menu" 
         contextmenuforwindow="false" 
         style="display: none;" 
         targetnodeids="map">
        
        <div dojotype="dijit.MenuItem" onclick="Foo();">Foo</div>
        <div dojotype="dijit.MenuSeparator"></div>
        <div dojotype="dijit.MenuItem" onclick="Bar();">Bar</div>
    </div>
</body>
</html>

La última versión del API para JS disponible con la que lo hemos probado es la v2.1 pero no debería ser un problema usar el código en otras versiones.

Material de introducción a OpenLayers

2011-01-31T00:00:00Z

Recientemente he tenido el placer de participar como profesor dentro de la primera edición del curso Experto en Desarrollo y Gestión de Sistemas de Información Geográfica de la Universidad de Cantabria.

El módulo que impartí era una introducción rápida a OpenLayers. La mayoría de los alumnos eran geógrafos, pero también había biólogos, historiadores, sociólogos... sin una base previa de programación pero con interés en aprender.

Cuelgo a continuación el documento de apuntes que se les entregó a los alumnos para apoyar y complementar los ejercicios prácticos hechos en clase.

El documento pretende recoger los fundamentos básicos útiles (sobre neogeografía, mashups, html, javascript...) para que una persona sin conocimientos previos de programación se sienta cómoda al empezar a trabajar con OpenLayers.

Saludos y que sea útil.

Nota (15-06-2013): Estos materiales han sido revisados y ampliados, ver Materiales curso OpenLayers e Ikimap - DGSIG 2013

Convertir rasters de un directorio a otro formato con gdal

2010-05-10T00:00:00Z

Teniendo acceso desde línea de comandos a la utilidad gdal_translate (distribuida p.ej. en FWTools), podemos convertir todos los ficheros .ecw de una carpeta a formato .tif, mediante el siguiente código en Python:

import os

directorio_actual = os.getcwd()
directorio_salida = os.path.join(directorio_actual, "resultados")

os.makedirs(directorio_salida, exist_ok=True)

for root, dirs, files in os.walk(directorio_actual):
    for fichero in files:
        nombre_fichero, extension = os.path.splitext(fichero)
        if extension == ".ecw":
            comando = f"gdal_translate {fichero} {os.path.join(directorio_salida, nombre_fichero + '.tif')}"
            print(comando)
            os.system(comando)

Copiamos el código a un fichero llamado p.ej. ejecutar.pydentro de la carpeta que nos interese, creamos una carpeta dentro para los ficheros transformados ('resultados') y ejecutamos... Más fácil imposible.

Se pueden introducir fácilmente otras variantes, p.ej. con otros formatos de raster, viendo las opciones disponibles en la herramienta gdal_translate

Geoproceso interactivo vs geoproceso en batch

2009-12-29T00:00:00Z

En ocasiones, con geoprocesos que tienen como parámetro de entrada entidades vectoriales, es interesante que podamos ejecutarlos de dos modos:

(1) de manera interactiva (dibujando nosotros las geometrías) o (2) suministrando una capa ya existente que tenga las entidades (p.ej. un shapefile). Dentro del entorno de geoprocesos de ESRI, esto se corresponde con la definición de un parámetro de tipo FeatureSet (1) y un parámetro como FeatureLayer (2), respectivamente.

[Esto en la versión 9.3 de ArcGIS Desktop viene incorporado 'de serie', así que no hay problema. Lo que se comenta a continuación en este post es aplicable solo para la versión 9.2]

Una manera sencilla de que el mismo script pueda trabajar con los dos modos es como se muestra a continuación:

gp = arcgisscripting.create()
gp.overwriteoutput = 1
if gp.ScratchWorkspace is None:
    gp.ScratchWorkspace = gp.GetSystemEnvironment("TEMP")
# Parametros de entrada.........
fs = gp.GetParameter(0)   # (1) FeatureSet [opcional]
fLayer = gp.GetParameter(1)   #(2) FeatureLayer [opcional]
# Detección del MODO DE USO
if (str(fLayer).strip() != ""):
    gp.AddMessage("Trabajando con modo batch...")
else:
    gp.AddMessage("Trabajando con modo interactivo...")
    #Adaptación del FeatureSet a Feature Layer
    tmp = str(int(math.ceil(random.random()*1000000)))
    fLayer = "%s\\%s.shp" %(gp.ScratchWorkspace, tmp)
    fs.Save(fLayer)
# A partir de aquí, el tratamiento puede ser igual
registros = gp.SearchCursor(fLayer)
registro = registros.Next()
while registro:
    # tratamiento del registro [...]
    registro = registros.Next()

En la línea tmp = ... también puede usarse gp.CreateScratchName
Que sea útil.

Descarga de ficheros desde Web Coverage Service (WCS)

2009-11-09T00:00:00Z

Este script sirve para realizar peticiones a un servicio OGC-WCS para, dado un encuadre y una 'coverage' conocida, descargar su información a local en ficheros. Está realizado con python y utiliza la librería urllib2. Los ficheros raster generados, en Geotiff o AsciiGrid, pueden luego cargarse en cualquier programa GIS o manipularse con librerías estándar como gdal.

El resultado en este caso es un modelo digital del terreno como éste:

UtilidadesWCS.py

import os
import time
import urllib2

class ServicioWCS:
    """
    Utilidad para generar peticiones a un servicio OGC-WCS y guardar los resultados en disco.
    
    @author: VictorVelarde (victor.velarde@gmail.com)
    """
    
    # Class constants (in same units as projection system)
    ANCHURA_PETICION = 10000
    SEGUNDOS_ESPERA_ENTRE_PETICIONES = 5
    
    def __init__(self, url):
        """
        Constructor with service URL.
        
        Args:
            url (str): Base URL for the WCS service, 
                      e.g.: http://www.idee.es/wcs/IDEE-WCS-UTM30N/wcsServlet?
        """
        self.url = url
    
    def ExtraerFicheros(self, xmin, ymin, xmax, ymax, directorioSalida, formatoWCS):
        """
        Extract files from WCS service based on given coordinates.
        
        Args:
            xmin (float): Minimum X coordinate
            ymin (float): Minimum Y coordinate
            xmax (float): Maximum X coordinate
            ymax (float): Maximum Y coordinate
            directorioSalida (str): Output directory path
            formatoWCS (str): WCS format type
        """
        if not os.path.isdir(directorioSalida):
            os.mkdir(directorioSalida)
            
        print('Inicio de la extraccion')
        i = 1
        
        for x in range(xmin, xmax, ServicioWCS.ANCHURA_PETICION):
            for y in range(ymin, ymax, ServicioWCS.ANCHURA_PETICION):
                url = (
                    f'{self.url}?REQUEST=GetCoverage&SERVICE=WCS&VERSION=1.0.0'
                    f'&FORMAT={formatoWCS}&COVERAGE=MDT25_peninsula_zip'
                    f'&BBOX={x},{y},{x + ServicioWCS.ANCHURA_PETICION},'
                    f'{y + ServicioWCS.ANCHURA_PETICION}&CRS=EPSG:23030'
                    f'&RESX=25&RESY=25'
                )
                
                print(url)
                peticion = urllib2.Request(url)
                respuesta = urllib2.urlopen(peticion)
                
                extension = {
                    FormatoWCS.ASCII_GRID: '.asc',
                    FormatoWCS.GEOTIFF: '.tif'
                }
                
                with open(f'{directorioSalida}/{i:03d}{extension[formatoWCS]}', 'wb') as fileHandle:
                    fileHandle.write(respuesta.read())
                
                time.sleep(ServicioWCS.SEGUNDOS_ESPERA_ENTRE_PETICIONES)
                i += 1
                
        print('Fin de la extraccion')


class FormatoWCS:
    """Available WCS format types."""
    ASCII_GRID = 'AsciiGrid'
    GEOTIFF = 'Geotiff'

Y para ejecutarlo:

from UtilidadesWCS import ServicioWCS, FormatoWCS

# Initialize WCS service with IDEE's URL
servicio = ServicioWCS("http://www.idee.es/wcs/IDEE-WCS-UTM30N/wcsServlet")

# Extract data in ASCII Grid format
servicio.ExtraerFicheros(
    xmin=333850.0,
    ymin=4728100.0,
    xmax=503850.0,
    ymax=4888100.0,
    directorioSalida="extraccion",
    formatoWCS=FormatoWCS.ASCII_GRID
)

# Extract same area in GeoTIFF format
servicio.ExtraerFicheros(
    xmin=333850.0,
    ymin=4728100.0,
    xmax=503850.0,
    ymax=4888100.0,
    directorioSalida="extraccion",
    formatoWCS=FormatoWCS.GEOTIFF
)

Conferencia de usuarios ESRI España 2009

2009-10-03T00:00:00Z

El pasado día 30 de septiembre y 1 de octubre se celebró en el IFEMA de Madrid la conferencia de usuarios de ESRI ESpaña 2009. Aunque hubo ponencias temáticas sobre aspectos variados como utilities, administración local o defensa, acudí sobre todo a ponencias técnicas.

Geolics

Como resultado de los trabajos que hemos estado realizando con ArcGIS Server y geoprocesos en el IHCantabria, presenté el poster Geolics.

poster-geolics.pdf

Conferencia

En la conferencia se presentaron algunas cuestiones interesantes, sobre la versión 9.3.1 y algunos avances de la próxima v9.4 (estimada para mayo de 2010). Algunas cosas que considero interesantes:

ArcGIS Desktop

Lo más destacable desde la 9.3.1 es quizá el nuevo formato de mapa 'Map Service Definition' (MSD). Parece que viene a sustituir paulatinamente al MXD y se usa en un nuevo motor interno de dibujado que produce mapas bastante más rápidos, tanto en escritorio como en servidor. Otra novedad es la 'Map Service Publishing': una barra de herramientas que parece útil para asesorar (warnings, infos...) sobre cómo hacer documentos de mapa más rápidos de cara a publicación.

Por otro lado, de la 9.4 se vieron algunos detalles como la integración en Arcmap de una ventana con funciones de ArcCatalog (algo bastante práctico, la verdad), un modo más rápido de edición de features mediante 'plantillas' y un nuevo tipo de capa llamado 'Query Layer' que permite pintar directamente el resultado de consultas complejas de SQL contra bases de datos estándar (SQL Server y Oracle). Algunos detalles más sobre sus novedades en Novedades de desktop 9.4 y http://www.unmundoparatodos.com/2009/08/16/arcgis94\_novedades/

ArcGIS Explorer (900)

La nueva versión del visor gratuito trae bastantes mejoras estéticas (p.ej. un toolbar tipo 'ribbon' como el de ms-office) y alguna funcional (lee .csv, tiene vista 2D/3D, enlaces a fotos/videos, generación de 'presentaciones')...

ArcGIS Server

Hay una mejora muy importante de rendimiento en los servicios de mapa en la 9.3.1. y avances en el sistema de caché previstos para la v.9.4 (se pueden mezclar formatos de imagen en una misma cache, cuesta mucho menos moverla por la red...). Se avanza igualmente en los APIs para entornos RIA: Flex y Silverlight.

Mis impresiones personales:

a) El desktop está 'tocando techo' en cuanto a funcionalidad. Las mejoras que aparecen se centran en usabilidad (lo cual no me parece mal, la verdad, porque le hace bastante falta) y en ser una buena herramienta para el administrador de ArcGIS Server.
b) Hay una inversión importante de esri en el ArcGIS Explorer, enfocándolo como un Google Earth, para usuarios no expertos en GIS. Si bien hasta ahora apenas lo he usado, creo que puede ser una herramienta útil para un uso esporádico o para distribuir a ciertos usuarios como visor.
c) El interés fundamental del desarrollo en esri está en ArcGIS Server y el producto está madurando. El objetivo actual es ganar rendimiento en los servicios de mapa, e ir trasladando funcionalidades del desktop al web. Creo que el próximo objetivo estará en los geoprocesos: primero en que se ejecuten más rápido (ahora mismo no son muy rápidos y parece necesario acudir a desarrollo más complejos como las Server Object Extensions -SOE-).
d) El API de Javascript para server me sigue pareciendo el más interesante y el camino a seguir (especialmente para dejar de lado el 'infierno' del adf para .net. Además, por mucho que veo demos en Silverlight y Flex, no veo diseños ni "efectos" que no se puedan sacar con alguna librería js, y al menos se mantiene uno en los estándares web, sin plugins propietarios.
d) ESRI está estableciendo alianzas con Microsoft en varios frentes (uso de los servicios de Virtual Earth, el software MapIt, integración con SharePoint...) parece que para posicionarse ante fuertes competidores como Google o el creciente ecosistema de Software libre.

Cómo convertir un shapefile a geojson

2009-02-02T00:00:00Z

Recientemente necesitábamos publicar una capa geográfica dentro de una web con un sencillo visor de mapas hecho con Openlayers. La capa estaba en el formato omnipresente ESRI Shapefile.

Openlayers acepta un elevado número de orígenes de datos (WMS, WFS, KML, GeoJSON...) pero no directamente ficheros .shp. Una opción hubiera sido utilizar Geoserver como servidor de los datos, pero buscábamos algo más rápido, para una capa estática, y no queríamos incrementar la infraestructura en el despliegue.

Solución rápida: generar un fichero con el contenido del .shp en formato geojson y luego alojarlo directamente en el sitio web. ¿Cómo convertirlo? Utilizando la herramienta gratuita y abierta para conversión entre formatos llamada ogr2ogr.

Descargamos e instalamos FWTools que incluye la citada ogr2ogr y otras utilidades.
Desde línea de comandos, en la ruta donde hayamos instalado el software (o la incluimos en el PATH y tecleamos desde cualquier directorio):
```
ogr2ogr c:\\ficheroSalida.geojson -f “GeoJSON” C:\\ficheroOriginal.shp
```
Y con esto ya tenemos un fichero geojson apto para consumir desde OpenLayers.