Hi Jbah,

From node/10679004016 touched in this CS:
>fixme=someone please double check in person. I'm doubting my memory since I can't find any news articles of it having been removed...

Midgårdsbrønden still exists, but you/Pavol33 got the intersection with Torvegade mixed up and this node was added as a duplicate with wrong location. It is not placed at intersection with Flegborg, but with Orla Lehmannsgade a bit South-West.

Take a look at [GeoDanmark Ortofotos from spring 2025][1], or [Klimadatastyrelsens Skraafoto from 2023-05][2] (latter is multi angle, so easier to spot such objects).

Midgårdsbrønden has been [present in OSM node/7041919832 ][3] as an unnamed statue all along since 2019.

In recent [changeset/175407265][4] I upgraded tags for it to also become a fountain and added other details (together with the other 2 artworks which is part of the installation), so all should be good now (or at least better ;).

Thanks and happy mapping,
Mikkel

[1]: https://kortoverblik.dk/spatialmap?layers=theme-orto_foraar_daf&mapext=533447.4074889551+6173802.009257668+533538.3869767742+6173850.010414523
[2]: https://skraafoto.dataforsyningen.dk/?center=533479.5%2C6173819.91&item=2023_83_29_4_0017_00001758&year=2023&orientation=east
[3]: node/7041919832/history
[4]: changeset/175407265

Hej Troels,

Kommentaren skulle vist have været "Added space..."?

Bemærk at der ikke er fuldstændig konsensus omkring hvorvidt der anvendes mellemrum eller ej i referencer til redningsnumre.

Jeg har også altid selv opfattet skiltene som havende mellemrum, men ved nærmere undersøgelse viser det sig at uagtet dette bliver der refereret til dem uden mellemrum i de officielle kilder både på [kortet på respektforvand.dk][1] og den officielle liste (som fås både som [WMS/WFS] [2] og [MS XLS][3]).

Derfor er der flere mappere der korrigerer og fjerner mellemrum i overensstemmelse med listen. Se f.eks [changeset/62137505][4] og [changeset/148671541][5].

Se også [Jørgen Elgaards valideringsværktøj missingObjectsDK][6] som kan [fremhæve uoverensstemmelser mellem listen og eksisterende/manglende access_points][7], hvorpå disse to "F 485" nu fremhæves som fejlende (rød) og den ene position for "F485" der eksisterer på listen lidt nord for den nordligste markeres som manglende (blå).
Der er i øvrigt mange steder hvor der fysisk står flere skilte med samme nummer (disse er markeret grønne), men på listen er der altid kun én registrering med én lokation (måske mødepunkt for udrykningskørsel, og øvrige skilte er for publikums opmærksomhed?).

Direkte import af listen er desværre ikke mulig da [datalicensen i så fald kræver at opdateringsdato fremgår på reproduktioner][8] hvilket selvsagt ikke kan garanteres med OSM-data under ODbL).

--
Hilsner,
Mikkel

[1]: https://respektforvand.dk/?filter=6#Find%20badested
[2]: https://www.redningsnummer.dk/#korttjenester
[3]: https://www.redningsnummer.dk/#download
[4]: changeset/62137505
[5]: changeset/148671541
[6]: https://github.com/OSM-DK/missingObjectsDK
[7]: https://osm.elgaard.net/map.html?layers=missing_rescuenumbers;doubled_rescuenumbers;extra_rescuenumbers&pointColors=%2333f;%233f3;%23f33&titles=Mangler%20fra%20redningsnummer.dk;Dublerede%20redningsnumre;Forkerte%20redningsnumre&hideLayers=0;0;0;0&title=Manglende/forkerte%20redningsnummerskilte
[8]: https://www.redningsnummer.dk/#termsandconditions

Hi there!
Oh, my bad (or more specifically the Android on-screen-keyboard + auto-completion + my fingers combo).

The "ref:DK:cvr" key is correct, but the "ref:DK:cvr:" misses a "pnummer" suffix to be a "produktionsenhedsnummer" tag (ref:DK:cvr:pnummer=*).

Refer to the CVR source registration for the entity providing both numbers at https://datacvr.virk.dk/enhed/produktionsenhed/1022357472.

I have just fixed this in CS changeset/169453774.

Thanks for the attention ;).

Hej,

Jeg afventer lige at have tid til en gennemgang af koden omkring Overpass, der må være nogle fejlscenarier der ikke detekteres som forårsagede dette.

