Multipla noder på byggnader - varför?

Jag fixade lite runt Sala Silvergruva häromdagen och noterade då att nästan alla byggnader hade flera noder på väggarna. Varför?

När jag ritar en rektangulär byggnad så sätter jag en nod i varje hörn och sen är det klart. De här byggnaderna hade, förutom hörn-noderna, även en extra nod mitt på vardera kortsida, och tre extranoder på vardera långsida. Alltså, summa 12 noder där det räcker med 4.

När byggnaden först skapades hade den sina 4 noder, sen har nån kommit in i mellantiden och lagt på extranoderna (från iD). Jag raderade extranoderna helt osentimentalt. Exempel nedan.

Men… Varför har iD lagt in en massa extranoder som ändå inte innehåller någon information och därmed inte behövs? Jag är mest bara nyfiken. Har någon här en hypotes?

Ibland uppstår sådana geometrier när objekt från import hamnar i databasen. I de flesta fall beror det dock helt enkelt på mapparen, som inte mappar korrekt. I allmänhet har du rätt: en linje ska vara en rak linje mellan två punkter (Good practice - OpenStreetMap Wiki).

1 Like

Just det här tror jag inte var nån import.

Byggnaden skapades 23:e sept 2021 med 4 noder
Byggnaden editerades 14:e dec 2021 och fick 12 noder
Byggnaden editerades (av mig) 20: maj 2023 och fick 8 av de 12 noderna raderade.

Det ser ut som att iD bara har lagt till helt onödiga noder och inte ändrat nåt annat. Undrar varför?

Jag är inget stort fan av iD, men jag kan inte tänka mig att iD automatiskt lägger till noder i byggnader. Samtidigt är det intressant att noder i de aktuella ändringarna lades till i flera byggnader med jämna mellanrum. Detta visualiseras ganska bra här: achavi - Augmented OSM Change Viewer  [attic]

Kanske kan du kommentera ändringssatsen en gång så att användaren kan komma ihåg den.

2 Likes

Jag kan inte se nån logisk förklaring. Du får gärna fråga personen som la dit dom. Det är alltid interessant att veta vilket resonemang som låg bakom.

Done

1 Like

Jag ser detta fenomen även på vägar som är helt raka. Om vägen är mycket lång kan det kanske vara svårt att se att vägen är helt rak, men även på korta raka vägar lägger vissa till mer än 2 noder. Mycket märkligt.

I fallet med vägar är det inte så märkligt.

Hus kan förutsättas ha raka sidor (även om ett fåtal undantag finns). Där räcker det med en nod i hörnen.

Vägar kan inte förutsättas vara raka. En raksträcka utan nod kan mycket väl vara en sväng med för dålig nodtäthet. Därför är det inte alls orimligt att sätta en nod på raksträckan.

Den dagen OSM till 100% representerar verkligheten kan vi köra en databesparingsalgoritm och rensa bort noder på raksträckor. Men dit kommer vi aldrig att komma.

1 Like

Detta är en motsägelse. En rak sträcka är alltid rak, inte böjd. Om den inte är rak, är den böjd, och då motiveras extra noder. Sedan kan man ju olika åsikter om en väg är spikrak eller inte.

Det jag vänder mig emot är att vissa personer verkar tycka att många noder är bra. Så kallade “nodfetischer”.

Ok, jag omformulerar mig.
Vad som i OSM kan se ut att vara en raksträcka är relativt ofta en sväng men ingen har satt en nod där.
Därför fyller extra noder på en raksträcka en funktion eftersom man aldrig kan veta hur bra underlaget är. Sitter det en nod har dock någon gjort något aktivt just där.

1 Like

Jag gissar att extra noder på vägar kommer av att nån klickar ut raksträckan per skärmbredd och ser inte hela sträckan samtidigt. Om personen jobbar i iD eller i övrigt inte tar sig bryet med att ta bort onödiga noder så blir dom liggande.

Det är iaf min gissning på förloppet.

Förklarar inte byggnaderna. Vi får nog aldrig svar heller. Användaren har inte mappat på 1 år. :frowning:

Många onödiga noder är ju inget större problem. Antalet noder ökar i onödan i databasen, men jag tror inte det är ett stort problem. För min del är det mer ett estetiskt problem och som stör mitt ordningssinne att det finns onödiga objekt.

