I förra veckan sneglade jag lite på detaljplaner och PostGIS och ett av de grundläggande problemen var att använda så få dataset till så mycket informationslager som möjligt, utan att informationen krockar och överlagras. Mycket information i planerna är linjer, men det är i många fall smidigare att registrera dessa som polygoner. I detta avsnitt tänkte jag mera systematiskt titta på vilka möjligheter vi har med olika ”st” kommandon i PostGIS.

För mina tester skapar jag en väldigt enkel polygon delad i ett rutnät, där tabellen i huvudsak har två numeriska fält (typ_a och typ_b).

I QGIS delar jag upp värdet i de båda fälten så att jag kan göra indelningar i såväl typ_a som typ_b på olika sätt.

Om jag vill rita ut den omgivande kantlinjen runt alla ingående, men sammanhängande polygoner så går det inte med QGIS stilar. Men ett virtuellt lager skulle fungera, vilket använder sql, men beräkningen görs i QGIS. Genom att använda DB Manager så kan jag skicka ett sql kommando till PostGIS databasen där beräkningen görs och jag får bara resultatet. Det första är smidigt, speciellt med lokala data, men om det exempelvis är en begränsning i nätverkets överföringshastighet så är DB Manager bättre. Många kommandon stöds heller inte i virtuella lager och i många fall går det snabbare på en dedikerad databasserver. Jag kommer därför enbart att presentera kommandon på detta vis, men mycket av det som presenteras går som sagt att skapa även med virtuella lager direkt mot lokala lager i QGIS.

I bilden ovan har jag skapat ett enkelt SQL-kommando i DB Manager (klicka på andra knappen från vänster i DB Manager).

SELECT st_union(geom)
From "Detaljplan"."test_tabell";

Detta slår samman alla geometrier i tabellen ”test_tabell” i schemat ”Detaljplan”. Resultatet laddas in i QGIS som nytt lager och här behöver man först välja geometrikolumn och ge lagret ett namn innan det går att läsa in resultatet. Rutan stängs sedan inte, så nu kan jag dels spara frågan till senare tillfällen, eller modifiera den och köra igen.

Om jag inte vill ha en polygon, utan endast en gränslinje så modifierar jag uttrycket något.

SELECT st_boundary(st_union(geom))
FROM "Detaljplan"."test_tabell";

I många fall är det just kantlinjen jag är ute efter och detta ger mig just det resultatet.

Om jag i stället vill ha kantlinjerna runt alla områden indelade efter ”typ_a” så blir uttrycket lite längre.

SELECT st_boundary(st_union(geom))
FROM "Detaljplan"."test_tabell"
GROUP BY "typ_a";

Detta gör samma sak som tidigare, men grupperar först alla objekt efter värdet i kolumnen ”typ_a”. Här introduceras två problem.

1. Kantlinjen runt hela polygonen är med, vilket kanske inte är önskvärt.
2. Det är dubbla linjer mellan områdena, vilket gör en del stilar svåra att använda på ett snyggt sätt.

Vi tar problem 1 först. Det kan fixas med lite ”algebra”. Yttergränsen är ju redan beräknad, så det borde gå att ”ta bort” den från det nya resultatet. Det går att göra med st_difference.

SELECT st_difference(typ_a.geom, hela.geom)
FROM
(SELECT st_boundary(st_union(geom)) AS geom
FROM "Detaljplan"."test_tabell") AS hela,
(SELECT st_boundary(st_union(geom)) AS geom
FROM "Detaljplan"."test_tabell"
GROUP BY "typ_a") AS typ_a;

Det nya SQL kommandot är i grunden ett st_difference som tar två geometrier som argument. Dessa är här angivna som två alias som sedan definieras i FROM med varsin parentes där de ”döps” med AS.

Varje SELECT i FROM satsen måste dessutom ges en alias för att st_difference skall kunna hämta resultatet. Det görs genom AS geom för båda.

St_difference tar nu resultatet med alias typ_a och presenterar det som skiljer sig från resultatet med alias hela.