Kan ikke se at Overpass værende bagude skulle kunne give så mange dubletter. Der ville først begynde at opstå dubletter ved genkørsel af et postnummer efter ca. 20 timer (1089 postnumre processoret med ca. et i minuttet i det normale flow), og det vil kun være de senest tilføjede der mangler og dermed dubleres.
Denne situation vil rigtigt nok kunne fanges af et tjek af "timestamp_osm_base", som jeg også tidligere har tilføjet til [autoAWS' todo-liste][1], men har ikke prioriteret dette ret højt da dublettjekket burde fange det.

OSM sysadmin-teamet har også bedt om at der sættes en User-Agent-header, det sad jeg faktisk og arbejdede på da jeg opdagede ovenstående i loggen.

Jeg har ikke meget tid i overskud, så jeg har ikke endnu studeret hverken replikeringsproblemet eller hvordan autoAWS reagerede i detaljer (og mangler desværre også logs fra starten af hændelsen), men vil gøre en indsats for at få autoAWS kørende igen snarest.
--
Mikkel

[1]: https://gitlab.com/OSM-DK/autoAWS/-/blob/master/todo.md#taggingdata

Hmm, just took a quick look at a few of the offending nodes, and they seem to all have been created by autoAWS 4-5 days ago even though the existing node was never touched. So somehow autoAWS concluded that nodes with those osak:identifier values didn't exist.

Sorry for this mess. But please ping me/autoAWS account directly next time autoAWS causes troubles.

I have disabled autoAWS for now until we have a better understanding of what happened.

Examples:
* Glostervej 9, Valby: existing node node/4960384498, new node node/12950070726
* Granvænget 2, Karlslunde: existing node node/340792644, new node node/12953241205

Hi adresse_repair,

Could you please elaborate a bit about what happened here? Did you duplicate a lot of address nodes manually on another account and deleted them on this account?

The autoAWS bot saw 11071 nodes with duplicated osak:identifier from at least 2025-06-29 08:50:01 UTC (earliest log entry present because the existence of these caused extensive logging rotating logs very fast) until around the time of this changeset + overpass roundtrip (autoAWS queries overpass with filter for osak:identifier & postcode);

[29-Jun-2025 08:50:21 UTC] INFO: 11071 addresses will be deleted from OSM

[29-Jun-2025 10:10:13 UTC] INFO: 0 addresses will be deleted from OSM

autoAWS was supposed to delete duplicates automatically but there seems to be an error in the bot, so that deletions did not happen in this scenario, see fx. this empty changeset; changeset/168257489. This might be due to the large number of nodes which triggered a "split changeset" feature which I have never observed being activated before.

For non-Danish people reading along, please find more info in the wiki pages detailing how Danish addresses are updated automatically from authoritative sources by the autoAWS bot;

* osm.wiki/Da:Adresser
* osm.wiki/AutoAWS

--
Regards,
Mikkel
autoAWS operator

Hov, som tagsene viser inkluderer diskussionen selvfølgelig også fvst:navnelbnr.

Hej Niels,
CVR for Bøf og Vin i Aalborg havde været [ophørt i et halvt års tid][1] da du tilføjede denne i dette changeset, og andre mappere havde fjernet den oprindelige restaurant i 18C. Restauranten fremgår dog stadig som [aktiv hos fvst][2].

Jeg har [genbrugt den nye node til disused for 18B][3] samt [tilføjet disused:{name,amenity} og ref:DK:cvr{,:pnummer} tags til den oprindelige][4] sammen med en note med en forklaring.

Er dette tilstrækkeligt til at dit værktøj og redigeringsflow vil fange dette fremover og ikke gentilføje?

Det mest korrekte i denne situation ville nok være disused:ref:DK:cvr{,:pnummer} så det er tydeligt at tagget er inaktivt, men reagerer dit værktøj på dette? Eller kunne det bringes til det?

Et check for status i CVR inden tilføjelse ville selvfølgelig også fange sådan en situation inden det kommer så langt ;).

Tak for din indsats,
Mikkel

[1]: https://datacvr.virk.dk/enhed/virksomhed/34158800
[2]: https://findsmiley.dk/504573
[3]: node/10741944194/history
[4]: node/3965008757/history/10

Hej Jørn,
autoAWS bør selvfølgelig forsøge at forholde sig til mest fornuftigt til de ændringer den laver.

Jeg er enig med dig i at sletning af en adressenode der indgår i en relation, provides_features eller andre, er potentielt ødelæggende for relationens mening. Jeg er ikke enig med dig i at det betyder at autoAWS aboslut ikke bør gøre det.