En del sätter också onödigt många noder (som jag tycker) på sträckor som är böjda. Exempelvis på polygoner eller krokiga vägar. I de fallet tror jag att det är mycket tycke och smak, man tycker det är “snyggare” med tät liggande noder, så att en “böj” inte blir för kantig. Och eftersom vi alla är olika, har vi olika syn på vad som är en “för kantig” böj.

Jag sätter alltid perfekt antal noder på mina svängar :slight_smile:

Upplösningen i antal punker för att definiera en icke-linjär struktur är såklart godtycklig. Ju fler korrekta punkter desto bättre i någon mening. Att det skiljer sig mellan användare behöver inte vara ett driv av att “mappa för renderaren” utan snarare ett exempel på olika tålamod eller värdesättande av detaljer kontra antal strukturer.

Jag är själv för hög detaljnivå och vill även lyfta AndersAnderssons tanke angående extra punker på raka sträckor. Det finns absolut ett värde att lägga till korrekta punkter i raka vägsegment då det ger information om hur väl datan representerar verkligheten. Två punkter som definiersr ändar av en väg ger alltid en linjär modell oavsett hur mycket vägen i verkligheten slingrar sig.

Förklara varför man ska lägga till extranoder på en rak väg? Ju fler desto bättre? Exempelvis 1 nod per meter eller varför inte 1 nod per decimeter eller varje centimeter?!

Jag trodde jag hade börjat förstå hur man arbetar med vägar i OSM. Tydligen verkar vissa anse att åsikten att ha så få noder som möjligt, utan att försämra geometrin, är fel. Så ni som vet hur det ska vara, upplys mig, den okunnige, hur tätt noder ska sättas för att en väg ska vara korrekt mappad.

Jag förklarar gärna!

Vi kan väl resonera kring nedanstående bild jag ritade lite snabbt?

De två svarta punkterna är korrekt karterade ändpunkter på ett vägsegment. Förfinar vi inte vår kartdata är både grön och blå väg möjliga alternativ till den faktiska väg vi ämnar representera. Väljer någon då att förfina kartdatan och lägger till de gröna punkterna försvinner blå väg som alternativ till den verkliga vägen.

Vänder vi på det hela och faktiskt försöker avbilda en väg som den blå och endast definierar ändpunkterna kan vi inte vara säkra på att inte grön väg (eller något annat slingrigt) avses. Lägger vi till de blå punkterna utesluter vi grön väg (och ett stort antal andra).

Det hela är i någon mening analogt med hur vi ibland anger mätetal med en siffra följt av endast nollor som decimaler. 6,000 är inte samma sak som 6,0. 6,000 betyder att vi anser att de verkliga värdet ligger i ett betydligt snävare intervall än om vi skrivit 6,0.

Tillbaka till OSM: som jag skrev i tidigare inlägg är det godtyckligt hur tätt man väljer att placera punkterna för att precisera noggrannheten i den struktur vi avbildar. Det finns inget rätt eller fel här. Jag tycker att AndersAndersson förklarar det bra med att hus kan förutsättas ha raka linjer som sidor i en annan utsträckning än vägar.

Vill du endast definiera ändarna av vägar som är raka är det helt ok, på samma sätt som att det är helt ok om en annan bidragsgivare väljer att tydligare precisera sträckningen. Hyperbolen nodtäthet på centimeterskala är såklart inte vad jag avser här. Är det något som du inte förstod i vad jag skrev, inte håller med om eller liknande får du gärna skriva tillbaka. Tanken med detta forum är konstruktiv diskussion som förbättrar vår kartdatabas.

1 Like

Om OSM var stängt och endast några få professionella välutbildade personer ritade kartmaterialet från ett bra underlag vore det optimalt att endast ha punkter där vägen svänger. Så är inte verkligheten.

Många vägar finns kvar från den tiden då endast Yahoos flygbilder eller egna GPS-spår var de enda alternativ som gällde. Ibland försvann 1 km av vägen i moln, ibland såg man inte skillnad på en å eller en väg, en sjö eller skugga från moln m.m. Flygbilder uppdateras också med tiden, moln finns på nya ställen. Om man har 1 km väg utan noder i mitten som täcks av moln, hur ska man veta om det är en rak väg som någon ritat perfekt tidigare eller om vägen är full med svängar som döljs under molnet?

Du stirrar dig lite blind på hur det är i Sverige precis nu. Stora (största?) delen av världen har fortfarande kassa flygfoton som enda källa. Vår tillgång till NVDB kan när som helst försvinna, precis som t.ex. Maxars flygbilder och Strava gjort relativt nyligen.

