Mappning mellan Boverkets Ändamålskatalog och OSM

Communities Sverige (Sweden)
1

Inget i december, men förhoppningsvis kanske datamängden byggnad går i produktion i NGP i början på året. Men under tiden vi väntar på detta tänkte jag att vi kan påbörja en diskussion om hur vi ska mappa ändamålen från Boverkets Ändamålskatalog till OSM-taggar. Det är de ändamål vi kommer få med från NGP, och även bortsett från NGP så är (Boverkets och Lantmäteriets) tanke att det är dessa ändamål som kommunerna ska börja använda för att klassificera sina byggnader.

För att inte fastna i diskussioner om själva importprocessen tycker jag att vi ska hålla det borta från den här tråden. Vid behov kan vi snegla på vilken mer information vi får med (aktuell informationsmodell för NS/NGP), men i övrigt tänker jag att vi i den här tråden tänker oss bara import i områden där OSM helt saknar byggnader och annan information för att hålla det enkelt.

Första intressanta funderingen blir hur ändamål (oftast närmare relaterat till användning än typ av byggnad) rent allmänt mappar mot OSMs building=*, som ju anger byggnadens typ/karaktär istället för användning. Som ett exempel, om någon bygger om en lada till att vara en restaurang så skulle det enligt ändamålskatalogen vara Verksamhet / Logi och restaurang / Restaurang, men i OSM building=barn (med amenity=restaurant). En lösning är att gå på minsta gemensamma nämnare (building=yes för allt), men det känns synd att förlora mycket information på det viset. Kan därför tycka att det faktiskt kan vara rimligt att likställa användning/ändamål/karaktär vid en mapping (om inte andra taggar redan existerar), då mängden byggnader som ändå får korrekt taggning borde vara flera magnitud större än de som får aningen felaktiga.

Jag har påbörjat en tabell med mappning här, ta gärna en titt vad ni tycker (såklart fritt fram att lägga till och editera, men kan vara bra att diskutera här innan man ändrar något):

https://wiki.openstreetmap.org/wiki/Sweden/Datakällor/NGP_Byggnad

Några ändamål där jag inte kommit på någon passande OSM-tagg:

  • Miljöhus (det som i folkmun oftast kallas sophus/soprum)
  • Förråd för annat än bostäder (där känns building=shed fel)
  • Specialbostäder för äldre, funktionsnedsatta och unga (bara building=residential funkar ju, men finns kanske bättre?)
  • Bussgarage (finns ju building=garages, men utan extra tagg skulle jag anta att den gäller personbilar)
  • Hembygdsgård
  • Fäbod
  • Cistern
  • Kyl- och fryshus

Och några jag känner mig osäker på:

  • Finns det bättre än building=residential för komplementbostadshus (attefallshus)?
  • Finns det taggning för att särskilja radhus och kedjehus?
  • Räknas en tunnelbanestation som en tågstation?
  • Finns det mera exakt för jaktstuga respektive sjöbod än building=hut?
1 Like
2

Bra initiativ. Bare for inspirasjon/referanse, her er tilsvarende tabell (GitHub) som ble brukt for bygningsimporten i Norge (se filen building_types.xlsx).

Basert på erfaringene fra den norske importen vil jeg anbefalt å bare tagge building=*, ikke i tillegg amenity=*, shop=* osv. Grunnen er at 1) det blir duplikate tagger der f.eks. amenity=cafe allerede er tagget på en node, 2) mange bygninger vil ha mer enn én amenity=*/shop=* osv, 3) bygningstypen fra importfilene er ikke alltid helt korrekte/presise.

1 Like
3

Jag skummade lite på Wiki-sidan och reagerade på taggarna till multiarena. De multiarenor som finns i mina omgivande kommuner är inga byggnader utan planer omgivna av en sarg där man kan spela flera olika sporter.

Fäbod har jag taggat med en nod som place=locality med fäbodens namn För byggnader där borde building=yes fungera. Det finns ju undantag, med delvis bebodda fäbodar och stall/kohus m.m., men för det krävs lokalkännedom. Så yes tycker jag är detaljerat nog.

4

Har inte riktigt tid/ork sätta mig in i detta men glatt tillrop ges härmed :+1:. Jag har manuellt klickat ut flera tusen byggnader senaste månaderna och det mesta blir ju bara building=yes, och building=house på småhus (som jag nog överanvänt litegranna på sportstugor).

Om nån bakar till en datakälla/parse-skript av det där så kommer jag använda det.

För att undvika dubbelarbete/divergering skulle jag låta dokumentationen sen vara python-skriptet som genererar en osm-xml utifrån datat.

(Får man bara en osm-xml så kan man hantera den på samma sätt med manuell översyn, sammanfogning och justering som i NVDB-projektet i områden där det redan finns byggnader)

5

Tappade lite bollen på denna, ska försöka plocka upp den igen till helgen.

Utan mycket fanfar publicerade LM förra veckan version 1.0 av specifikationen för Byggnad, vilket innebär att vi även kan börja titta på den.

Intressantast för oss är DPSen: https://www.lantmateriet.se/globalassets/temawebbar/smartare-samhallsbyggnadsprocess/nationella-specifikationer/natspec-dps-t-byggnad-version1.0.pdf

1 Like
6

En också mycket intressant fråga tycker jag är huruvida vi ska ange objektidentiteterna i OSM eller inte (ref:se:ngp:byggnad=<uuid> eller liknande). Fördelen är att det blir lättare att matcha när man ska uppdatera, nackdelen är att det blir ganska mycket extra data i OSM med tveksam nytta (ca 7 miljoner byggnader, ref:se:ngp:byggnad=<uuid> blir 55 tecken, totalt ca 385 MB) och att det kan vara förvirrande för karterare.

