Align "Analyzed roads" layer with analysis filter logic

[Copilot]

The "Analyzed roads" layer was displaying data from planet_osm_roads, which includes all OSM roads regardless of analysis status. It now queries relevant_roads with filter logic matching the analysis CTE.

Changes

• database/setup.sh: Extended relevant_roads filter to match analysis.sql CTE

  • Added numeric maxspeed ≤ 30 check: (p.tags->'maxspeed') ~ '^\d+$' AND (p.tags->'maxspeed')::integer <= 30
  • Added zone tags: DE:zone:20, DE:zone:10
  • Added walk zones: maxspeed = 'walk'

• proxy/proxy.js: Changed WFS layer from planet_osm_roads → relevant_roads

Before:

AND NOT ((p.tags->'maxspeed') IN ('30', 'DE:zone:30'));

After:

AND NOT COALESCE(
    ((p.tags->'maxspeed') ~ '^\d+$' AND (p.tags->'maxspeed')::integer <= 30)
    OR (p.tags->'maxspeed') IN ('DE:zone:30', 'DE:zone:20', 'DE:zone:10')
    OR (p.tags->'maxspeed') = 'walk',
    false
);

The blue layer now shows only roads actually eligible for Tempo-30 analysis, excluding roads already at ≤30 km/h.

Original prompt

Problem

Der Legendeneintrag "Analyzed roads" (blau) zeigt derzeit Daten aus planet_osm_roads, was inkonsistent ist mit der tatsächlichen Analyse-Logik. Es sollen nur Straßen angezeigt werden, die wirklich auf Tempo-30-Eignung geprüft wurden.

Aktuelle Situation

1. proxy/proxy.js (Zeile 60): Fragt planet_osm_roads ab - dieser Layer enthält alle OSM-Straßen, auch solche die bereits Tempo 30 haben oder nie analysiert wurden.

2. geoserver/setup.sh (Zeile 24): Publiziert relevant_roads - aber der Proxy fragt den falschen Layer ab.

3. database/setup.sh: Erstellt relevant_roads Tabelle mit bereits gefilterten Straßen (ohne bestehendes Tempo 30).

4. database/analysis.sql: Die Analyse verwendet intern einen CTE relevant_roads, aber die persistierte relevant_roads Tabelle in setup.sh hat eine etwas andere Filterlogik.

Gewünschtes Verhalten

Der "Analyzed roads" Layer soll nur Straßen anzeigen, die tatsächlich in der Tempo-30-Analyse berücksichtigt wurden:

• residential, primary, secondary, tertiary Straßen
• Ohne Straßen die bereits maxspeed ≤ 30 haben (DE:zone:30, DE:zone:20, DE:zone:10, numerisch ≤30, walk)
• Ohne living_street

Erforderliche Änderungen

1. database/setup.sh

Die relevant_roads Tabelle muss die gleiche Filterlogik verwenden wie der CTE in analysis.sql:

CREATE TABLE relevant_roads AS
SELECT 
    p.osm_id, p.highway, p.name,
    ST_Transform(p.way, 25832) AS geom
FROM planet_osm_line p
WHERE p.highway IN ('residential', 'primary', 'secondary', 'tertiary')
  AND p.highway != 'living_street'
  AND NOT COALESCE(
      ((p.tags->'maxspeed') ~ '^\d+$' AND (p.tags->'maxspeed')::integer <= 30)
      OR (p.tags->'maxspeed') IN ('DE:zone:30', 'DE:zone:20', 'DE:zone:10')
      OR (p.tags->'maxspeed') = 'walk',
      false
  );

2. proxy/proxy.js

Zeile 60 ändern von:

const layerName = 'planet_osm_roads';

zu:

const layerName = 'relevant_roads';

Auch den Kommentar in Zeile 58 aktualisieren:

// Forwarding of relevant_roads feature layer (analyzed roads without existing tempo 30)

3. Überprüfen der Konsistenz

Sicherstellen dass:

• geoserver/setup.sh den Layer relevant_roads publiziert (ist bereits korrekt)
• Die Geometrie-Transformation in relevant_roads kompatibel ist mit dem Frontend (EPSG:4326 wird vom Proxy/GeoServer erwartet)

Erwartetes Ergebnis

Nach den Änderungen:

• Blau ("Analyzed roads"): Alle Straßen die auf Tempo-30-Eignung geprüft wurden, aber keine Begründung haben
• Hell-Blau ("Residential"): Wohnstraßen (automatische Kandidaten)
• Lila ("Social facilities"): Straßen nahe Schulen, Kindergärten, etc.
• Orange ("Noise protection"): Straßen mit Lärmschutz-Begründung
• Rot ("Gap filling"): Lückenschluss-Straßen

This pull request was created from Copilot chat.

---

💬 We'd love your input! Share your thoughts on Copilot coding agent in our 2 minute survey.

[svenklingel]

Prüfe ob auch eine Anpassung der frontend/map.html oder einer anderen Datei nötig ist

[Copilot]

Prüfe ob auch eine Anpassung der frontend/map.html oder einer anderen Datei nötig ist

Keine Änderung an frontend/map.html nötig. Das Frontend nutzt bereits korrekt den Proxy-Endpoint /roads-wfs (Zeile 111), der nach meinen Änderungen in proxy/proxy.js nun relevant_roads statt planet_osm_roads abfragt. Die Datenfluss-Kette ist: Frontend → Proxy /roads-wfs → GeoServer relevant_roads → PostgreSQL relevant_roads Tabelle. Die Layer-Namen, Farben und Legende passen bereits.