Över 90% av OSM:s användare är nybörjare där man inte alls kan vara säker på vilken noggrannhet dom tycker är acceptabelt. Förhoppningsvis väljer dom i alla fall att sätta noden där vägen är även om dom är slarviga med kvalitén i övrigt.

1 Like

Ja, man kan lägga ut texten om möjliga fall, hur det ser ut i verkligheten och de foton vi har tillgång till. När det gäller noggrannhet och precision har jag mångårig vana och kunskap om sådant, men i första hand när det gäller mätning elektriska värden. Oavsett hur bra man mäter, kan man alltid hitta “fel” om man ökar upplösningen. Detta gäller för allt man mäter och försöker kvantifiera.

Resonemanget om att sätta noder på en väg är analogt med detta. Om man mäter på plats kanske kan man se att en väg inte är “spikrak” den kanske svänger några centimeter eller decimeter på en given sträcka. Och då kanske den noggranna mapparna sätter ytterligare noder för markera “svängarna”. Och om vägen verkligen inte är “spikrak”, hur man nu definierar det, så är ytterligare noder inte fel. Och inget jag är emot, även om jag inte orkar med finlir i absurdum.

Det jag reagerar emot är när uppenbart raka vägar, enligt flygfoto, verkligen är raka. När dragning av väg är tänkt att vara rak, men där extranoder adderas av någon anledning. Exempelvis en modern stadsgata. Man gör inte sådan krokig av misstag. Den planeras att bli “spikrak” och byggs så. En “petimeter” kanske kan hitta en mindre/mikroskopisk “böj” någonstans Eller en kortare uppfart till en fastighet. Men OSM gynnas inte av extranoder i dessa fall.

Jag tycker att både jag och Batistacavera gett bra anledningar till varför man sätter noder på raksträckor. Förstår du inte det vi skriver eller ignorerar du det?

Eftersom du jobbar med mätning kanske du förstår detta exempel:
Om vi har en konstant signal samt en sinusvåg med våglängden 1 m och samplar båda signalerna en gång varje meter så ser båda raka ut. Endast den som vet att det är en sinusvåg ser att det är kurvor på den. Men inom OSM vet vi inte om det är en sinusvåg eller en konstant signal.
Du står just i detta tillfälle med all information och tycker det är självklart att endast sinusvågen behöver samplas med högre frekvens.
Men inom OSM kan vi inte ta den informationen för given. Rätt som det är försvinner datakällan där det framgår att vägen är rak. Hur ska nästa editerare då veta om vägen är rak eller svänger när det saknas noder på en lång sträcka? Moln kan ha tillkommit på den enda flygbilden som finns tillgänglig och GPS-spår saknas.

Detta är självklart mer applicerbart på landsbygden än i stan, men även där skadar inte extra noder.
Sedan har vi ett historiskt arv. OSM började från 0. Man började men en väg i en stad utifrån det GPS-spår man samlat in och hade ingen aning om var korsningarna fanns. Därför hamnade noderna var som helst. Med Murphys lag så hamnade dom ju gärna för nära, men ändå för långt ifrån korsningen så att det blir en nod man helst inte vill ha. En nod som är lite irriterande när man behöver justera vägens position något.

Jag har inte sett någon som förespråkar en nod varje meter på en raksträcka. Det blir bara jobbigt att editera. Men 1-3 extra kanske på en raksträcka som är några 100 m lång, så man är säker att vägen inte kan sticka iväg i någon sväng mellan noderna i kurvorna.

1 Like

Jag håller helt och hållet med dig. Hade själv inte funderat på dina exempel på historiaka abledningar till nodtätheten. Och bra exempel med sanpling av elektriska signaler med.

Jag ser det med pragmatiska glasögon. Alla har sin gräns för hur tätt man sätter sina noder. Så länge de väl stämmer överens med verkligheten är fler noder bra. Är det interpolerad data eller eller slarvigt karterade är det inte önskvärt. Och som vi båda konstaterat är det lämpligt att fundera på hur sannolikt det är att strukturen avviker från att vara helt rak och välja nodtäthet därefter. I fallet bro/husvägg/vajer eller dyligt är drt mer rimligt att anta spikrak sträckning än hos ett meanderlopp.

Har man problem med att databasen blir för stor är det ju dessutom matematiskt mycket lätt att filtrers bort noder baserat på vinklarna mot föregående och nästa nod.