Sidnot, i skrivande stund har vi dryga 3 miljoner byggnader i OSM: building | Keys | OpenStreetMap Taginfo Sweden

7

Jag tycker det låter som ett alldeles tillräckligt bra argument :slight_smile:

Sidnot på sidnoten: Åhå, taginfo med landsfiltrering, den kände jag inte till. Mycket användbart :heart_eyes:

8

Hur ska detta användas? Är tanken att man manuellt använder katalogen och lägger in i OSM eller ska man göra en skriptad import? Och i så fall hur hanteras befintliga byggnader, som i många fall har något fel position eller felaktig geometry.

9

Tänker mig att oavsett om manuell import eller (semi-)automatiserad så behöver vi bestämma en mappning från ändamålskatalogen till OSM-taggar.

Vad gäller själva importen föreslår jag att man delar upp det:

Byggnader i NGP som är helt friliggande (d.v.s. ingen annan byggnad i OSM inom X meter och inget överlapp med t.ex. vägar) eller tydligt matchar en OSM-byggnad (t.ex. baserat på IoU-mått)

Kan importeras helt automatiskt, d.v.s. ett skript som översätter från ändamålskatalogen+NS till OSM och automatiskt laddar upp i någon batchstorlek.

Kommer troligen mest handla om landsbygd eller dåligt karterade tätorter.

Byggnader i NGP som inte är friliggande (d.v.s. finns redan byggnad i OSM inom X meter, eller överlapp med t.ex. vägar) och matchar dåligt med OSM-byggnad

För dessa byggnader behöver man dubbelkolla att det är rätt byggnad man avser (t.ex. skulle det på en gård kunna finnas en gård med 3 byggnader varav OSM bara har huvudbyggnaden men den ligger fel så bästa matchen hade varit ladugården i NGP). Dessutom kan man behöva justera kringliggande objekt som vägar eller vatten.

Kan importeras med handpåläggning (likt NVDB-importen), d.v.s. skript skapar upp förändringsfiler som man sedan jobbar med i JOSM.

Övriga byggnader

Kan t.ex. vara fall där vi i OSM har en byggnad men i NGP två (en för bostad och en för garage) eller där man i OSM karterat en hel radhuslänga som en byggnad (eller tvärtom). Kommer sannolikt mest handla om redan välkarterade tätorter.

Kommer som regel behöva mer omfattande handpåläggning, beroende antal fall kan man antingen köra fram JOSM-fil (som i förgående fall) eller kanske använda MapRoulette.

Huruvida en byggnadsgeometri ska ersättas eller inte kan vi titta på koordinatkvalitén i NGP. För byggnader inmätta terrestert (med GNSS eller totalstation) är osäkerheten oftast på centimeternivå och nästan garanterat bättre än vad vi har i OSM. För byggnader inmätta från flygbilder är osäkerheten större, ofta decimeternivå, där ger det nog inget stort värde för oss att ersätta geometrin om den inte avviker signifikant (t.ex. inmät från dåligt inpassad satellitbild) eller saknas detaljer (t.ex. en tillbyggnad inte inmätt i OSM).

Sidnot: Jag hade gärna haft att iD och JOSM tittat på angivna koordinatkvalitéer (vilket det inte finns någon etablerad tagg för) samt underlagsdatum (vilket tyvärr inte finns för de flesta satellitbilder, men finns för t.ex. LMs ortofoton) och varnat om man t.ex. förflyttar en byggnad som anges vara inmätt med bättre noggrannheten än underlaget man aktuellt har tänt. Hade nog löst en hel del av problemet med att någon ritar om efter sämre/äldre underlag.

10

Jag har funderat på detta för NVDB-importen men tror det inte fungerar, då det är många övervägande man måste göra.

Byggnader kanske kan hanteras, men hur ger man ett referensobjekt (byggnad med rätt geometri) till en user som ska gör uppdateringen? Normalt justerar man efter en bakgrundsbild och inte ett separat objekt “på sidan om”. Finns det något teknisk möjlighet i Maproulette för det?

11

Du har säkert tänkt på det, men det är viktigt att inte kasta bort data som finns i OSM. Många byggnader består av flera building:part för 3D-representation, olika taggar på byggnad eller ingående noder där adress, namn, företag eller annat finns taggat.

12

Typ, MapRoulette har infrastruktur för “cooperative tasks”, där man t.ex. kan skicka med föreslagna taggar och geometri. Tanken är bl.a. att man ska kunna jobba med en task först i en mobilapp (t.ex. samla in taggar) och sen från datorn (skissa utifrån satellit) eller tvärtom, men det går även att använda för att skicka med data från externa källor. Dock är det bara JOSM-pluginet för MapRoulette som faktiskt använder och stödjer det idag.

Det går även att “bifoga” underlag till en task i MapRoulette, som då läggs till som ett datalager i JOSM (återigen inget stöd i annan editor).

Så svaret är: “typ, men i praktiken nog inte tillräckligt” (tyvärr)

Dessa skulle nog ofta falla i den tredje kategorin, dock finns det nog även där fall där det går att göra det mer automatiserat (t.ex. om geometrin överrensstämmer tillräckligt och man bara behöver uppdatera taggar).

Huvudregeln för en import lär vara att skippa automatisk import om man inte är hyfsat säker att det blir rätt (men det kan även finnas situationer där det kan vara “värt” att riskera att det blir lite fel om det totalt sett blir bättre).