All checks were successful
Deploy / build-backend (push) Successful in 6m30s
Deploy / build-worker (push) Successful in 6m44s
Deploy / changes (push) Successful in 11s
Deploy Trade-In / changes (push) Successful in 15s
Deploy Trade-In / build-backend (push) Successful in 1m19s
Deploy / build-frontend (push) Has been skipped
Deploy / deploy (push) Successful in 2m26s
Deploy Trade-In / deploy (push) Successful in 3m10s
Deploy Trade-In / build-browser (push) Has been skipped
Deploy Trade-In / build-frontend (push) Successful in 3m6s
Deploy Trade-In / test (push) Successful in 5m5s
48 lines
2.6 KiB
PL/PgSQL
48 lines
2.6 KiB
PL/PgSQL
-- 188_tradein_osm_poi_view_relax_freshness.sql
|
|
-- Fix for 185_tradein_osm_poi_view.sql: v_tradein_osm_poi_ekb enforced a HARD 2-year
|
|
-- OSM last-edit-date filter that silently dropped legitimate, stable infrastructure.
|
|
--
|
|
-- CONTEXT (trade-in location-index rework, replaces the broken location-coef):
|
|
-- Audit of the trade-in POI mirror (osm_poi_ekb_local, fed by this view via the FDW
|
|
-- bridge) found only 5 of 9 EKB metro stations and just 2787 POI total reaching
|
|
-- tradein-mvp, despite osm_poi_ekb (this table, Site Finder's own registry) having more.
|
|
--
|
|
-- Root cause: this view's WHERE clause dropped any POI whose OSM `last_osm_edit_date` is
|
|
-- older than 2 years. A subway station node, once correctly mapped, is essentially never
|
|
-- re-edited in OSM — "stale last edit" here means "nobody touched this tag in years",
|
|
-- NOT "this station stopped existing". The same logic applies to schools/hospitals/parks:
|
|
-- physically permanent infrastructure that simply isn't re-edited often.
|
|
--
|
|
-- The "2-year freshness" requirement itself (see 82_osm_poi_ekb.sql, "требование
|
|
-- Максима") was intended as a SOFT confidence signal, not a hard existence filter — Site
|
|
-- Finder itself (backend/app/api/v1/parcels.py, "POI freshness" confidence subscore) only
|
|
-- uses last_osm_edit_date to DERATE a confidence score; every POI stays in the result set
|
|
-- regardless of staleness. This view diverged into a hard filter when the FDW bridge was
|
|
-- built (185) — this migration fixes that divergence, matching Site Finder's own intent.
|
|
--
|
|
-- WHAT: CREATE OR REPLACE VIEW, same 4-column shape as 185 (category, name, lat, lon) — no
|
|
-- WHERE clause. tradein-mvp's FDW foreign table (tradein-mvp/backend/data/sql/
|
|
-- 168_fdw_osm_poi_ekb.sql) is untouched — same column list, so no FDW-side change needed.
|
|
--
|
|
-- Idempotent: CREATE OR REPLACE VIEW. GRANT re-applied (idempotent, matches 185).
|
|
|
|
BEGIN;
|
|
|
|
CREATE OR REPLACE VIEW v_tradein_osm_poi_ekb AS
|
|
SELECT
|
|
category,
|
|
name,
|
|
lat,
|
|
lon
|
|
FROM osm_poi_ekb;
|
|
|
|
GRANT SELECT ON v_tradein_osm_poi_ekb TO tradein_fdw_reader;
|
|
|
|
COMMENT ON VIEW v_tradein_osm_poi_ekb IS
|
|
'FDW source for tradein-mvp (postgres_fdw) location-index/nearby-POI list (replaces the '
|
|
'broken location-coef, #2045). No freshness filter — last_osm_edit_date is a soft '
|
|
'confidence signal only (see Site Finder parcels.py), not evidence a POI stopped '
|
|
'existing. Fixes 185_tradein_osm_poi_view.sql hard 2-year WHERE filter that silently '
|
|
'dropped 4/9 EKB metro stations + other stable infrastructure from the trade-in mirror.';
|
|
|
|
COMMIT;
|