Men vi har fortfarande problem 2 att fixa, eftersom det är många sammanfallande linjer i resultatet (vilket inte direkt syns i bilden ovan).

Jag har i uttrycken nedan dessutom valt att lägga till en alias för den utvalda geometrin med AS geometri för att göra min egen hantering lite enklare, men det är inte nödvändigt så länge man är noga med att kontrollera att man använder rätt geometrikolumn när man lägger till sina lager från DB Manager.

SELECT st_unaryunion(st_collect(st_difference(typ_a.geom, hela.geom))) as geometri
FROM
(SELECT st_boundary(st_union(geom)) AS geom
FROM "Detaljplan"."test_tabell") AS hela,
(SELECT st_boundary(st_union(geom)) AS geom
FROM "Detaljplan"."test_tabell"
GROUP BY "typ_a") AS typ_a;

I uttrycket är två saker tillagda. St_collect som tar alla geometrier och returnerar en ”samling” med geometrier, som sedan st_unaryunion sammanfogar till ett enda linjeobjekt utan överlappande geometrier.

Detta introducerar dock ett nytt problem, nämligen att det är ett multipart-objekt, så stilsättningen ser lite konstig ut på sina ställen med långa linjer eller oregelbundna intervall. Detta kan i och för sig lösas med en geometrigenerator i QGIS (line_merge()), men det går även att göra ytterligare ett tillägg till SQL-kommandot.

SELECT st_linemerge(st_unaryunion(st_collect(st_difference(typ_a.geom, hela.geom)))) as geometri
FROM
(SELECT st_boundary(st_union(geom)) AS geom
FROM "Detaljplan"."test_tabell") AS hela,
(SELECT st_boundary(st_union(geom)) AS geom
FROM "Detaljplan"."test_tabell"
GROUP BY "typ_a") AS typ_a;

Den enda skillnaden mot tidigare är att det dessutom finns ett st_linemerge() kommando som omsluter urvalet.

Om nu detta var allt jag ville få fram så borde jag vara klar. Men det är nu det börjar krångla till sig på riktigt.

Jag kanske dessutom vill ha ett lager med gränser även för typ_b, där dessa inte sammanfaller med gränser i ytterkant eller mellan typ_a områden.

Jag vill ha:

• Ytterlinjer för sammanfogade typ_b områden,
• som inte sammanfaller med ytterlinjer för typ_a områden,
• eller yttergräns.

Den sista punkten kan jag bortse ifrån här då jag kan använda hela typ_a gränserna och inte bara de som ligger mellan typ_a områden. Sedan borde det gå att skapa ett nytt uttryck liknande det ovan, om än lite krångligare.

Ett lager motsvarande typ_a fast för typ_b är inte så svårt att skapa, men för att belysa problemet ytterligare så redigerar jag värdena något i databasen.

Resultatet ovan är från en kopia från tidigare kommandon för typ_a men där referenser ändrats till att grupperas efter värdet i fält typ_b. Ytterlinjerna är borta, men jag skulle vilja att även linjerna mellan typ_a områden skulle försvinna… Vilket visat sig vara lite krångligare att få till.

SELECT st_linemerge(st_unaryunion(st_collect(st_difference(typ_b.geom, typ_a.geom)))) as geometri
FROM
(SELECT st_linemerge(st_unaryunion(st_collect(aa.geom))) AS geom
FROM
(SELECT st_boundary(st_union(geom)) AS geom
FROM "Detaljplan"."test_tabell"
GROUP BY "typ_a") AS aa) AS typ_a
,
(SELECT st_linemerge(st_unaryunion(st_collect(bb.geom))) AS geom
FROM
(SELECT st_boundary(st_union(geom)) AS geom
FROM "Detaljplan"."test_tabell"
GROUP BY "typ_b") AS bb) AS typ_b;

