Skip to main content

Documentation Index

Fetch the complete documentation index at: https://mintlify.com/astrxnomo/manizalesdepie/llms.txt

Use this file to discover all available pages before exploring further.

The seed data layer consists of two parts: the supabase/seed.sql file which populates known aid sites from press and institutional reporting, and the scripts/seed-barrios.mjs script which loads the 114 official barrio polygons into the neighborhood table. Neither part is optional — the map needs neighborhood boundaries before site pins can be assigned to a barrio, and the site rows give curators something to geocode and publish from day one.

​
The seed.sql file

supabase/seed.sql carries real shelter names, collection points, blood donation centers, and census points sourced from press and institutional reporting about the August 2026 earthquake in Manizales and Villamaría. It inserts:
  • Shelters (shelter) — Coliseo Mayor, Coliseo Menor, CIC Aranjuez, Coliseo de la Universidad de Caldas, and Coliseo de Villamaría.
  • Blood donation sites (blood_donation) — Canchas auxiliares de Palogrande and Hemocentro del Café, both flagged with O-positive and O-negative urgency.
  • Collection points (collection_point) — Cruz Roja Caldas and Banco de Alimentos de Manizales, each pre-populated with site_item rows that specify what is needed and what is explicitly not accepted (used clothing and near-expiry food are refused).
  • Medical/coordination post (medical_post) — Puesto de Mando Unificado at Bomberos Manizales.
  • Neighborhood status rows — gas suspension notices for La Estrella, Milán, and Centro, derived from Efigas reporting.
  • Work orders — eleven individual household requests sourced from press and community mapping reports on 14–15 August, with coordinates rounded to three decimal places (~100 m) to avoid publishing a precise household address.
Every row is inserted with published = false by default.
Coordinates are approximate and unverified. The latitude and longitude values in seed.sql are rough placements derived from the sector name in a press report — not a geocoded address. Sending someone to the wrong shelter during an emergency is worse than having no pin at all. A curator must geocode and verify each row before toggling published = true in the /admin queue.
Apply the seed with: 
npx supabase db execute --file supabase/seed.sql
Run barrios.sql (generated by fetch-barrios.mjs) before this file when possible. The sites above rely on a trigger that stamps each row with its neighborhood_id by resolving the site’s coordinates against barrio boundary polygons — that resolution returns null until the polygons exist.

​
Loading neighborhood data

Three scripts manage neighborhood geometry, and they must be run in order.

​
scripts/fetch-barrios.mjs

Downloads the official barrio layer from the Alcaldía de Manizales ArcGIS open data portal (geodata-manizales-sigalcmzl.opendata.arcgis.com) — specifically the “Límite de barrios Municipio de Manizales” layer, which encodes the 116 polygons defined by Acuerdo Municipal 589 de 2004 (amended by 1038 de 2019). The script then:
  1. Simplifies each ring with Ramer–Douglas–Peucker to reduce byte count over a potentially degraded network.
  2. Merges split polygons (barrios with non-contiguous parts, like Puerta del Sol/Corinto) into a single MultiPolygon feature.
  3. Fixes accent marks by cross-referencing OSM neighbourhood nodes within Manizales’s administrative boundary via Overpass API. The unaccented all-caps names from the official dataset (“SAN JOSE”, “COLON”) are replaced with their properly accented OSM spellings where a match is found, and title-cased otherwise.
  4. Writes public/barrios.geojson and generates supabase/barrios.sql as a side effect.
The script also reads any previously committed public/barrios.geojson as a spelling cache, so a failed Overpass run never silently overwrites good accent marks with unaccented fallbacks.
The Overpass API is used only for accent correction, not for geometry. Overpass responds with HTTP 504 intermittently — the script has two mirror endpoints and falls back gracefully, logging a warning and continuing with title-cased names. The barrio boundary data itself comes entirely from the Alcaldía’s ArcGIS service and is unaffected by Overpass availability.

​
scripts/seed-barrios.mjs

Reads public/barrios.geojson and upserts rows into the neighborhood table, calling the upsert_neighborhood Postgres RPC for each feature. The RPC receives three parameters per call:
  • p_name — the accented barrio name resolved by fetch-barrios.mjs
  • p_comuna — the numeric commune identifier from the source layer
  • p_geojson — the full simplified polygon or MultiPolygon geometry as a GeoJSON string
The script uses the service-role key from .env.local to bypass RLS. After inserting all barrios, it calls backfill_neighborhoods to re-stamp any site or work_order rows that were inserted before the boundary polygons existed. The script is idempotent — it upserts on (name, municipality) — and is designed to be re-run whenever the Alcaldía publishes an updated layer.

​
Run order

node scripts/fetch-barrios.mjs     # downloads + writes public/barrios.geojson
node scripts/seed-barrios.mjs      # loads into the neighborhood table

​
Importing OSM sites

scripts/import-osm-sites.mjs queries the Overpass API for OSM nodes, ways, and relations tagged as hospitals, clinics, doctors, veterinary practices, and drinking water points within the administrative boundaries of Manizales and Villamaría. It deduplicates against existing site_public rows (skipping any candidate within 80 m of a known site) and inserts the remainder as site rows with status = 'unknown' and published = true, each carrying a source_url pointing to its OpenStreetMap object. Run it with: 
node --env-file=.env.local scripts/import-osm-sites.mjs
After importing, run scripts/prune-osm-sites.mjs to clean up results before curator review. These rows are starting points for a curator to inspect — OSM knows the building is there; it knows nothing about whether a clinic is receiving patients three days after an earthquake.
The scope is deliberately narrow. Pharmacies and supermarkets are excluded: this is not a city directory, and hundreds of unprompted pins would bury the ones somebody actually reported. Only categories that directly answer “where do I get or give help” are imported.

​
Adapting for a different city

To use this codebase as the basis for a different emergency:
  1. Replace public/barrios.geojson with your city’s neighborhood polygon data. The file must be a GeoJSON FeatureCollection with each feature carrying at minimum a name string property and a Polygon or MultiPolygon geometry.
  2. Update the geographic bounds in the DTO schemas. The current bounds are longitude: -76.2 to -74.8 and latitude: 4.6 to 5.6, corresponding to the Caldas department area. Out-of-area submissions are rejected at the DTO validation layer.
  3. Update the OUT_OF_AREA error messages in each DTO to reference your city and region.
  4. Run node scripts/seed-barrios.mjs with the new GeoJSON to populate the neighborhood table.
  5. Write new seed data for your emergency’s known aid sites, following the structure of supabase/seed.sql.
Nothing in this codebase deletes rows for staleness. Rows reach their expires_at and are demoted in query ordering, or are toggled to published = false by a curator. This is intentional: the database is a permanent record of the relief effort, not a real-time state machine. When the emergency ends you will have a complete, auditable history of every shelter, collection point, and household request — exactly the data a post-event review needs.

Build docs developers (and LLMs) love

Get started for freeTalk to us