Att ha en komplett adressuppsättning i OSM är väldigt värdefullt då ett av de vanligaste användningsområdena för t.ex. en kartapp som använder sig av OSM är att kunna hitta från en adress till en annan. Många måste tyvärr falla tillbaka på stängda tjänster och appar idag för att OSM inte har alla adresser, så nu när möjligheten finns att lägga in det så är jag helt för att städa ut alla gamla adresser och ersätta dem med denna import.
2 Likes
Hvorfor er det viktig å ha adressen på bygningspolygonet?
På kartet vil det se temmelig likt ut, om han ikke zoomer svært langt inn. Og ingen av de andre kartene har det på polygonet (Google Maps, Apple Maps, Here, Eniro, Lantmäteriet osv).
Helt fantastiskt @NKA! Som vi har längtat efter att få till en import!
Vad jag förstår det som kvarstår att få explicit godkännande att tillkännage Lantmäteriet som källa på wikin, enligt CC-BY 4.0.
Angående det tänkta resultatet av importen har jag några synpunkter:
- För villor, parhus och radhus anser jag att byggnadspolygonen bör få adressen, eftersom det dels är lokal standard att kartera så, dels eftersom det är huset man generellt sett syftar på när man skriver in en adress. Att lägga adressen vid en uppfarts början ser jag inte som önskvärt eftersom man då inte kommer fram till huset. Att knyta adressen till en viss byggnad gör att kartan ser ur såsom man tänker sig i verkligheten – ett hus, en adress. Det blir också direkt tydligt vilken byggnad på tomten som är bostadshuset, och inte garage, bodar etc.
- Separata noder kan vara okej (även om jag tycker att det är en fulare lösning), särskilt på hörntomter där det är nödvändigt om ett hus har två adresser, men uppstår inte problem med dubblerad data i t.ex. StreetComplete om alla hus plötsligt saknar adressdata? Ingången på villor är ofta under tak som inte är korrekt ritade eller inte ritade alls, eller på sidan eller baksidan, så att sätta en entrénod på byggnadspolygonen känns inte realistiskt.
- För flerbostadshus anser jag att lösa adressnoder är en bra lösning, men inte lika detaljerat som att knyta adressen till entrénoden till trapphuset. Loftgångshus har jag försökt mig på att kartera, men det visade sig vara väldigt svårt att få till flera lager av trappor, gångvägar och entrénoder ovanpå varandra. Här är nog lösa noder är nog att föredra i dagsläget.
- För industriområden, gårdar och adresser utan byggnad är lösa noder det självklara valet.
- Butiker med samma namn särskiljs ofta i sökresultat enbart på adressen. Hur skulle detta fungera om vi tog bort adresser från butiker och andra objekt (som i dagsläget dubblerar adresserna)?
Och så några synpunkter angående själva importen:
- För själva inportförfarandet vore en tänkbar lösning att på studs importera alla saknade adresser som lösa noder, och låta resten vara kvar, för att i dag få till en användbar, sökbar karta, samtidigt som vi kan fortsätta diskutera detaljerna för vidare import och kontinuerlig synkronisering.
- Att radera nuvarande adresser i OSM utan djupare analys vore destruktivt. Att jämföra med andra karttjänster brukar synliggöra att OSM ofta är bättre och mer exakt i de områden adresserna är karterade noggrant. Jag har lyckades t.ex. ganska direkt hitta fel i adresserna i Lantmäteriets data i ett område som jag har undersökt på plats, där en överskrivning av nuvarande data hade lett till saknade adresser.
- Med 100 000 adressuppdateringar per år (varav en stor andel gissningsvis är postnummer) är manuell hantering som tidigare påpekats orimlig. Att med hjälp av
note-taggen undanta adresser från synkronisering verkar dock direkt olämpligt, eftersom den används till många andra kommentarer och kan ändras av någon ovetande om vad det föreslagna kodordet innebär. Jag förordar därför en unik tagg om det behövs för att undanta adresser från skriptet. - Därför kan dock diskuteras huruvida postnummer över huvud taget är av intresse för OSM, eftersom det (åtminstone fram till nu) har varit ett av Postnord privatägt register som marknadsförs och säljs av Postnummerservice Norden AB. Det används dock även i vardagliga sammanhang, även icke försändelserelaterade, så om nu Lantmäteriet också får tillstånd att licensiera datan – och därtill under en öppen licens – kanske det ändå inte skadar att importera den. Men då ska postnumren importeras med (om inte enligt standard så enligt praxis) blanksteg efter tredje siffran, NNN NN.
- Slutligen bör synkronisering ske så ofta som möjligt, för att göra OSM så konkurrenskraftigt och användbart som möjligt. I nybyggda områden ligger t.ex. OSM ofta före andra komersiella aktörer tack vare att användare är ute och uppdaterar kartan med byggprocessen och nya entréer, så att synka en gång i månaden känns lite för sällan. En gång i veckan vore lämpligare till en början, eftersom Lantmäteriet ju uppdaterar adressdatan dagligen.
1 Like
Nja, bara om adressen är en egen nod och inte ligger för långt ifrån Lantmäteriets position så behålls den. Skulle tippa på att 90% kommer tas bort och ersättas av en ny nod.
Har ni kollat på exempelfilerna?
I Göteborg ligger alla adresser ute vid närmsta väg
Utom den här typen av hus där dom ligger på inngången
Verkar som nån slags “vid postlådan”-strategei i Götet.
Stockholm gör inte alls så utan har adressenara relativt “normalt” om man vill kalla OSM normalt:
I Karlshamn har man istället gått för “mitt på byggmassan”
Fast bara ibland
Dock relativt konsekvent
Härjedalen har också mestadels “mitt på”
2 Likes
Det faller nog tillbaka på en till stor del subjektiv och filosofisk fråga. Personligen ser jag det lite såhär - du är aldrig egentligen intresserad av att komma till den punkt adressens koordinat representerar, utan du är intresserad av att ta dig till t.ex. ett hus, en affär, eller liknande. Så följaktligen är det relativt ointressant att ha adresserna som egna objekt, utan de bör vara del av de objekt man faktiskt är ute efter.
@Hidoo00 tycker jag också har många bra argument.
Det låter lite som tagging for the renderer 
Jag tror att just den biten faktiskt är löst, i villkoren står det “Om det inte är praktiskt möjligt att ange ovanstående i direkt anslutning till
geodataprodukten kan ovanstående anges eller länkas till i medföljande
dokumentation, metadata eller motsvarande.” vilket jag tycker låter som precis det godkännandet vi behöver.
Men det kvarstår då tre frågor;
- Godkännande kring DRM-problemet
- Om det är något särskilt att tänka på utifrån Fastighetsregisterlagen och GDPR (borde inte vara om ni fått godkänt för ändamålet att använda i OSM)
- Och den spännande frågan om ens någon får använda HVD idag…
Stort +1 på den!
1 Like
Nu har liksom det blivit en allmän sanning att 100 000 adresser ändras varje år i Norge. Jag tycker det låter oerhört märkligt. I förhållande till befolkningsmängd så är det ju väldigt många som får sin adress ändrad varje år? I Sverige tycker jag snarare att adresser inte förändras särskilt mycket över tid. Jag skulle gissa att en stor del av de där 100k ändringarna är folk som flyttar på adresspunkterna för att förbättra och att polis-scriptet går in och reverserar ändringen? Och det är det förfarandet jag vänder mig emot.
Teknisk fråga:
Om rätt adress finns inom en felmarginal/radie på 0-50 m. Varför behöver scriptet göra någonting då? Är det inte bättre att lämna den isf så att folk kan finjustera?
Ja, en intressant synpunkt och gissning. Men i stället för att spekulera vore det bättre att få info om vad de 100-tusen ändringarna består av. Finns det statistik?
I alla fall i Sverige så är en väldigt stor andel av ändringarna för postnummer. Enligt Skatteverket så är det t.o.m. ännu värre än i Norge: Postnummerändringar 4 mars 2024 | Skatteverket
Så definitivt något vi måste automatisera om vi vill ha en chans att hinna med. Men då såklart på rimligt vis, t.ex. att bara postnumret ändras om det bara är det som ändrats, och inte t.ex. positionen eller typ av objekt.
4 Likes
Det stemmer - nye postnummer (og dermed poststed) står for den største mengden endringer.
Mina OSM-bidrag har i huvudsak bestått av just adresser i Storstockholm och tycker att det är jättebra om vi kan importera LMs data, även om det i praktiken skulle innebära att de flesta av mina OSM-bidrag blir raderade 
Är dock lite osäker på om det är en bra idé att använda specifikt note-taggen för att blockera adressuppdateringar. note används ju ofta som en “lättare” fixme, eller för “att göra”-grejer. Det är i alla fall så som jag har sett den taggen användas (och använt den själv), i alla fall i södra Storstockholm. Och i wiki:n står det att den kan användas för “hints for further improvement”. Fast sådana note-taggar kanske borde ersättas med fixme-taggar?
Mer kommentarer från mig (långt / gällande en massa specialfall)
Angående adressens placering: Det mest intuitiva är ju att den antingen ligger på byggnaden eller på ingången.
- Lägger man den på t.ex. uppfarten så blir det fel ifall det finns flera addresser (typ A/B/C) som delar på samma uppfart. Väldigt vanligt runt Stockholm.
- Är det rimligt att förvänta sig att routing-kod föredrar vägen med samma namn, ifall det finns flera vägar i närheten av addressen?
(Givetvis finns det fall där det inte går. T.ex. om en väg går i en slinga och passerar en adress på både fram- och baksidan. Eller om det finns enbarrierpå vägen, som man vill hamna på rätt sida om. Men det känns som ovanliga specialfall. Man kanske kan rita ut enhighway=service(ellerfootway) från rätt sida, för att lösa sådanna specialfall?)
Angående noder / polygoner / relationer:
- Kollade runt hur det ser ut i Norge och Danmark, och tycker det ser helt okej ut. Man kanske kan göra manuella justeringar där det blir galet?
- I vissa fall är polygoner inte ett alternativ, redan idag, t.ex. flera vid byggnader på samma address, eller 3d-byggnader (dessa är en multipolygon/relation).
Angående automatisk radering eller flyttning av noder:
- Address-noden kan ju ha andra attribut, som t.ex.
entrance=yes, som man inte vill ta bort, men samtidigt vill man inte duplicera entréer heller. Känns som en knepig fråga. - Det förekommer också att det finns två entréer, som båda har var sin nod med samma adress-taggar.
- Det förekommer också inofficiella (men nummerskyltade) adresser. T.ex. föreningslokaler, attefallshus, m.m. Dessa bör ju få finnas kvar. Kanske kan man generera en lista över allt som raderas helt vid första importen (dvs utan att flyttas / göras om till en nod), så att man kan lägga tillbaka sådana adresser?
Angående taggning för att “blockera” import/radering
notetaggen används ibland som en “lättare”fixme. Tex.note=approximate location,note=check housenumbers,note=guess. Fast egentligen borde man kanske ersätta alla sådananotes medfixmes?- Kanske bättre att använda en specifik tagg, typ
allow_import:lm_belagenhetsadress=no. Bör så klart diskuteras/dokumenteras på wiki:n.
Angående “Metertalsadressplats” t.ex. “250-10”
- Denna syntax används ju redan utanför OSM t.ex.
59-61för tomter/byggnader som tar upp två adresser. Kanske är bättre att använda ett annat tecken än-för att undvika förvirring?
100 000 adresser ändras varje år i Norge. Jag tycker det låter oerhört märkligt
Men i stället för att spekulera vore det bättre att få info om vad de 100-tusen ändringarna består av.
Här är bottens framfart
Stickprova lite på adressernas history, eller gör statistik om man kan.
Egentligen borde dom göra ännu fler ändringar eftersom väldigt många kommuner har väldigt dåliga adressplaceringar.
Takk for mange fine observasjoner og forslag, SamuelLB. Noen kommentarer nedenfor.
Ikke uenig, men vi får bare det datasettet som LM tilbyr, og der er alt frittstående noder uten tilknytning til bygning. Man kan ønske seg en annen plassering, men da må vi nok trene opp en AI-modul. Jeg har forsøkt å la skriptet velge nærmeste hus, men da havner adressen like gjerne i en garasje eller et uthus, og to adresser kan havne i samme hus. Og vi må da først gjøre bygningsimporten, siden de fleste hus mangler i OSM.
Enig, og både Norge og Danmark bruker frittstående noder.
Enig, entrance=yes vil ikke fjernes fra der den lå, men adressen kommer på en egen node. Man kan se detaljert i eksempel-filene hvordan dette blir med ekte data fra OSM. Det ser ok ut, synes jeg. En komplikasjon er at entrance=yes kan ligge litt feil, særlig der Bing er brukt.
Vi bør unngå duplikate adresser - det er vanskelig å skille hva som er duplikat med hensikt, og hva som er en brukerfeil.
Ja, det er egne addr-tagger for slike og de vil beholdes. Jeg har lastet ned samtlige slike i Sverige og det ser ut til å være håndterbart.
Jeg har ikke noe sterkt synspunkt på hvilken tag som skal brukes, men note=* er normalt den man bruker for å gi informasjon til andre OSM-mappere. Taggen bør være enkel å huske. Kanskje note:addr=* kan brukes.
Jeg er ikke vant til å bruke metertallsadresser. Skrives adressen på f.eks. et brev akkurat slik, med bindestrek (“250-10”)? Jeg har sett at LM viser slik adresser på sitt topo-kart som “250-10”, dvs. med bindestrek. LM viser aldri to adresser samlet, men som to separate noder.
2 Likes
@NKA Tack för kommentarerna 
Kanske är säkrast att låta noderna ligga på samma punkt som i LM:s data. Bättre att det ser fult ut (t.ex. att en nod ligger precis utanför ett hus) än att den hamnar på grannens hus
Jag är egentligen väldigt dåligt insatt i metertalsadresser. Har aldrig sett de användas i Storstockholm där jag karterar. Men det känns som att både metertalsadresser (som 250-10) och “dubbeladresser” (som 59-61) är relativt ovanliga. Och det är ju uppenbart vad som är vad i dessa exempel. Så det kanske inte är något problem ändå.
Noen kommuner har flere tusen adresser med metertall, f.eks. Karlshamn.
En del av disse adressene har bare én bolig per nummer, dvs. intet metertall, og da står det null i husnummeret, f.eks. “195-0” som vist i bildet nedenfor. Er det vanlig i Sverige å ta med denne nullen når man skriver en slik adresse på et brev, eller skriver man bare “195”?
Jeg ser på LM’s kart at “-0” er tatt med der.
Som jag tidigare nämnt så är jag emot detta, eftersom vi då faktiskt tappar information.
Om det finns ett befintligt objekt med en viss adress så bör den behållas, både i position, övriga taggar, o.s.v., och ingen ny nod skapas för den adressen.
Ett möjligt undantag är noder med shop=, amenity=, etc., men även det tycker jag är tillräckligt tveksamt för att en första import inte bör röra det.
1 Like
Se på eksempelfilen fra Stockholm. Man skal ha temmelig god AI for å finne ut 1) hvilken adresse som hører til hvilken inngang, og 2) hva som er mappet mest riktig - adressen eller inngangen. I tillegg kan bygningen ha offset.
Bildet viser inngangene slik de er mappet i OSM må.
Det krävs väl ingen AI model för detta en enkel jämförelse av den genererade addressen och en adress i osm är ju enkelt och då behåller man adressen i osm om avståndet är under säg 10 meter.
det kan mycket väl finnas en offset men det kan korrigeras senare. En adress ovanför huskroppen är bättre än en utanför även om den utanför ligger “mer korrekt”.
Precis, vet inte riktigt hur AI kommer in i det.
Finns motsvarande adress inom några hundra meter (minst samma nummer och gata)? Gör inget, ändra inget.
Finns motsvarande adress men med någon avvikelse (t.ex. annat postnummer)? Justera den avvikelsen men inget annat (inte positionen, inte övriga taggar, inte skapa ny nod).
Om inte? Lägg till det som nod på Lantmäteriets koordinat.
7 Likes
Och som @Wulfmorn visade tidigare här i tråden så är geometrierna från kommunerna/Lantmäteriet inte heller helt konsekvent placerade, så vi har verkligen en möjlighet att vara bättre än LMs data.
2 Likes