Jag tvivlar på att det måste bli så krångligt som mitt SQL-kommando är ovan, men jag var tvungen att förenkla de båda gränserna för typ_a och typ_b så att de var singelgeometrier och endast ett objekt per geometri. Detta gjorde jag genom att använda de st kommandon som jag använt tidigare och bädda in dessa i varandra i två steg. Först därefter lyckades jag isolera endast de unika gränserna för typ_b.

Nu kan jag däremot skapa lager för enskilda polygontyper i QGIS och med SQL kommandon hämta enskilda unika gränser som inte överlappar varandra, utan att ha skapat ytterligare tabeller i databasen.

Ändrar jag något i ursprungstabellen, geometri eller fältvärde, så behöver kartan bara uppdateras så kommer alla lager att anpassas till de nya förutsättningarna.

Sedan kan jag kombinera detta med andra SQL lager, eller inbyggda funktioner i QGIS för att ytterligare bygga lager som ändå bara har ett enda polygonlager som källa, så länge geometrierna sammanfaller med det jag är ute efter.

Jag kanske bara vill ha gränser typ_b i ytor av typ_a men en annan markering av ytor med värdet ”3,1”. Då kan jag slänga in en WHERE i SQL kommandot för typ_b gränser och ett enkelt virtuellt lager för ”3,1” ytorna är lätt att fixa.

Om man inte vill ha gränser så kan man bara utelämna st_boundary i kommandona. Ja det kan bli lite krångligare än så eftersom man byter geometri, men kommandot totalt lär bara bli enklare. Väldigt mycket av dessa polygoner går dessutom ganska enkelt att skapa med virtuella lager i stället för med SQL.

select typ_a, st_union(geometry) from test_tabell group by typ_a;

Om du som här bygger upp ett projekt med flera lager som hämtar information från samma källa, så kan det hjälpa att ställa in databeroenden.

Ett SQL lager kanske skall uppdateras automatiskt om det ursprungliga ”rådatalagret” redigeras. För varje lager kan man i lagerinställningarna ställa in så att QGIS håller koll på dessa lager och automatiskt uppdaterar lagret om det sker en förändring.

Sent tillägg

Om du har data för flera områden i en och samma tabell, men vill kunna välja ut endast de data som finns exempelvis i ett specifikt område, då kan du använda fler ”st” kommandon.

Data är här lagrat i tabellen ”test_tabell” och för att testa så skapas ett polygonlager till vid namn ”region”.

Det går att skapa virtuella lager där data från test_tabell (B) som har en geografisk relation till polygonen i regiontabellen (A).

SELECT B.* FROM A, B WHERE st_contains(A, B)
SELECT B.* FROM A, B WHERE st_intersects(A, B)
SELECT B.* FROM A, B WHERE st_overlaps(A, B)

Resultatet från st_contains() är alla polygoner som helt ryms innanför regionen. För st_intersects() är det alla objekt som med någon del rör vid regionen, och för st_overlaps() är det objekt som delvis täcks av regionen.

Det går även att baka in dessa kommandon i befintliga SQL kommandon direkt mot PostGIS.

Ovanstående är ett enkelt exempel från artikeln, medan övriga uttryck blir något mer omfattande. Det går dock att modifiera alla SQL-lager så att de anpassas efter formen på ett ”regionlager”.

Detta tillägg är främst med anledning av en fråga om just geografiska urval i PostGIS jag fick från Norge nyligen, och det passade bra att lägga in detta i denna sedan tidigare planerade artikel.

Avslutning

Detta inlägg har hjälpt mig att få lite bättre ordning på några av alla st kommandon som finns för databaser. Det är mycket kvar innan det är helt solklart, men varje gång jag sätter mig ner och samtidigt skriver ner lite så blir det tydligare (och enklare att återskapa).

Jag hoppas att du som läser detta också tycker att det blev lite tydligare och att du kan ha användning av dessa kommandon.

Nyhet från Geosupportsystem , orginal inlägg

If you are a MacOS QGIS user, you are probably bothered by some MacOS specific bugs. These are due to the fact that we have fewer QGIS developers working on the MacOS platform and there are additional MacOS specific issues in the underlying qt5 library.

