Hush · Reescribe las reglas del campo de batalla
21 terminales en Cundinamarca. Cupos libres, buses parqueados y próximas salidas en un mapa dinámico.
Registre llegadas y salidas, controle la permanencia y venda puestos antes de que el bus salga.
Una empresa de transporte intermunicipal necesita un sistema de software para gestionar sus buses y parqueaderos dentro de los límites de Cundinamarca, Colombia. Diseñamos un sistema de información geográfica sobre PostGIS y el mapa dinámico de OpenStreetMap, documentado con el modelo de vistas arquitectónicas 4+1, y lo entregamos como sistema web y como app móvil en Cordova.
“¿Cuántos cupos libres hay ahora en cada terminal?”
Cada llegada abre un parking_stay; cada salida lo cierra. v_parking_availability compara las estadías abiertas con la capacidad máxima de cada parqueadero, y un trigger bloquea el parqueadero para que nunca se sobrepase.
“¿Dónde está el bus CB-127?”
No se necesita GPS: el bus se ubica en el parqueadero de su estadía abierta. Mientras un viaje está en ruta, PostGIS estima su posición sobre el trayecto con ST_LineInterpolatePoint según el tiempo transcurrido.
“¿Quedan puestos en el de las 13:05 a Ubaté?”
Cada ticket guarda un número de puesto de un viaje. Puestos disponibles = capacidad del bus − tiquetes vendidos. La base de datos rechaza puestos duplicados, puestos inexistentes y ventas después de la salida.
database/ · app/docs/ARCHITECTURE.md01–06 *.sqlST_Covers rechaza cualquier parqueadero por fuera.02_functions.sqlparking_stay abierta → ubicación; no requiere rastreo en tiempo real.v_bus_locationtrip guarda origen, destino, hora de salida, hora de llegada y tiempo de permanencia en el parqueadero.Registrar → Nuevo viajeapi_register_arrival / api_register_departure, solo para su propio parqueadero.Pestaña Registrarmobile/api_nearest_lotsLos parqueaderos de la empresa, exactamente como aparecen en el taller, sobre OpenStreetMap. Todo lo que está fuera de Cundinamarca y Bogotá D.C. se oscurece: la propia base de datos se niega a registrar una terminal más allá de esa línea.
El modelo de Kruchten describe el sistema desde el punto de vista de cada interesado. Cuatro vistas — lógica, de procesos, de desarrollo y física — se integran y validan con una quinta: los escenarios (casos de uso).
Casos de uso derivados del taller. Cada uno se rastrea en las demás vistas: p. ej. Registrar llegada se vuelve la clase ParkingStay (lógica), la secuencia de llegada (procesos), api_register_arrival (desarrollo) y una llamada del celular a Supabase (física).
El modelo de dominio. Los objetos espaciales (ServiceArea, ParkingLot) llevan geometrías PostGIS; toda la operación cuelga del Trip (la “información del bus”) y del ParkingStay (lo que registra el administrador).
ParkingStay = una llegada + una salida → el tiempo real de permanencia.Trip = origen, destino, salida, llegada y permanencia planeada.Ticket = un puesto de un viaje → disponibilidad de puestos.DriverShift = horario de servicio del conductor, con base en una terminal.Comportamiento en ejecución del escenario más crítico: registrar la llegada de un bus. Toda la operación es una única transacción de PostgreSQL ejecutada por una función RPC.
parking_lot (FOR UPDATE), así dos administradores no pueden ocupar el último cupo al mismo tiempo.api_overview() cada 30 s — una sola petición trae parqueaderos, buses y estadísticas.Capas y los archivos que las implementan. Las reglas de negocio viven en la base de datos, así el sistema web, la app Cordova y cualquier cliente futuro obedecen exactamente las mismas reglas.
app/ se comparte tal cual entre la web y la app móvil (npm run sync).api.js es el único módulo que habla con la red.Dónde corre cada pieza. Los clientes son livianos: dibujan el mapa OSM y llaman a la API de Supabase por HTTPS. El único servidor es el proyecto administrado de Supabase, desplegado en la región us-east-1 (Virginia, EE. UU.).
Nueve tablas en PostgreSQL + PostGIS (SRID 4326). Las reglas del negocio se imponen dentro de la base de datos — triggers, restricciones y funciones — para que ningún cliente pueda meter un bus en una terminal llena ni crear una terminal fuera de Cundinamarca.
Cada terminal se valida contra los polígonos del departamento importados de OpenStreetMap.
CREATE FUNCTION fn_in_service_area(p geometry) RETURNS boolean AS $$ SELECT EXISTS (SELECT 1 FROM service_area sa WHERE ST_Covers(sa.geom, p)); $$; -- BEFORE INSERT OR UPDATE OF geom ON parking_lot -- → RAISE 'La ubicación está fuera de Cundinamarca'
La fila del parqueadero se bloquea antes de contar, así las llegadas concurrentes se serializan.
SELECT capacity INTO v_capacity FROM parking_lot WHERE id = NEW.parking_lot_id FOR UPDATE; SELECT count(*) INTO v_occupied FROM parking_stay WHERE parking_lot_id = NEW.parking_lot_id AND departed_at IS NULL; IF v_occupied >= v_capacity THEN RAISE EXCEPTION 'El parqueadero % está lleno'…
Dirección geocodificada → terminales más cercanas usando el índice GiST y el operador de distancia <->.
SELECT code, municipality, available, ST_DistanceSphere(pl.geom, q.g) / 1000 AS km FROM parking_lot pl JOIN v_parking_availability USING (id) ORDER BY pl.geom <-> ST_SetSRID(ST_MakePoint(lng, lat), 4326) LIMIT 3;
No se requiere rastreo en tiempo real; mientras está en ruta, el bus se ubica sobre su trayecto según el tiempo transcurrido.
ST_LineInterpolatePoint( ST_MakeLine(origin.geom, destination.geom), LEAST(1, GREATEST(0, extract(epoch FROM now() - t.actual_departure) / extract(epoch FROM t.scheduled_arrival - t.scheduled_departure))))
Este es el sistema de información real funcionando contra la base de datos en Supabase — no es una maqueta. Abra una terminal, registre una salida, venda un puesto o busque una dirección: cada acción pasa por las reglas de PostGIS de arriba.
Cupos libres, buses parqueados, permanencia, próximas salidas, llegadas y turnos de conductores por terminal.
Un bus 3D recorre la vía real (OSRM) según la hora; síguelo con la cámara o acelera el reloj ×30 a ×600.
Llegadas, salidas y nuevos viajes con origen, destino, horas y permanencia.
Mapa de puestos por bus y viaje; venda un puesto y vea cómo se actualiza la disponibilidad.
La app móvil está hecha con Apache Cordova. Empaqueta exactamente el mismo código del sistema web, cambia a un panel inferior deslizable en pantallas pequeñas y usa el GPS del dispositivo para encontrar la terminal más cercana.
npm run sync copia app/ en mobile/www e inyecta cordova.js.cordova-plugin-geolocation alimenta la consulta KNN de “terminal más cercana”.$ npm install $ npm run sync # app/ → www/ $ npx cordova platform add android $ npx cordova run android # o: npm run browser
Sin servidor de aplicaciones: la base de datos es un proyecto de Supabase y los clientes son archivos estáticos.
Cree un proyecto en Supabase y ejecute database/01…06_*.sql en orden (editor SQL o migraciones).
Pegue la URL del proyecto y la llave pública en app/js/config.js.
Sirva la carpeta (p. ej. npx serve .) y abra esta página o app/.
En mobile/: npm install, npm run sync, cordova run android.