Sprang på snygga stilfiler för Lantmäteriets vektordata i skala 1:100’000 som jag tänkte göra en bra startkarta med för exempelvis olika fjällaktiviteter. För att ge lite extra dimension åt kartorna vill jag ha med höjdskuggning, så Lantmäteriets öppna data för hela Sverige laddas ner och öppnas. Men…
Här saknas det ju höjddata? Nåja, det visste jag redan, men jag har också blivit uppmärksammad på att det finns höjddata över de saknade områdena under ”hdb” på Lantmäteriets ftp. Så samtliga dessa laddas ner. Men…
Dessa data är i ASCii tabellformat, eller ”xyz” formaterat, vilket ställer till med mer bekymmer.
QGIS, eller GDAL rättare sagt, har stöd för ASCii format och xyz, så det är inte problemet. Nej problemet är att för att GDAL skall kunna hantera formatet så måste data i filerna vara sorterade i en speciell ordning. Först så måste alla Y värden listas i stigande ordning, därefter X. Så ser dessa filer inte ut. När jag försöker sortera om så fungerar det delvis. I stället för ett fel på rad 3 så får jag i stället ett fel på rad 252’002… Dessa filer är på tok för stora att felsöka i.
Nej, det blir till att ta en omväg via vektordata. Filerna läses in som separerad text enligt bilden nedan.
Värden är separerade med mellanslag och decimaltecknet är ett komma. Det finns inga rubriker och importen startar på första raden. Det första fältet är X och det andra är Y. För att värden skall tolkas korrekt så skall även ”Detektera fälttyper” vara ikryssat.
Jag behövde tack och lov inte läsa in alla filer, utan bara de som har data där jag saknar det. Men många punkter blev det i alla fall. varje helt lager har över fyra miljoner punkter, och det är sju lager som behövs. Totalt uppskattar jag det till runt 25 miljoner punkter att hantera.
Det finns ett verktyg för att göra om vektordata till raster, men detta bygger också på GDAL, och hur jag än testar så blir det fel. Det finns dock fler alternativ i QGIS.
Med GRASS kan man köra v.to.rast. Detta tar lite tid att köra igenom, men det enda jag behöver göra förutom att peka ut indata och filnamn som skall skapas, är att se till att rastervärdet som sätts hämtas från det tredje fältet i attributtabellen.
En parameter som var lite dold fanns under de ”avancerade” inställningarna. Det handlar om cellstorleken i det resulterande rasterlagret. Som standard görs en beräkning som väljer en ”lämplig” upplösning, vilket i det här fallet resulterade i 100 m pixlar. När jag ställer in 50 meter, så blir det lite ”hål” i rasterlagret. Det är enstaka pixlar som saknas med ungefär 3850 meters intervall i hela lagret. Det finns dock flera verktyg som enkelt lagar dessa ”hål”, exempelvis GDAL:fixnodata, som återfinns bland processverktygen i QGIS.
Om man kan leva med att det blir 100 meters pixlar så slipper man dels att laga hål, men man kan även köra alla lager i en ”batch” process. Avancerade inställningar är nämligen inte exponerade för upprepade körningar. Det skulle dock gå att bygga en modell med ett skript för allt om man nödvändigtvis vill det. Då kan man ju även lägga till ett steg som lagar eventuella hål.
Att ha samma rasterupplösning är dock nödvändig om man vill använda de ”nya” rasterlagren tillsammans med de gamla i ett virtuellt raster.
Terrängskuggning med alternativet belysning från flera riktningar aktiverat, blandat med bakgrunden med multiply, tycker jag blir riktigt effektfullt på den här typen av kartor.
Så, nu är det bara att vänta in nästa tillfälle att fjällvandra.
Allt som ger oss bättre vägledning till att producera vektor- och rasterkartor i ett digitaliserat plan för att simulera 2,5D och 3D är välkommet och så givetvis detta inlägg. Vi behöver alla denna blogg som draglok, och idag blev det extra bra och relevant – tycker jag! Nu blev det kanske lite väl stora kliv i stegbeskrivningen – såvida man inte är en van qgis-are som kan fylla upp luckorna själv.
För andra gången på kort tid (se https://geosupportsystem.se/2019/05/15/mer-experiment-med-stil-i-qgis/#comment-696) dök namnet GRASS upp, och när jag söker på namnet får jag upp att QGIS ursprungligen togs fram som en visningstjänst för GRASS. Så vad det idag är för skillnad mellan GRASS och QGIS och de praktiska relationerna dem emellan har jag inte fått någon klarhet i – vilket känns lite jobbigt om man t ex ska rekrytera personal för gis-uppdrag. Jag hörde en obekräftad uppgift ifrån en gammal gis-are som sa att med GRASS kan man göra ”allt” – som inte heller kommersiella program klarar av att göra. Om det är så kan man ju fundera vad vi håller på med egentligen…
Om man fastnar i stora 100 meterspixlar blir det dock ett exempel på att ingenting är starkare än dess svagaste länk, då Lantmäteriet när det begav sig med årsaktuella rasterkartor låg på pixelnivåer på 5-10 meter beroende på karttyp. Om målmiljön är Garmin GPS och Android så har kanske någon redan utvecklat ett ”hemligt recept” (kompilerad kod mm) för kommersiella appar för användning i fält så att man kan zooma in utan pixelproblem. Jag skulle gärna vilja och kunna matcha detta med ”Gör din egen zoombara topografiska karta i QGIS för vandring i både skog och mark som i fjällen” som papperskarta och i handhållen enhet. Om man gillar open source för målmiljön är (förstås?) off-linekartor till appen Oruxmaps i Android det givna valet, såvida man inte gör något i webbläsarmiljön och står ut med dess interpreterande. Jag kör själv den ”nästan gratisappen” Locus Map Pro för att kunna lägga på olika lager i vektor- som i rasterformat.
Det är f ö inte så länge sen man släppte in egna off-linekartor i Locus Map, och ihop med den nya autorotationen (norr-söder passning) behöver man inte heller köpa någon dyr bilnavigator då det räcker med den vanliga androidtelefonen med ett extra sd-kort för att lägga sina kartor på. Om dessutom open-source androidappen Oruxmaps kan hantera motsvarande funktioner har vi väl en naturlig (förstaval?) digital målmiljö för QGIS när det gäller handhållet och mobilt.
En pixelstorlek om 100 m kan se bra ut på en på en lågupplöst karta men duger inte för dagens papperskartor och gpser. Pixelstorleken där motsvarar 5-10m och i LMs kso-tjänst som du visar en bild ifrån så har terrängskuggningen en pixelstorlek på 1m. När det är svårt att hantera pixlar om 100m i QGIS hur blir det då när de blir 1m, alltså 10000 ggr fler punkter? Kanske går det att göra tiles som är 10000 ggr mindre och sedan sätta ihop dem till en större karta? Är det möjligt i QGIS?
Lms höjddata med en grid om 1m är inte frisläppt utan kostar mycket pengar. Det som finns fritt har en storlek om 50m och jag antar att det var dem som du laddade ner. Det du visar i översiktskartan är laserdata med 1m upplösning och pixlar med 50m upplösning kan inte ersätta de vita fläckarna i översiktskartan annat än mycket rudimentärt. När jag först såg din bild och att det gick att ladda ner höjddata hajade jag till och en vag förhoppning om att laserdata gick att ladda ner infann sig. Men den grusades snabbt när jag såg vilka data du laddat ner.
De höjddata som jag använt i detta inlägg ÄR från LM öppna data i 50m och ingenstans har jag använt ”kso tjänster”. De bilder som visas i inlägget är helt baserade på öppna data och inget annat. Jag har dock använt mig av ”sub-sampling” med ”bilinjär interpolation” som är en standardinställning i QGIS för rasterdata. Detta ger intryck av högre upplösning och mjukare övergångar, men det är alltså 50 meters data i grunden. De vektordata som visas är som jag skriver LM 100k data (vägkartan + fjällinfo).
Att skapa tiles, eller ännu hellre bygga ”pyramider” med data i en databas är inte bara möjligt utan högst lämpligt. För dessa kartor här så har jag lagrat 50 meters upplösta höjddata över hela Sverige i ett GeoPackage, med tillhörande pyramider som gör att oavsett upplösning så visas data blixtrande snabbt. Paketet är med lämplig komprimering faktiskt bara 1Gb stor. En datamängd som är 10’000 gånger större blir naturligtvis lite mera krävande att hantera men principen är exakt den samma. På jobbet använder vi motsvarande databaser med pyramider där pixelstorleken heltäckande över Sverige är under 0.5 meter utan märkbara problem. Att databasen sedan mäts i terabyte är en helt annan fråga, men det är därför vi har databaser och inte förlitar oss på rent filbaserade lagringsformat som TIF, eller SHP för den delen.
Finns stilfilerna som du använt tillgängliga någonstans?
Japp, nu…
Kolla på https://github.com/klakar/kartografi
Jag har skapat en pull request mot QGIS Sverige på GitHub så vi får se när de dyker upp där.
Vägkartans stilfil tl.qml verkar trasig. QGIS stänger ner.
Någon annan som har samma problem? Det fungerar fint för mig med QGIS 3.8.1 på Linux…
Efter att ha tittat vidare så verkar det som att det står ’GSDText [unknown]’ vara problemet,
ändras det till ’GSDText’ verka det gå bra. (Sedan verkar det som det filen är skapad med tyskspråkig inställning, har inte hunnit kolla om ’Schräggestellt’ och ’Regular’ fungerar med svensk inställning).
I TL-stilen, både qlr- och qml-filen så ställer det här till det:
Först i Typsnittsväljaren:
—-
CASE
WHEN ”KKOD” in (61, 62, 63, 64, 65, 76, 77, 101, 102, 103, 104, 105, 172, 173, 174, 175, 176) THEN ‘GSDText narrow’
ELSE ‘GSDText [unknown]’
END
—-
Jag tog bort ‘ [unknown]’
Vidare i fontstilen:
—-
CASE
WHEN ”KKOD” in (41, 42, 43, 44, 45, 46, 47, 48, 49, 50, 51, 52, 53, 54, 55, 56, 57, 58, 61, 62, 63, 64, 65, 76, 77, 81, 82, 83, 84, 85, 86, 87, 88, 91, 172, 173, 174, 175, 176) THEN ‘Schräggestellt’
ELSE ‘Regular’
END
—
Jag ändrade ‘Schräggestellt’ till ‘Kursiv’ och ‘Regular’ till ‘Normal’ och får inga fel.
Jag har inte kontrollerat om texten presenteras fel.
En annan sak, OH har tyska i beskrivningstexten.
Höhenlinie, Senke och Böschung.
Höjdkurva, Gropkurva och Skärning
Om du kan, gör en pull-request med ändringarna på https://github.com/qgissverige/kartografi/tree/master/vagkartan