Nevertheless, we found a developer, Denis Rouzaud, who wants to specifically look into investigating and hopefully solving several of these issues. If you are a MacOS user and care about a better QGIS experience on this platform, we invite you to financially support this effort. As a private person, and for smaller amounts, please use the usual donation channel – if you are a company or organization and want to contribute to this specific effort, please consider becoming a sponsor. In any case – please add “MacOS bug fixing campaign” as a remark when donating/sponsoring or inform [email protected] about your earmarked donation.

This effort runs from the 14th September 2018 until the 3.4 release date, due on October 26, 2018. See the QGIS road map for more details about our release schedule.

Specific issues that are looked into, are:

issue	priority	subject
11103	1	Support for retina displays (HiDPI)
17773	1	No Retina / HiDPI support in 2.99 on osx
19546	1	QGIS 3 slow on macOS at high resolutions
19524	1	[macOS] Map canvas with wrong size on QGIS 3.2.1 start up
19321	2	Map Tips on Mac doesn’t display the content correctly
19314	1	3.2 crashes on startup on a Mac
19092	2	Measure tool on a Mac uses the top right corner of the cross hair cursor instead of the centre
18943	3	QGIS Server on MacOS X High Sierra
18914	3	[macOS] Plugin list corrupted by wrongly placed checkboxes on Mac
18720	2	QGIS 3.0.1 crashes on Mac
18452	3	Snapping options missing on Mac
18418	2	Scroll zoom erratic on Mac trackpad
16575	3	QGIS 2.18.7 crashes on macOS 10.12.4 when undocking the label panel
16025	2	[macOS] Control feature rendering order will crash QGIS
3975	2	PDF exports on OSX always convert text to outlines

Thank you for considering to support this effort! Please note that some issues may also exist due to up-stream issues in the qt library. In such a case, it can’t be guaranteed if and how fast, such an issue can be fixed.

Andreas Neumann, QGIS.ORG treasurer

Nyhet från XXXXXX, orginal inlägg

I detta inlägg använder jag ett punktlager med mätvärden för att ”interpolera” en sammanhängande yta som visualiserar dessa värden. Interpolering är ett sätt att räkna ut värden där dessa saknas baserat på de värden man har. Olika metoder använder olika algoritmer för att göra uträkningen och i olika situationer passar dessa olika bra.