Teknisk set er det fuldt lovligt med en relation med kun et medlem, iD-editoren advarer ikke engang om denne situation. Jeg har leget lidt med det på test-databasen, se en slettet adressenode i en provides_features relation i [dev changeset/355421][1].
Faktuelt ville det være dette scenarie der opstår lige nu hvis en kommune sletter en af de adressenoder som osmviborg har tilføjet til relationer (og jeg kan se at han fortsætter ufortrødent i dag ;).

Jeg tænker umiddelbart at sletning af en adressenode er en administrativ ændring foretaget af kommunen som formentlig følges op af tilføjelse af en ny adressenode (måske med ændret osak:identifier) som nok i det fleste tilfælde ville give mening at genindføje som "address"-medlem af en provides_features relation.

Hvis autoAWS skulle gøre noget mere intelligent, tænker jeg at den måske kunne tilføje et eller flere tags på relationen der gemmer hvilken adresse og osak-id der tidligere var associeret, således at tilføjelse af en ny adressenode med samme osak-id eller samme adresse automatisk kan tilføjes til relationen igen.
Alternativt kunne autoAWS afholde sig helt fra at røre adressenoder der er medlem af en relation. Det synes jeg dog er lidt en glidebane mod manuel opdatering, og bør kun indføres som en nødløsning hvis der viser sig stor problemer med den nuværende tilgang.

Lige for at kvantificere antallet af sletninger kontra andre opdateringer, har jeg lavet et script til at trække denne statistik ud fra autoAWS-logs. De aktuelle logs dækker de sidste ~20 dage, og der foregår faktisk flere sletninger end jeg havde forestillet mig, men stadig langt færre end opdateringer.

autoAWS log statistics
----------------------
Start date: 2024-04-01T02:00:01+00:00
end date: 2024-04-21T10:40:05+00:00

Address nodes updated: 10587
Address nodes added : 1152
Address nodes deleted: 181

--
Hilsner
Mikkel

[1]: https://master.apis.dev.openstreetmap.org/changeset/355421

Hejsa,
Denne måde at knytte POIs til andre elementer på er også ny for mig. Men den er da ganske interessant, da den jo åbner op for at kunne associere POIs direkte med en konkret adresse, hvilket jeg altid har syntes var en mangel i den måde de danske adresser er endt med at være modelleret i OSM på.

Umiddelbart kan jeg ikke se at det skulle påvirke autoAWS' håndtering af en node at den indgår i en relation. Det er en viden der ligger ud over noden at den indgår i et mere overordnet objekt og er [overhovedet ikke synligt på selve nodens data][1].

autoAWS trækker sammenligningsgrundlaget mod AWS/DAR ud fra OSM vha. Overpass via en [query på noder der indeholder et osak:identifier-tag][2]. Dette sammenlignes derefter med data fra AWS/DAR og noden opdateres hvis den adskiller sig.
Associationen der eksisterer i en relation er [udelukkende på elementets id][3], så relationen vil være upåvirket af enhver ændring på adressenoden så længe den beholder sit ID, hvilket den vil gøre i en normal opdateringssituation.

Sletter nogen adressenoden manuelt vil autoAWS dog tilføje en ny fordi osak:identifier dermed ikke findes længere, denne vil så få et nyt ID, men det vil være den manuelle sletning der i første omgang ødelægger relationen og afkobler POI og adresse.

I vil kunne se at Jens Bangs Gade 8/node 343020428 stadig indgår i det [konkrete Overpass-opslag på postnummer 9000][4] selvom den er en del af relation/17468468 der har Cafe Alpha/node 11815994236 som target.

Bemærk at wiki-siden er fra 2023-12, mens [proposal er helt tilbage fra 2012 og markeret inactive][5], og at nuværende global brug kun er ~6500 relationer.

--
Hilsner,
Mikkel

[1]: osm.org/api/0.6/node/343020428

[2]: https://gitlab.com/OSM-DK/autoAWS/-/blob/88444100c48764591036732409f75066a818376f/index.php#L239

[3]: osm.org/api/0.6/relation/17468468

[4]: http://overpass-api.de/api/interpreter?data=[https://wiki.openstreetmap.org/wiki/Tag:out:json];node[%22osak:identifier%22][%22addr:postcode%22=9000];out;

[5]: osm.wiki/Proposal:Provides_feature

Hejsa,

Tak for dine bidrag. Du havde dog fået lavet nogle lidt sjove relationer i dette redigeringssæt.

Efter din redigering bestod [Munken SFO][1] hhv. [Fritidsklub][2] hver af en relation med to veje, hvoraf den ene var fælles.
Dette er for så vidt ikke forkert (og blev også renderet rigtigt på kortet), men det er unødvendigt i den situation og gør data mere kompliceret og sværere for mappere at overskue og redigere efterfølgende.

