Jeg har tilpasset skriptene som ble brukt til bygningsimporten i Norge slik at de kan brukes for Sverige. Koden er her:
building2osm.py konverterer bygningsfilene fra Lantmäteriet til filer som kan importeres.
Bygningene tagges.
Bygningenes hjørner blir vinkelrette (om ikke avviket er for stort).
Overflødige noder fjernes.
building_merge.py fletter bygningene den konverterte importfilen med bygningene som er i OSM der bygningenes form og.plassering er nær. Dermed blir over 90% av jobben automatisert. Resten flettes manuelt før opplasting.
I denne første versjonen må bygningsfilene lastes manuelt ned fra Lantmäteriet og lagres fra JOSM i geojson-format før building2osm.py kan kjøres. Planen er at skriptet i en senere versjon henter data automatisk fra LM.
Jeg har ikke selv fått tilgang til datafiler fra LM ennå, så skriptene er så langt bare testet på genererte filer som følger LM’s produktdokumentasjon.
Her er også et utkast til import wiki, slik importreglene krever. Metoden og skriptene har vært brukt til å importere 4 millioner bygninger i Norge. La oss diskutere etter hvert som flere får tilgang til filene.
Vi må fremdeles innhente eksplisitt tillatelse fra Lantmäteriet før en organisert import kan starte.
Har inte satt mig in i skriptet i detalj, men en sak jag gissar kommer uppkomma: Hur hanterar den byggnader som är uppdelade i flera i Lantmäteriets data (som går efter s.k. “registerbyggnader”, d.v.s. de är klippta i fastighetsgränserna) men en och samma i OSM (s.k. “fysisk byggnad”). Förekommer bl.a. för radhus.
Tack så väldigt mycket för att du lagt tid på detta. Hoppas licensfrågan löser sig med LM inom kort så att detta kan användas. Ser fram emot en komplett byggmadsimport i Sverige.
Jag börjar läsa igenom Wikin nu med. Återkommer om det är några frågor.
Enligt Wikin ska i alla fall radhus delas på och vara separata byggnader. Det samma borde gälla för lägenhetshus och annat som även de är intill varandra med fastighetsgränser.
Jag skulle föredra ref:lantmateriet:byggnad framför ref:lm_byggnad, både för att undvika förkortningen och för att : är den vedertagna avgränsaren för en subkey
Eftersom förhoppningsvis stora mängder data kan automatiseras (hoppas nog på >90% utanför tätorter och >50% i tätorter) föreslår jag att vi istället för att enskilda personer gör kommun-för-kommun (som vi gör i t.ex. NVDB, där det behövs för att det är nästintill helt manuellt arbete) har följande arbetsgång:
En person kör automatiserad import på de byggnader där så är möjligt i en kommun i testmiljön
Communityt granskar resultatet
Samma person kör samma automatiserade import i vanliga miljön
Communityt granskar resultatet
Samma person (eller mindre grupp, här är mindre varians viktigt) kör samma automatiserade import för resten av Sverige, utspritt över ett rimligt tidsinterval (inte för snabbt för att hinna uppfatta eventuella problem, men det ska inte heller dra ut på tiden), kanske 1-2 månader?
“Restfiler” med de byggnader som inte kunde importeras tas fram och hanteras kommun-för-kommun samma som i NVDB-importen
Hur hanteras ändamål som avviker? Hur hanteras byggnader med flera ändamål?
Hur är det tänkt att hantera befintliga byggnader? Dessa kan vara av olika kvalité. Dåliga kan ersättas av import. Kan nog vara svårt att dra en gräns.
Jeg fikk tilsendt en LM-fil for en kommune fra en i community, så nå er skriptene testet bedre og oppdatert.
Det gjenstår å legge inn litt bedre logikk ved oppdatering av building=* slik at detaljerte tagger i OSM (f.eks. building=cabin) ikke blir overskrevet av mer generelle tagger fra importfilene (f.eks. building=residential).
En sak å være obs på er at identifikatoren fra LM er den samme for grupper av bygninger som ligger inntil hverandre. Har lagt til MULTI=* for å markere dem.
building_merge.py slik den er nå overskriver building=* tag i OSM dersom verdien er en annen enn building=yes (det skyldes at importen i Norge hadde ca 100 forskjellige bygningstyper, mens det bare er 22 fra LM). Der taggene er forskjellige lages det en OSM_BUILDING=* tag for å ta vare på det som var i OSM.
Planen er å tilpasse koden slik at den mest spesifikke building=* taggen beholdes.
Der det er flere ändamål blir den første brukt til taggingen. De andre vises i hjelpetaggen TYPE=*. Man kan søke på TYPE:"," i JOSM.
Update: Skriptet er nå endret slik at building=* tagging i OSM beholdes dersom den er mer spesifikk enn “yes” og “residential” (med unntak av “detached”, som overskriver “house” for frittliggende småhus).
Jag har kollat lite på building_tags.json nu. Skulle det vara möjligt att göra mer specifika taggar av den information som finns från LM? Har några förslag nedan som jag kommit på, kanske är helt ute och cyklar på vissa.
Bostad - Småhus friliggande skulle kunna vara =detatchedi stället. Är det mer korrekt än bara =house?
Bostad - Småhus kedjehus är inte samma sak som terrace enligt definitionen. Den säger att varje hus är fristående med garage eller annan byggnad mellan dem. Ungefär som | hus | garage | garage | hus. Dessa brukar jag inte sätta till =terrace utan snarare =house. Och =garage mellan.
Bostad - Småhus med flera lägenheter är nog inte samma sak som semidetached_house. Vanligt i Sverige för dessa är ex. 2 våningar med en lägenhet per våning samt 3-4 addresser. Typ 31 A-F där A-B-C är nedre våningen och D-E-F är övre. Snarare =residential som skall in här. Minst 3st bostäder i fastigheten också.
Industri - Övrig industribyggnad kan vi verkligen vara säkra på =warehouse? Beskrivningen säger att detta även kan vara reparation, bilförsäljning mm.
Samhällsfunktion - Badhus skulle man kunna lägga till sport=swimming här?
Samhällsfunktion - Ishall skulle man kunna lägga till sport=hockey eller liknande här?
Sammhällsfunktion - Ridhus skulle man kunna lägga till sport=equestrian?
Ekonomibyggnad verkar från beskrivningen inte alltid vara =barn. Kan även vara cisterner, silo mm. Hur hanterar vi det?
Komplementbyggnad denna är också svår. Vi kan inte anta att det är =garage då beskrivningen lika gärna skulle kunna vara =shed (uthus/figgebod/sjöbod), =carport, eller garage…
Efter att ha gjort följande observationer inser jag att det finns några tveksamma sammanslagningar. Men nu får vi ju jobba med den datakvalitét som erbjuds. Jag läste någonstans att antalet definitioner i LM var betydligt lägre i Sverige jämfört med Norge. Och tror detta visar på var begränsningen ligger i användandet av den data som finns.
Men jag ser också att vi importerar building=yeshellre än att tagga fel användning. Så länge vi inte skriver över annan existerande taggning.
Bra kommentarer. I praksis må man se på hvordan de ulike ändamål-kategoriene er brukt i datasettet for å se om én spesiell building=* tag passer best. F.eks. er building=garage og building=warehouse de som viser seg å være mest forekommende i sine kategorier (men så bør det ikke være altfor galt for resten).
Jeg har lagt ut den ene filen jeg har (for Göteborg) i “Byggnader Sverige” mappen. Om man laster inn i JOSM, søker på hver kategori (f.eks. "Småhus kedjehus"), legger inn i To-do plugin og blar seg igjennom et stort antall bygninger med luftfoto som bakgrunn så vil man få et bra inntrykk av hvilken tag som passer best.
Man kan også velge ut et utsnitt av filen, f.eks. 10.000 bygninger, og kjøre building_merge.py for å se hvilke tags som var brukt i OSM (ligger i OSM_BUILDING=* taggen).
Koden gjør noen justeringer:
building=garage og building=barn blir building=shed for bygninger mindre enn 15 kvm.
building=garage blir building=garages for bygninger større enn 100 kvm.
building=barn blir building=farm_auxiliary for bygninger mindre enn 100 kvm.
Noen building=garage er egentlig runde tanker. De bør kunne kjennes igjen ut i fra geometrien og kan få en annen tag. Eller mer generelle tags kan brukes for hele kategorien, men helst ikke building=yes på “alt”.
Men fint om flere kan se igjennom bygningene og foreslå regler for taggingen.
Tack för förtydligande. Jag testade att ladda in Göteborg nu och kolla hur det ser ut. Men skulle säga att det är lite tveksamt med =garage och =garages för komplementbyggnad. Se bild
Det större huset liknar föreningslokal/tvättstuga eller sopstation. De två mindre är förmodligen tillhörande förskolan, typ olika skjul för farvaring av saker/barnvagnar. Samma finns på nästan alla skolgårdar om man kollar run.
Husen på följande bild skulle jag klassa som fristående. Men har här blivit radhus. Dessa är dock markerade som “Kedjehus” enligt LM. Kollar man runt kan man hitta flera liknande exempel. Jag undrar om kedjehus i detta fall är “hus som är byggda exakt likadant men inte nödvändigtvis sitter ihop”. Dvs. samma planlösning men fristående byggnader? Intressant att notera är också de små tilläggshusen som nog är samma byggnad som den större egentligen.
De två markerade byggnaderna längst ned till vänster är båda två lite udda med. På StreetView ser dessa båda ut som transformatorstationer/substation. Men de har olika LM-taggar med. Den ena (höger) “komplementbyggnad” och den andra (vänster) “Ospecificerad samhällsfunktion”.
@NKA som jag uppfattar det går din process fortfarande ut på helt manuellt arbete (d.v.s. att efter skripten körts så behöver fortfarande varje byggnad hanteras manuellt). Jag ser det som helt centralt att vi får till processen så automatiserat som möjligt.
Det finns idag cirka 3,3 miljoner byggnader i OSM, Lantmäteriet har över 8 miljoner. Säg att 1,7 miljoner som saknas i OSM inte kan läggas in automatiskt (för mycket annat som ligger som runt om t.ex.) innebär fortfarande över 3 miljoner byggnader att lägga in. Räknar man ganska snällt på 5 sekunder per byggnad (kopiera → klistra in mellan lager i JOSM) så landar man fortfarande på över 4 000 arbetstimmar.
Det blir med andra ord helt och hållet ohållbart, särskilt eftersom vi redan har en större pågående import (NVDB) och det nu säkert kommer bli fler (marktäcke, adresser, kraftledningar, m.m.).
Ska vi få bäst resultat så är det nog knepigare än så. Tycker att:
Om befintligt är building=yes kan vi sätta utifrån LM
Om befintligt har grov klassning (t.ex. building=residential) och LM säger samma men mer exakt (t.ex. building=detached) kan vi skriva över
Om befintligt är helt annan kategori (t.ex. building=garage) än enligt LM (t.ex building=detached) så kan vi skriva över (särskilt inom primärkarteområde/tätort (där ändamålen är satta utifrån bygglov, och därmed, om man inte gjort något olagligt, alltid stämmer i LMs data))
Tycker att om det är tveksamt är det bättre att sätta en grövre tag (även building=yes). Det är då enkelt att via t.ex. StreetComplete eller en MapRoulette förbättra det, dessutom kommer vi få betydligt mer exakta ändamål när/om NGP börjar fyllas på. Hellre det än att sätta en mer exakt men felaktig tag.
Är också tveksam till att ge sig in på “smarta” regler för att sätta taggar, då blir risken stor att vi spenderar ett år på att justera och diskutera det. Hellre då att göra en import med grövre taggning, och sen följa upp med “finjusteringar” i efterföljande steg (som man då kan göra tagg-för-tagg, t.ex. en för att justera garage utifrån deras form).
Att det går några knappslag snabbare att skriva ser jag som väldigt oviktigt, det är hundra gånger viktigare att det är (hyfsat) tydligt för någon som läser den. Dessutom sätts taggen ju nästintill automatiskt även när man jobbar i JOSM.
Jag tycker det är viktigare att vi får fram filer vi kan börja jobba med manuellt än att ha en helt automatiserad färdig process, om vi ens kommer dit. För mig är det också viktigt att bevara historiken, d.v.s. man justerar befintlig geometri snarare än ersätter den (exempelvis med replace geometry i JOSM).
Nei, det er bare unntakene (feilmeldinger etc) som behandles manuelt, slik angitt i wiki. Da jeg importerte i Norge var ca 5% av bygningene manuelt arbeid. De fleste mindre kommuner tok 1-2 timer hver.
En möjlig approach skulle kunna vara att först fokusera på de byggnader som ändå inte kan importeras automatiskt och göra dem manuellt först. Men jag ser det ändå som extremt viktigt att vi får till en automatisering, utan det så kommer vi inte få till en färdig import.
Håller med, dock är det ju inte så relaterat till om något görs manuellt eller automatiserat (då det i båda fallen går att behålla historiken).
Jag har några obesvarade frågor kring en eventuell byggnadsimport.
Jag har suttit och ritat samt importerat många byggnader i Stockholm. Jag har därmed några frågor kring script och import av tätorter:
Hur hanteras building_passages, rudimentära 3d-objekt (genom building:part), POIs kopplade på building-geometrin, entréer i hus osv.
Sen skulle jag vilja påstå att LMs byggnadsdata inte är överlägsen i många fall. OSMs data är ofta bättre och mer granulär, kanske särskilt i aktivt tappade områden.
Jag skulle nog argumentera för att vi inte börjar med att ersätta massa befintliga byggnader, utan att ett script snarare koncentrerar sig på de saknade byggnaderna. Dvs, att vi endast importerar byggnader som inte finns i OSM. Då minimeras risken för informationsförlust.
Att ersätta befintliga byggnader kommer bli mycket komplicerat, så att man inte raderar/ersätter något som redan är bättre i osm.
Även att addera ej befintliga byggnader, kommer inte vara helt enkelt. Exempelvis i tätbebyggda områden, där vissa byggnader redan är mappade, och som gränsar till ej mappade byggander. Risk för överlappning. Dessutom kan en befintlig byggnads geometri vara så pass fel, att “skriptet” anser att byggnaden inte finns tidigare, och lägger dit ytterligare en byggnad. Kriterierna för detta kanske inte är så enkelt att definiera?