Jag kommer att använda temperaturdata från SMHI (CC-BY) som går att hämta från deras sida för öppna data (http://opendata.smhi.se/). Det går att använda vilka typer av mätvärden, eller punktobservationer som helst, men dessa passar ganska bra som demonstration.

Mera konkret hämtar jag en sammanställning av den senaste timmens temperaturer från alla mätstationer i en csv-fil via den här länken.

Dessa data läser jag sedan in i QGIS via den vanliga ”separerad text” funktionen.

På kartan får jag ett antal punkter som kan stilsättas precis som vanligt i QGIS, men jag nöjer mig med att använda en etikett som anger aktuell temperatur på mätplatsen.

Nästa steg är helt enkelt att skapa en interpolering med något verktyg. Jag har dock inte lyckats göra detta på det här csv-lagret, och jag vet inte vad det beror på, men om jag först exporterar lagret till ett GeoPackage så går det bra.

QGIS har två inbyggda funktioner för interpolering, IDW och ”TIN”. IDW står för ”inverse distanse weighting”. Med denna metod beräknas ett värde för varje punkt baserat på de värden som existerar i de angivna kända punkterna.

Det finns begränsade inställningsmöjligheter med i Wikipedia så förklaras ett värde, som baserat på resultatet i QGIS även är det som går att ange här. Här får man experimentera lite och jag har hamnat någonstans mellan 2 och 4 när jag provat med temperaturdata.

I dialogen väljer man vektorlager och det värdefält som skall interpoleras. Detta ”lägger man till” i listan med det gröna ”plus-tecknet”. Antalet rader och kolumner går att anpassa till formen för observationsområdet och tänkt upplösning. Ju högre värden desto tätare pixlar. Man måste även ange utsträckningen, men det går att ange ett lagers utsträckning, eller markera i kartbilden, så det är inte speciellt krångligt.

Om man vill spara resultatet till en fil så kan man göra det, annars sparas resultatet i minnet som en temporär fil.

TIN interpolering (”triangular irregular network”) fungerar liknande, men ger ett lite annorlunda resultat.

Här kan man välja en av två metoder, med viss variation i resultatet. Man kan även välja att visa det trianguleringsnät som räknats fram, och som ligger till grund för beräkningen.

Det finns andra verktyg i SAGA eller GRASS, men jag nöjer mig med mitt IDW resultat. Det är trots allt metoder jag vill visa.

Man kan nu använda sig av kreativ stilsättning i QGIS och vara nöjd så här långt, men det finns sätt att gå vidare.

Ett exempel är höjdkurvor.

Höjdkurvor behöver ju inte bara beskriva höjd! Det går lika bra att som i det här fallet knyta ihop områden med samma temperatur.

Här byter jag helt enkelt ut attributnamnet HOJD mot TEMP, bara för att inte själv bli förvirrad. Annars är det ingen som helst skillnad att skapa linjer av den här typen eller höjdkurvor.

Genom att laborera med intervall och offset så kan man nog få till ganska ”trevliga” linjer för kommande kartprodukter.

Det finns säkert många fler sätt att göra om oregelbundet utspridda mätpunkter till yttäckande data, men de som finns inbyggda i QGIS räcker nog ganska långt.

Oavsett om det som här är temperatur från SMHI, eller egna insamlade data om luftkvalité, eller markens surhetsgrad på en fastighet, så kan man tillämpa metoden för att ”interpolera” värden där dessa saknas. Man måste naturligtvis vara noggrann med att tala om att interpolering är gjord, och det bör gå att spåra vilka mätpunkter som använts, med vilka värden, på ett eller annat sätt. Speciellt om det rör sig om en vetenskaplig rapport eller motsvarande.

Nyhet från Geosupportsystem , orginal inlägg

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.

Nyhet från Geosupportsystem , orginal inlägg

Jag spelar inte mycket på PC, eller alls för den delen. Men när Valve släpper ”Proton” för Steam så måste jag testa. Det är ju dessutom fredag!

Proton är helt enkelt ett kompatibilitetsläge för Windowsspel på Steam, så att dessa går att köra direkt på Linux!!! Om allt fungerar så kommer detta i ett slag att göra många tusen ytterligare spel tillgängliga på Linux.

Det är många som säger att de inte kan byta till Linux av olika skäl. Ett av dessa är att deras spel inte finns till Linux. För de spel som finns på Steam, så kan detta hinder nu helt blåst bort!

Jag är som sagt inte en storspelare, men jag kommer ihåg när jag spelade Sim City när jag var yngre, så det passar jag på att köpa via Steam för att prova.

Proton aktiveras genom inställningarna i Steam där man först går med i betatestningsprogrammet (Proton finns för närvarande bara som beta), och sedan aktiverar man Proton under SteamPlay.

Detta gör att alla spel kan installeras, men det är inte 100% säkert att det fungerar lika bra som på Windows.

Installationen förflyter helt utan problem, och det är ingenting som antyder att detta spel egentligen inte är för Linux (endast Windows och MacOS).

När spelet är installerat är det bara att starta precis som vanligt. Det enda som dyker upp är en ruta som talar om att man startar med ”Steam Play”.

Sedan är man igång! Inte direkt 4K upplösning i det här gamla spelet, men det fungerar! Utan problem i Linux!

Jag hade tänkt att även ladda hem och prova ett nytt spel. Det jag hittade som var ”free to play” som jag valde att installera heter ”Runes of Magic” och finns enbart till Windows. Nytt och nytt är relativt, då spelet släpptes 2009, men först nu släppts till Steam. Men dra åt… nästan 12 Gb att ladda hem???

Nåja, det går utmärkt att installera och spela det här med. Men kan jag inte hitta något… mer modernt, som inte kostar skjortan? Det är ju trots allt bara ett test. Det behöver dessutom vara ett spel för bara Windows! De flesta Free to play finns även för Linux…

Det får bli ”Climb”. Ingen aning om vad det är, men det verkar som att det är ett plattformsspel där man spelar mot andra och den som träffar lavan sist vinner?

Inga problem här heller!

Om man vill vara säker på att en titel fungerar med Linux så finns det ett antal som är ”officiellt” supportade av Valve. Det finns även en lista där användare själva testar och rapporterar vilka som fungerar.

Så… De som inte kan byta till Linux på grund av spel, åtminstone via Steam, har ingen ursäkt längre.

Vad kommer härnäst? Microsoft och Adobe på Linux?

Själv har jag faktiskt provat att installera en del Esri mjukvara på Linux via Wine, med blandat resultat. Det mesta fungerar, men man får prova en hel del i inställningarna. Även med Proton så finns Wine i bakgrunden, men Valve har gjort alla inställningarna åt dig för titlarna. Dessutom finns det översättningar från exempelvis DirectX till Vulkan, vilket gör att alla titlar som kräver DirectX i teorin borde fungera även på Linux. Teori och praktik är däremot en relativ fråga. Glöm inte heller att Proton är en beta i Steam.

Nej, nu skall jag testa ”Cuisine Royale” på Steam via Proton…

(EDIT: Cuisine Royale fungerade inte! Det finns ett ”anti fusk läge” i spelet som inte stöds av Proton. Det är samma sak med andra typer av ”skydd” som exempelvis DRM.)

Nyhet från Geosupportsystem , orginal inlägg

Något dold kanske, men en ack så användbar funktion i QGIS, när man skall skapa flera likadana kartor över flera platser eller objekt. Jag talar om ”kartböcker” eller i vissa sammanhang ”Atlas”.

I detta inlägg blir det en snabbintroduktion till hur du skapar dessa i QGIS och jag tittar närmare på ett praktiskt exempel.

Kartböcker är en funktion i layouthanteraren. Genom att använda sig av ett ”indexlager” så skapar funktionen en sida baserad på aktuell layout, för varje objekt i indexlagret.

Indexlagret kan vara vilken typ av vektorlager som helst och det allra enklaste är väl att ta ett lager med orter eller platsnamn och helt enkelt använda detta som indexlager i en kartbok, så det testar jag först.

Jag använder ett punktlager med kommunnamn (terrängkartan at) för detta och lantmäteriets WMTS tjänst som bakgrund. Lagret har 147 punkter, vilket nog är mer än vad man vill använda, men det skall nog fungera ändå.

Jag börjar med att skapa en superenkel layout med en karta och en titel. Sedan behöver jag definiera mitt indexlager, vilket görs i en kartbokspanel som aktiveras med knappen ”Atlas Settings” (Kartboksinställningar).

Här kryssar man i att man vill generera en kartbok (Atlas) och väljer vilket indexlager som skall användas för detta. Om man inte vill att indexlagret skall synas så kan man kryssa i att det skall vara dolt.

Det finns sedan möjligheter att filtrera och sortera indexlagret om man vill det, men jag väljer att bara välja attributet ”text” som mitt bladnamn.

Om man vill exportera hela kartboken som en fil i exempelvis PDF så finns det ett alternativ för det (standard) och man kan även välja bildformat för export av kartboken som bilder. Om du vill exportera varje sida för sig som PDF, så tar du bort krysset och då kan du ange vilken metod som skall användas för att döpa varje fil.

Det som sedan återstår är att aktivera att kartramen i layouten skall kontrolleras av kartboken. Beroende på vilket typ av vektorlager indexlagret är så får man sedan lite olika alternativ för inställning av skalan på varje blad. För punktlager så är det endast fast skala som gäller.

För att titeln skall ändra namn mellan sidorna så använder man sig av den inbyggda variabeln @atlas_pagename.

14Sedan är det bara att aktivera förhandsgranskningen av kartboken (knappen till vänster ovan) och välja eller bläddra mellan sidorna för att se att det ser bra ut. När man är klar så skriver man ut eller exporterar kartboken till fil.

Attribut i indexlagret kan användas till mycket mer i layouten. Det finns inbyggda funktioner för exempelvis sidnummer men det går även att hämta andra värden från tabellen och använda dessa i andra sammanhang i layouten där uttrycksbyggaren går att använda.

Du kan exempelvis ha en sökväg till en bild i ett attribut och använda denna sökväg för att placera en unik bild på varje sida.

Generera indexlager

Om du inte har ett lager som kan vara ett index, så är det inte så svårt att skapa ett just för den kartbok du vill ha. Vet du vilken skala du vill ha så behövs bara ett punktlager där du anger centrumpunkten för varje kartblad.

Vill du däremot skapa en kartbok över ett område eller längs en linjesträckning, så får du först generera ett indexlager med någon av de inbyggda funktionerna i QGIS.

Jag tänker skapa en kartbok längs ån Lagan och jag använder SMHI Nätverksbildande vattendrag från Geodataportalen för att välja ut detta vattendrag och skapa ett lager att utgå ifrån.

För att skapa mitt indexlager så behöver jag först veta hur stor utsträckning varje kartblad kommer att ha i meter. Det tar jag reda på i layouten som måste skapas först. Det går inte att ändra kartans storlek i layouten i efterhand, utan att det påverkar täckningen totalt, detaljer är dock inga problem att ändra, så länge kartelementets storlek förblir oförändrad. Om man vill ha exakt matchning mellan kartbladens utsträckning så väljer man exakt det antal meter som kartans utsträckning har i layouten, men om man vill ha lite överlapp så använder man ett lite mindre mått. Du använder kartelementets ”extent” för att enkelt räkna ut utsträckningen.

Det kan finnas andra sätt, men jag använder funktionen ”skapa rutnät” i QGIS för att generera ett indexlager. Utsträckningen begränsas av mitt vektorlager där enbart Lagan är med (välj att använda lagret för att generera utsträckningen) och jag skriver in vertikalt- och horisontellt intervall i dialogrutan.

Det räcker att skapa ett temporärt lager så länge, eftersom jag behöver redigera de genererade rutorna då jag inte behöver ha med rutor som inte täcker vattensträckningen.

Utgångsläget för genereringen av rutnätet med denna metod är i vektorlagrets utsträcknings övre vänstra hörn, men det är enkelt att redigera lagret, välja alla objekt och flytta dessa så att man får en lämplig sidindelning. Sedan är det bara att radera de rutor som man inte vill ha med och spara resultatet i ett GeoPackage som indexlager.

Vill man sedan använda lagret för att döpa eller sortera sidorna, ange sidnummer eller liknande, så får man redigera attributtabellen och lägga till fält för detta. Jag nöjer mig att skapa en sidnumrering från flödets början till dess slut.

Lite mer ”styling” av lager och skapande av två olika teman för mina två kartor i layouten, så blir det ungefär som i bilden ovan. Huvudkartan är kontrollerad av kartboken och indexkartan är det inte. Där har jag i stället valt att visa indexlagrets utsträckning med sidnummer och sedan markeras det aktuella bladet som en ”översikt”.

En och samma layout kan på detta sätt generera en stor mängd kartor baserat på ett enda indexlager.

Nyhet från Geosupportsystem , orginal inlägg

Att georeferera är en process i ett GIS där man tar en kartbild som saknar en digital geografisk referens och skapar en sådan, så att kartbilden kan visas korrekt tillsammans med andra data i programmet.

Här hämtar jag en bild från Internet (public domain från wikipedia) som visar gamla stan i Stockholm.

Din bild kan vara i princip vad som helst, men ju mer referenspunkter från bilden du kan återfinna i ditt GIS, desto bättre.

Innan du börjar så skall du undersöka om det kommer att underlätta om du väljer en specifik kartprojektion för georefereringen. Ju mer ”formen” på kartobjekten i bilden överensstämmer med det som visas i QGIS, desto enklare blir refereringen. I det här fallet så är området så litet och ”plant” att SWEREF99TM duger gott.

Jag startar ett projekt med en lämplig bakgrundskarta och panorera till ett område som ungefär motsvarar bilden. Tänk på projektet måste (bör) vara i det koordinatsystem som skall användas för bilden.

För att referera bilden kan du behöva aktivera ”GDAL Georefererare” i pluginhanteraren. När du gjort det så har du ett nytt menyalternativ i rastermenyn. När du klickar på ”Georefererare…” så öppnas ett nytt fönster där du kan lägga till bilden. Välj här samma koordinatsystem som i projektet så blir det lite enklare att hålla koll på vad som händer.

Nu skall du markera överensstämmande punkter i bilden i georefereraren och i kartan i QGIS kartfönster. Detta gör du genom att lägga till punkter i bilden med ett klick, vilket öppnar en liten dialogruta där du antingen kan skriva in en koordinat, eller välja ”Från kartbladet”. Om du väljer ”Från kartbladet” så växlar programmet till kartan i QGIS där du kan leta reda på aktuell referenspunkt och klicka där. Du bekräftar med ”OK” i den lilla dialogrutan.

Både i georefereraren och i kartfönstret går det att zooma och panorera precis som vanligt för att mera noggrant markera samma punkter.

Ju fler punkter du kan hitta som överensstämmer och ju bättre spridning dessa har över bilden, desto bättre blir resultatet. Fler punkter innebär även att fler typer av bearbetningar blir tillgängliga.

När du har en bra uppsättning punkter kan du ändra transformationsinställningarna. Genom att välja olika transformationer så kommer du att få ett värde på uppskattat ”fel” som beräknas för varje punkt (dX, dY). Litet fel är bättre än stort, men mer avancerade transformationer förvränger också bilden mera. Här kan du få testa lite och tipset är att välja en så ”enkel” transformation som möjligt till att börja med.

När inställningarna är klara så kan du prova att köra georefereringen och lägga till resultatet i kartan. Detta går att göra genom att kryssa i en ruta i dialogen (bilden ovan) innan du klickar på OK och sedan kör processen.

Kontrollera resultatet, exempelvis genom att lägga lite transparens på bildlagret, eller växla synligheten genom att tända och släcka lagret.

Om något inte riktigt stämmer så tar du bara bort lagret, går tillbaka till georefereraren och justerar punkter eller lägger till flera. Du kan även prova att byta transformationstyp, sedan kör du processen igen.

Resultatet skrivs till en GeoTiff, men du kan spara lagret i vilket format du vill från QGIS när du är klar. Högerklicka på lagret i lagerlistan och välja ”Exportera” och ”Spara Som…”.

Raster i GeoPackage

Här kan du även välja att spara i exempelvis GeoPackage om du vill det.

Det går att lägga till lagret i ett befintligt GeoPackage, men det är lite krångligare. Du måste nämligen skapa två extra ”inställningar för skapande”, för att inte skriva över information som redan finns i paketet.

De parametrar som skall läggas till är:

APPEND_SUBDATASET   YES
RASTER_TABLE Lagernamn

Validera dina inställningar med knappen under listan. Tänk på att lagernamnet inte får innehålla mellanslag.

Detta gör att ett GeoPackage kan innehålla flera lager, som dessutom kan vara av helt olika typ. Om du har problem med exporten så beror det sannolikt på att din GeoTiff är ett raster i tre band. Välj bara att ”rendera bilden” i dialogen för export så kommer det att fungera (även transparens renderas till resultatet). Det går även att bygga pyramider i paketet, men det går att lägga till dessa i efterhand om det skulle behövas.

Det hade varit önskvärt att dessa två parametrar kunde finnas med som ett förval bland övriga profiler i dialogen för att underlätta hanteringen av raster i GeoPackage. Men det skall vi nog se till att fixa till kommande QGIS versioner.

Nyhet från Geosupportsystem , orginal inlägg