To almindelige veje kan sagtens dele de samme punkter, uden at en relation er påkrævet. Kun hvis der er information der skal tagges på det delte vejforløb giver det mening at lave den som en vej til at bære dette, og indføre de overordnede elementer som relationer der indeholder denne. Se også den lidt mere langhårede dokumentatoin [om relationer i wikien][3].

Jeg tænker at det måske er iD-editoren (standardværktøjet på hjemmesiden) der har forårsaget dette. Den kan nogle gang godt finde på automatiskt at lave en relation når man deler en vej i punkter der anvendes af flere veje. Det skal man lige være opmærksom på, og vurdere om det giver mening i det enkelte tilfælde.

Jeg har tilladet mig at fjerne relationerne og genetablere de to som veje i [changeset/142101192][4].

--
God mapning,
Mikkel

[1]: way/443547649/history
[2]: way/777916748
[3]: osm.wiki/Relation
[4]: changeset/142101192

Ok, det er helt i orden. Adressen bliver opdateret automatiskt af autoAWS, men ville bare gøre opmærksom på at hvis der er data i DAR der ikke er korrekt bør det rettes heri.

Jeg kan også se at alle adressenoder i området har dette tag, selv helt ind i noget af Allinge-Sandvig, men der er vist ikke (længere?) en by der decideret hedder Sandvig, kun [et kvarter i Allinge-Sandvig][1].

Jeg lægger mærke til det fordi jeg følger slavisk i hælene på autoAWS i øjeblikket, for at se om den gør hvad den skal, da den er flyttet til en ny server.

Jeg [har rettet][3] det andet shelter så det også er basic_hut, givet dem begge navnet fra udinaturen.dk, samt tilføjet [en kanobådrampe][2] på stranden som omtalt på udinaturen. Hvis du kender stedet må du da gerne lige tjekker om det ser fornuftigt ud, tak.

--
God mapning,
Mikkel

[1]: node/9480574410
[2]: canoe=put_in
[3]: changeset/142000953

Hej,

Var det med overlæg at du fjernede addr:place=Sandvig i dette changeset?

Botten autoAWS har genindført det i [changeset/141995659][1] da det er opført som [supplerende bynavn i Danmarks Adresser (DAR) på adressen Sænevej 5C][2], hviket [autoAWS mapper til addr:place i OSM][3] .

Hvis dette ikke er korrekt skal du som udgangspunkt have fat i kommunen der kan redigere DAR.

--
Mikkel

[1]: changeset/141995659
[2]: https://api.dataforsyningen.dk/adgangsadresser?q=s%C3%A6nevej%205c
[3]: osm.wiki/AutoAWS#Updating_addresses

Correction of erroneous import in which OIS fixes were disregarded, see [autoAWS gitlab issue #4][1] for details.

Correction of [changeset/141939287][2].

[1]: https://gitlab.com/OSM-DK/autoAWS/-/issues/4
[2]: changeset/141939287

This was an erroneous import in which OIS fixes were disregarded, see [autoAWS gitlab issue #4][1] for details.

Corrected by [changeset/141990537][2].

[1]: https://gitlab.com/OSM-DK/autoAWS/-/issues/4
[2]: changeset/141990537

Correction of erroneous import in which OIS fixes were disregarded, see [autoAWS gitlab issue #4][1] for details.

Correction of [changeset/141939123][2].

[1]: https://gitlab.com/OSM-DK/autoAWS/-/issues/4
[2]: changeset/141939123

This was an erroneous import in which OIS fixes were disregarded, see [autoAWS gitlab issue #4][1] for details.

Corrected by [changeset/141990301][2].

[1]: https://gitlab.com/OSM-DK/autoAWS/-/issues/4
[2]: changeset/141990301

Correction of erroneous import in which OIS fixes were disregarded, see [autoAWS gitlab issue #4][1] for details.

Correction of [changeset/141937848][2].

[1]: https://gitlab.com/OSM-DK/autoAWS/-/issues/4
[2]: changeset/141937848

Correction of erroneous import in which OIS fixes were disregarded, see [autoAWS gitlab issue #4][1] for details.

Correction of [changeset/141937671][2].

[1]: https://gitlab.com/OSM-DK/autoAWS/-/issues/4
[2]: changeset/141937671

This was an erroneous import in which OIS fixes were disregarded, see [autoAWS gitlab issue #4][1] for details.

Corrected by [changeset/141987419][2].

[1]: https://gitlab.com/OSM-DK/autoAWS/-/issues/4
[2]: changeset/141987419