Jeg har fått godkjent søknaden om å få adressene fra Lantmäteriet og har nå tilgang til alle 3.7 millioner adresser i Sverige. Jeg skrev i søknaden at jeg ville legge inn adressene i OSM.
Jeg har tilpasset importskriptet som har vært brukt i Norge i en del år - det ligger her: addr2osm. Skriptet oppdaterer automatisk alle adresser i landet og kan kjøres så ofte man vil (kjøres en gang i måneden i Norge). Det er normalt over 100k endringer i løpet av et år.
Planen legger opp til at alle adresser legges på separate noder, som er ved hovedinngangen til huset eller ved innkjøringen til eiendommen. fordi:
Dette gir mye bedre routing (man kommer til riktig side av huset/eiendommen).
Mange bygninger har mer enn én adresse, og mange adresser representerer mer enn én bygning.
Andre løsninger vil kreve manuell mapping, men det er ikke mulig holde 3.7 millioner adresser manuelt oppdatert, og neppe overkommelig å legge inn de 3 millioner som mangler manuelt.
Andre features, som f.eks. en butikk, behøver ikke ha adresseinformasjon på samme objekt i OSM fordi koordinatene til butikken allerede stedfester den, og den kan da søkes opp eller navigeres til.
Et sidehensyn er at importen av bygninger vil bli mye enklere å gjennomføre.
I praksis betyr dette at man lar skriptet foreta all oppdatering av adresser fremover, så kan man bruke sin egen tid på annen mapping. Jeg kan forstå at brukere som har lagt ned mye tid i mapping av adresser kan synes at dette er uheldig, men jeg ser ikke hvordan vi ellers kan klare å holde adressene oppdatert.
Vi forsøkte først andre løsninger i Norge, men det ledet til problemer med å matche adresser i OSM og i kildedata, f.eks. når et helt postdistrikt bytter postnummer.
Her er noen filer med eksempler på hvilke oppdateringer som skriptet vil gjøre: Adresser Sverige (velg mappe). Filene viser gamle og nye objekter i JOSM like før opplasting, slik at man kan se alle endringer.
Jag får liiiiite vibbar av “mapping for the renderer” här. En adress tillhör väl hela fastigheten, så en mer exakt ruttberäkning egentligen borde leta “en entrance i inom den yta som har en adress”?
Hur vet skriptet vad som är “huvudingången till huset” så att det kan lägga adressnoden på rätt ställe?
Skriptet bruker bare den koordinaten som Lantmäteriet har gitt. Og koordinaten angir enten riktig inngang til bygningen, eller stikkvei inn til eiendommen. Se eksempel-filene for hvordan LM har gjort dette.
På flerfamiljshus brukar adressen avse en ingång, inte hela byggnaden. (Ibland har jag stött på att adressen avser trappuppgången, där en entre leder till flera trappuppgångar.)
När de gäller friliggande villot på hörntomt kan de ha två olika adresser.
addr:district verkar överflödigt eftersom det aldrig är en del av adressen när den anges. Det har däremot administrativ användning, men då finns det redan geometrier som går att importera som gränser istället för taggar på noder. Se t.ex. i Linköping där jag har importerat distrikten som admin_level=9.
Dette vet dere best, men Lantmäteriet skriver at kommundedel (district) er en del av den formelle adressen i Matrikkelen, og at adressene ikke er unike uten den. Men jeg forstår det også slik at den ikke brukes i praksis når man har med postnummer.
Helt uavhengig av dette tenkte jeg at kommunedel-navnet kanskje kunne være nyttig å ha med i OSM? For eksempel i Stockholm er det 117 forskjellige kommunedeler (district), så dette må være noe annet enn de administrative stadsdelsområdene.
Merk at addr:district her er kommundel, ikke de svenske kirkedistriktene (parish i OSM).
Det är även mycket vanligt att en fastighet har flera adresser (t.ex. flerfamiljshus och större industrifastigheter, men även en del enfamiljsfastigheter (bl.a. min egen, där kommunen någon gång tyckt att gästhuset behöver en egen adress… )).
Sen så är det lite blandat med kvalitén på koordinaten (finns gott om exempel på adresser som avser en byggnad som inte ligger inom eller ens i närheten av byggnaden) så tycker att skriptet bör behålla befintliga koordinater.
Det finns även en hård koppling mellan byggnader och adresser med insamlingsläge byggnad eller ingång (objektet entré i tjänsten Byggnad Direkt) tyvärr saknas den för nedladdningstjänsten om jag uppfattat det rätt.
Har inte läst mig in på allt material så det kanske är besvarat någonstans, men hur hanterar skriptet addr:interpolation=*? Overpass ger mig drygt tusen i Sverige. Helt ärligt skulle jag inte vara emot att sådant raderas när det ersätts med punktobjekt, men det kanske kan få vara en manuell insats efter importen.
Jag har lagt till många adresser manuellt genom åren, men ser inga större problem med att ersätta dessa med en import.
Hur hanteras befintliga adresser som ligger på byggnadspolygoner? Kommer dessa taggar att tas bort?
Archie flyttade för ett antal år sedan en massa namn på byggnader från name=X till addr:housename=X trots att det inte var adresser. DWG lät det rinna ut i sanden. Därför bör inte addr:housename tas bort, men det är säkert inte tanken heller.
Men det här behöver vi ha en diskussion om. Jag är av principiella skäl stark motståndare till att i praktiken låsa data i OSM för att kunna automatisk underhålla den utifrån externa datamängder.
Det här öppnar för att fler datamängder blir låsta framöver: byggnader från LM, vägnätet från NVDB, marktäcke från LM, naturreservat från Natuvårdsverket. Då blir OSM något helt annat, ett OpenImportMap istället, vilket i och för sig skulle vara ett väldigt spännande projekt, men det är inte OpenStreetMap vars idé är att det ska vara en öppen karta öppen för alla att redigera och förbättra.
Jag tror att med importer samt verktyg som exempelvis BästaJävlaKartan kan vi vara bättre än öppna datakällor, för de innehåller också fel.
Jag är enig med detta. Jag har ägnat några veckor nu åt LMs data och jag är inte superimponerad. Visst är den mer komplett, men de saker som väl mappar i OSM håller ofta högre kvalitet och reflektion, särskilt i storstadsområden.
Återigen tycker jag att principen ska vara att vi bara importerar data som inte redan finns i databasen, dvs SAKNADE adresser. Att ersätta befintlig data i OSM med LM vore att sänka standarden.
Och varför ska man få LMs datamängd när man tankar hem OSMs data? Då särskiljer de sig ju inte alls och man kan lika gärna använda LM rakt av?
Däremot låter ju detta som ett fantastiskt verktyg att använda när vi ägnar åt oss adressmapping. Att ha sådana här hjälpverktyg för att få varningar och flaggningar för avvikelser gentemot LMs data tycker jag är toppen! Då kan vi ju försäkra oss om att OSM håller hög kvalitet.
Jag förstår oron men personligen tycker jag att det är fantastiskt att göra en sådan import regelbundet. Jag håller med om att källor som marktäcke är mindre användbara, men i synnerhet adresser är verkligen svåra och tidskrävande att kartlägga för hand och det är en enorm fördel att ha ett stort antal i OSM.
Och (om jag förstår det rätt) skippar scriptet befintliga adresser om de t.ex. har flyttats för hand till en mer korrekt position…
Så även om en person korrigerar data till en ännu “bättre” position så bevaras det.
Jag ser det som att det behöver vara en kombination. BJK, MapRoulette och liknande skulle vara väldigt olämpliga för att importera hundratusentals eller till och med miljontals objekt, men funkar såklart väldigt smidigt för ett mindre antal ändringar som kräver en del manuell handpåläggning.
Bäst tror jag det blir med en kombination där man drar nytta av båda alternativens styrkor - import används för en “grundläggning” nu och för att kontinuerligt lägga till nya adresser, andra verktyg används för att hantera förfining/avvikelser/fall som inte kan hanteras bra av importen.
Men det skapas begränsningar här. Du får inte lägga adressnoden tillsammans med entrén eller på byggnadspolygonen och inte på butiksnoder m.m. trots att det tillåtet enligt nuvarande taggnings-konsensus och är jättevanligt både i Sverige och i världen. Nya användningsområden kanske dyker upp som drar fördel av det. Det är lite det som är OSMs styrka.
Min åsikt är att importer och skript gärna får stödja arbetet i OSM men inte ta över. Exempelvis importera adresser som inte finns och uppdatera postnummer när dessa ändras och skapa valideringsverktyg för att visa och hjälpa till att rätta felaktigheter.
Ja, exakt. Första delen har jag inte problem med alls: att komplettera med saknad data som sedan OSM-användare kan förbättra och förfina. Bra!
Det är nästa steg jag VERKLIGEN vänder mig emot: att månatligen ta bort OSM-data och åter uppdatera med LMs databas. Varför? Då förstår jag inte alls syftet med OSM? Varför ska vi bara spegla en annan databas? Då kan man väl lika gärna använda den istället? Dessutom gör man en mängd antaganden:
att LMs data skulle vara bättre än OSMs. Det tycker jag verkligen inte.
att sättet LM presenterar sin data är den bästa möjliga representationen. Det stämmer inte heller och omöjliggör innovation efter en organiskt framväxande databas som speglar användarnas verkliga behov: exempelvis lokala konventioner osv.
och som @leojth skriver: det öppnar ett sluttande plan. Varför ska vi inte spegla NVDB, SL, SJ, LMs markanvändning osv. Då kan vi lika gärna bygga en stor aggregat-karta. Men är det verkligen OpenStreetMap då? Då blir OSM en databas för programmerare och scripts och inte mänskliga karterare (som är styrkan!)
Nej, enligt förslaget kan inte scriptet skilja mellan “dålig” och “bra” omplacering så “felaktig” (i förhållande till LM) tas bort och ersätts på nytt med LMs variant. Blir då helt onödigt att befatta sig med adresser alls i OSM. De kommer ändå att tas bort.
Addr-tagger på bygningspolygonene blir flyttet til en separat node (inngangen), bortsett fra de addr-taggene som er nevnt i importplanen, som beholdes. Blant annet beholdes addr:housename på polygonet.
Jeg er helt enig. Men la oss i denne tråden diskutere bare hva vi skal gjøre med adressene, siden det ikke er foreslått noen automatisert import for andre av LM’s data. Noen tanker:
Ingen korrekte adresselinjer (innholdet) fjernes fra OSM av importen.
Spørsmålet som gjenstår er da om det er ok å bruke en node i stedet for et polygon, også for å oppnå de fordelene dette gir (routing).
Det kan ta noen år, men det lar seg nok gjøre å importere 3,7 millioner manuelt. Men jeg tror ikke det lar seg gjøre å holde dem oppdatert med over 100k endringer per år (det har vært et årlig snitt i Norge). Dermed behøves det en automatisert løsning.
Når dere ser på LM’s plassering av nodene i eksempelfilene - er det egentlig noe galt her som vi ikke kan leve med? Hvor viktig er det?
Det finnes en opt-out løsning (note) som er beskrevet i importplanen, så spesielle adresser kan holdes utenfor importen.
Husk at langt over halvparten av de svenske adressene i OSM i dag har feil - feil postnummer, mangler postnummer, feil stavet gatenavn, feil gate, mangler bokstav A/B, feil plassering, mangler flere tags osv.
Etter flere år med automatisert oppdatering i Norge har det fremdeles ikke kommet klager, bare et par spørsmål om hvorfor adressene er flyttet noen meter til en separat node.
Kan bara instämma med NKA’s punkter. Det är det sämsta som finns att manuellt uppdatera den här typen av oändligt stor data och allt flyter på perfekt i Norge.
Eftersom vi använder Kartverkets koordinater så har jag även fått utsökt anledning att klaga på vissa kommuners placeringsstandard.
och som sagt, om det som redan ligger inne och är korrekt INTE tas bort, vad mer kan man önska sig?
Den är jag tveksam till. Det finns en rimlighet i det för riktigt stora byggnader (säg >500 m2 i markyta) men för t.ex. vanliga villor tycker jag att det är bättre med addressen på byggnadspolygonen.
Vid import av nya adresser läggs de förslagsvis på byggnadspolygonen om:
Den existerar i OSM,
Insamlingsläge är byggnad eller ingång,
Det enbart finns en adress på den byggnaden, och
Byggnaden är under 500 m2 i area
Annars läggs det som punkt. Existerande adresser bör inte ändras av importen (där kan man diskutera om att generera avvikelser i BJK för att justera åt något håll, men det är out-of-scope för denna diskussion).
En tanke till; för adresser med insamlingsläge ingång och som ligger på (eller väldigt nära) en byggnads ytterkant så bör dessa läggas som punkt som är del av byggnadsgeometrin och som har entrance=yes. Dessa kan jag även tycka är rimliga för mindre byggnader/villor, dock vet jag inte om det är rimligt att göra det som del av en automatisk import eller om det får bli ett manuellt senare steg.
)).