Origo i vår miljö

Ägare: GIS/Origo-förvaltning · Senast uppdaterad: 2026-02-24

Helhetsbild – hur Origo, GeoServer och GWC hänger ihop

• GeoServer är källan till sanning: data, attribut, CQL-filter, stilar och grundprestanda.
• GeoWebCache ansvarar för cache och tiled leverans (WMTS, seed/truncate, gridset).
• Origo är presentations- och interaktionslager (konfiguration, UX, synlighet, verktyg).

Miljöer och viktiga URL:er

• GeoServer UI: https://srv-origo01.kommun.skovde.se/geoserver/web
• OWS endpoint: https://srv-origo01.kommun.skovde.se/geoserver/ows/
• REST layers: https://srv-origo01.kommun.skovde.se/geoserver/rest/layers.json
• Intern Origo: https://srv-origo01.kommun.skovde.se/
• Publik Origo: https://origo.skovde.se

Operativa playbooks (så jobbar vi hos oss)

1) Publicera nytt lager (data → Origo)

Förutsättningar: datakälla tillgänglig, workspace bestämt, lagernamn enligt konvention.

1. Publicera i GeoServer och testa preview.
2. Verifiera GetMap/GetFeatureInfo direkt mot OWS.
3. Lägg till source/layer i Origo-konfig.
4. Kontrollera grupp, synlighet, min/max scale.

Vanliga misstag: fel workspace-prefix, blandad CRS, lager kvar i fel layergroup.

Verifiering: GetMap returnerar 200, lagret syns i klient, inga console-fel.

Done-definition: lager kan aktiveras av användare och ger korrekt legend/info.

2) Ändra stil + legend utan att sabba cache

Förutsättningar: aktuell SLD backupad, lagret identifierat i GWC.

1. Uppdatera stil i GeoServer och validera Rule Names.
2. Testa GetLegendGraphic utan och med RULE där relevant.
3. Truncate/seed om cache-beroende lager påverkas.
4. Verifiera i Origo att legend och rendering matchar.

Vanliga misstag: RULE=undefined, fel Rule Name, glömd cache-rensning.

Verifiering: legendsvar 200, inga schemafel i logg, uppdaterad symbolik i klient.

Done-definition: ny stil visas konsekvent i både WMS och WMTS-flöden där tillämpligt.

3) Välj WMS vs WMTS (beslutsmatris)

Förutsättningar: syfte med lagret (dynamik vs hastighet) är tydlig.

• Välj WMTS när samma bild efterfrågas ofta och kan cacheas.
• Välj WMS när stil/filter ändras ofta eller data är starkt dynamisk.

Vanliga misstag: köra tung bakgrund som WMS i stället för WMTS.

Verifiering: jämför svarstid; hos oss ofta ~70–200 ms WMTS vs ~500–700 ms WMS på tunga lager.

Done-definition: valt läge motiverat och dokumenterat i changelog/PR.

4) Incident: karta seg / timeout (triage)

Förutsättningar: reproducerbart symptom och timestamp från användare.

1. Bekräfta symptom i klient (Network/Console).
2. Kör motsvarande OWS-anrop direkt.
3. Isolera lager/stil: ett i taget.
4. Kontrollera Tomcat/proxy/GWC-loggar i samma tidsfönster.

Vanliga misstag: felsöka frontend först och hoppa över serveranrop.

Verifiering: flaskhals pekad (datakälla, render, cache eller nätverk).

Done-definition: åtgärd implementerad + mätbar förbättring + incidentnotering uppdaterad.

5) Release: PR → deploy → verifiering

Förutsättningar: granskad PR, uppdaterad docs/changelog, rollback-plan finns.

1. Merge till rätt branch enligt driftflöde.
2. Låt deployjobbet bygga och distribuera.
3. Verifiera intern sida först, därefter publik vid behov.
4. Bekräfta sök, lager och kritiska kartflöden.

Vanliga misstag: glömd verifiering av sökindex och cacheläge.

Verifiering: startsida, felsökning, try-it och minst ett WMS/WMTS-lager fungerar utan fel.

Done-definition: release signerad i checklista och monitorerad utan regressionsfel.