En tid har det diskuterats hur man kan jobba med detaljplaner i exempelvis QGIS. Jag själv har aldrig gjort det, jag vet knappt vad en detaljplan är, så med det perspektivet tänkte jag kika närmare på ämnet för att se vad jag som QGIS användare har att tillföra.
Vad är en detaljplan?
Med detaljplan får kommunen reglera användningen av mark och vattenområden.
Kommunen kan använda detaljplan för att pröva om ett mark och vattenområde är lämpligt för bebyggelse. Det gäller till exempel både när det ska byggas nytt och när bebyggelse ska förändras eller bevaras. Detaljplanen ska redovisa allmänna platser, kvartersmark och vattenområden och gränserna för dessa.
Ovanstående har jag hämtat från https://www.boverket.se/sv/PBL-kunskapsbanken/ där det går att generera en PDF för nedladdning, om man inte vill läsa on-line.
Detaljplaner skall utöver ovanstående generella områden även beskriva mer detaljerad information om vad och hur man får bygga eller upprätta olika typer av verksamhet. Exempelvis hur höga byggnader inom ett område får vara.
Jag tänker inte försöka bryta ner alla instruktioner i detalj, utan skummar igenom dokumentet och letar efter sådant som kan appliceras i ett GIS.
Framför allt ytor
Detaljplanen är inte bara en karta! Det är även mängder av beskrivningar och riktlinjer i text och bild. Här fokuserar jag dock på just kartan. Så när jag nämner detaljplanen, så är det just kartan jag menar i de flesta fall.
Som jag förstår det är detaljplanen framför allt ytor! Generella ytor och mer detaljerade. Varje ”plan” beskriver ett område, med flera mindre ingående delar. Allt presenteras på en lämplig karta i bakgrunden. Detaljplanen behöver således inte innehålla detaljerad kartinformation i sig, utan detta kan man hämta från exempelvis Lantmäteriets produkter.
Problemet som jag ser det är absolut inte om det går att skapa en karta med lämpligt utseende i QGIS, det gör det tveklöst. Snarare så gäller det att göra arbetet med planerna, eller de geodata som skall ingå, så effektivt som möjligt. Man bör undvika dubbelarbete och lagring av information på flera ställen. Jag skulle tro att man även bör ha viss spårbarhet i arbetet och även kunna plocka fram gamla planer att jämföra med?
Just spårbarheten lämnar jag lite. Om man vill ha fullständig spårbarhet så får man titta lite på exempelvis Geogig (Git för geodata) där det går att spåra varenda liten förändring. Här nöjer jag mig med att hantera fastställda planer. Inte ändringar.
Databas
Det är sannolikt bäst med en PostGIS databas, men i QGIS så är det även enkelt att lyfta ut enskilda planer till GeoPackage. Vilket är ett utmärkt sätt att sprida eller distribuera en plan. Stilsättningar för QGIS går att lagra i båda databaserna och data i sig går att läsa av flera andra GIS, även Esri ArcGIS.
För att testa så skapar jag en enkel tabell med några attribut som jag tror behövs för att uppfylla Boverkets rekommendationer (det behövs sannolikt betydligt fler).
- Plan Namn (alla objekt ingående i planen skall ha samma namn)
- Upprättad datum
- Ändrad datum
- Upphävd datum (samtliga datum gör att plandatabasen kan filtreras och sökas historiskt)
- Områdestyp (allmän plats, kvarter, vatten…)
- Användning (för allmän plats exempelvis gata, torg, park eller natur)
- Beteckningar (om ett område har flera användningsområden)
- Administrativa bestämmelser (om ett område har sådana)
- Skyddsbestämmelser (om ett område har sådana)
- Höjdrestriktioner (byggnadshöjd och schaktdjup)
Ovanstående löser säkert inte alla problem, men det får duga när jag testar lite. En databas med ovanstående skapas i PostGIS.
Sedan är det dags att jobba i QGIS för att se hur det kan tillämpas.
Nu har jag inte några detaljerade kartor som bakgrund, men jag kan tänka mig att fastighetskartan skulle vara lämplig, eller annan lokal karta. Jag använder ett flygfoto från Google och skapar ett fiktivt område utanför Eksjö som jag kan testa på.
Här kommer ”trix” nummer ett. Om ni titta noga så ser ni att jag har två ”lager” i kartan. Ett med planområdets gräns, och ett med alla användningsområden i detaljplanen (just nu inte så många). Det är däremot inte två datalager som ligger bakom! Hade det varit det hade jag varit tvungen att redigera två lager om jag förändrade yttergränsen. Nu är mitt planområdeslager ett ”virtuellt lager” skapat med ett SQL kommando som slår samman alla synliga lager i Detaljplanslagret till en polygon, som sedan kan stilsättas.
SELECT Plan_Namn, st_union(geometry) from Detaljplan;
Vill jag inte ha ännu ett polygonlager för gränserna så kan jag skapa ett linjelager genom att lägga till st_boundary() till geometrin, mer om detta senare.
Nu kan jag ”klippa” upp området, i områdestyper och ange användningsområde som jag vill, och min gräns för planområdet följer hela tiden med den totala utsträckningen. Man får tänka på att använda snappning och topologisk redigering, så att det inte blir några glipor.
Vill jag visa flera planer samtidigt så kan jag lägga till group by Plan_Namn till uttrycket. Urvalet av planer görs sedan med ett filteruttryck i grundlagret ”Detaljplan”.
Ytterligare uppdelningar med begränsningar i form av ”prickområden” och liknande har jag inte testat fullt ut här, men det skulle eventuellt också kunna göras med virtuella områden på samma sätt som för det övergripande detaljområdet.
För att göra det lite enklare att redigera och sätta egenskaper på nya områden så kan man använda inbyggda formulär.
När jag skapat en lagerstil som är kategoriserad baserad på ett fält i tabellen, kan jag för detta fält använda ”Klassificering” som widgettyp och därmed få en valruta i redigeringsdialogen. Detta gör det väldigt enkelt att redigera värdet för detta fält.
För andra fält kan man skapa en ”värdekarta” med värden och beskrivningar, där beskrivningarna visas i rullningslisten och värdet lagras i tabellen. I Nästa QGIS så kommer man att kunna skapa anpassade val baserat på tidigare gjorda val. Om man exempelvis valt att skapa ett ”kvartersområde” så kan man begränsa valet av användningsområde till enbart de som används i kvarter, och därmed göra urvalet lite snabbare och mindre omfattande.
Vill man inte skriva in exempelvis Beteckningar manuellt, och inte har något emot många attributkolumner så skulle man kunna skapa ett fält för varje beteckning som skall användas (sant/falskt) och sedan bygga etiketter för varje yta med uttryck baserat på detta. Då kan man använda sig av kryssrutor i redigeringsdialogen, vilket gör även detta betydligt enklare.
I kunskapsbanken talar man även om exempelvis illustrationslinjer, måttlinjer med mera. En del av dessa linjer och i något fall punkter, kan sannolikt vara bättre att skapa egna lager för. Att sedan stilsätta exempelvis en måttlinje i QGIS är inte speciellt svårt.
Här har jag bara dragit en linje med snappning aktiverat och sedan klippt den där jag vill ha mått angivna. En enkelt markörlinje med markörer på ändpunkter, en etikett och så är det klart (ursäkta färgbytet i bilden ovan).
När jag tittar på bilden ovan så ser jag ett problem, och det är att gränslinjen ritas ut två gånger. En gång för gatan och en gång för bostadsområdet. Om det är något man bekymrar sig över så går det att lösa det med.
Jag får det inte att fungera med ett virtuellt lager, men det går ju att koppla direkt mot PostGIS via databashanteraren med ett SQL kommando. Då fungerar st_union() som jag förväntar att det skall göra.
Det är fortfarande samma lager och samma data, fast här presenteras det som ett linjelager reducerat till enkla linjer som sammanfaller med polygonernas gränser.
SQL öppnar en helt ny värld med möjligheter för det här ändamålet. Det går att bygga väldigt avancerade uttryck i SQL och låta PostGIS göra beräkningarna först och bara hämta in resultatet i QGIS, som egna separata lager, med olika innehåll och geometri, baserat på samma källdata.
Om jag nu paketerar mina lager från QGIS till ett GeoPackage så skapas detta utan problem, med de data som är ”filtrerade” i projektet. Genererade lager från det gemensamma databaslagret skapas som enskilda lager med den geometri de fått vid genereringen. Det är ingen som helst visuell skillnad mellan dessa genererade data och originaldata i PostGIS. Bara att tillämpa stilen på det nya lagret, spara ner dessa som standard i paketet och kanske skicka med en projektfil med en rapportsammanställning för detaljplanen. Japp, det går ju att skapa kompletta rapporter med texter, bilder och kartor i ett flersidigt dokument direkt i QGIS. Om man vill så kan man skriva hela detaljplanen i programmet, även om layoutverktygen i rapportgeneratorn inte är lika bra som i en ordbehandlare…
Avslutning
Det finns massor med detaljer man måste fånga upp när man skall skapa en detaljplan och jag har absolut inte tagit hänsyn ens till allt det lilla jag känner till, efter att ha skummat igenom kunskapsbanken för Plan och Bygglagen (PBL).
Jag är däremot övertygad om att alla kartor som används i en detaljplan går att skapa och ajourhålla i QGIS med en PostGIS databas.
Om man är lite klok när man skapar sina tabeller och tillhörande lager och stilar i QGIS, så behöver det inte ens bli speciellt krångligt. Åtminstone inte rent tekniskt.
Teknik är bara ena sidan av problemet och man måste även titta på metoder och handledningar för att teknik i kombination med metoder skall göra arbetet så effektivt som möjligt.
Vill man bygga vidare på konceptet med QGIS och PostGIS så finns det mycket som kan göras med exempelvis Pythonskript. Om man har alla detaljplaner i databasen kan man använda Python för att välja vilka som man vill visa genom att ändra filter och urval till lager, om man nu inte vill göra det manuellt. Om man är smart så behöver man nog inte ändra på så många ställen för att välja rätt område.
Rapporter i QGIS 3 är ett för mig outforskat område, men om detta kan användas för hela planen så kan man nog vinna mycket då de kartor som finns med i rapporten är interaktiva och enkelt kan ändras utan att man behöver generera en ny PNG eller SVG i QGIS. Jag tror dock att det är en tillräcklig ambitionsnivå för närvarande, att försöka hantera kartorna i detaljplanen datamässigt i PostGIS och QGIS.