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 (osm.wiki/Key: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 osm.org/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 osm.org/node/4960384498, new node osm.org/node/12950070726
* Granvænget 2, Karlslunde: existing node osm.org/node/340792644, new node osm.org/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; osm.org/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]: osm.org/node/10741944194/history
[4]: osm.org/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=[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]: osm.org/way/443547649/history
[2]: osm.org/way/777916748
[3]: osm.wiki/Relation
[4]: osm.org/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]: osm.org/node/9480574410
[2]: osm.wiki/Tag:canoe%3Dput_in
[3]: osm.org/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]: osm.org/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]: osm.org/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]: osm.org/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]: osm.org/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]: osm.org/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]: osm.org/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]: osm.org/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]: osm.org/changeset/141987419

This was an erroneous import, see [autoAWS gitlab issue](https://gitlab.com/OSM-DK/autoAWS/-/issues/4).

Corrected by [141973796](osm.org/changeset/141973796).

Halløjsa, ja der er da lidt redundans.

Redningsnummeret på Esbjerg Brygge (9951319504) er den korrekte A 785, den på Esbjerg Strand/øen (9105172638) er A 786. Jeg har rettet det i osm.org/changeset/138727156.

Se billede af A 786 fra åbningen af Maritimt Center på https://drive.google.com/file/d/1aTFSmntulJ3QL6hAPheC2TgQr67a2uKO, eller søg den frem på den officielle redningsnummer-hjemmeside https://www.redningsnummer.dk/#korteksempler.

Mærkeligt nok vises ingen af de to på Trygfondens side (som ellers anbefales) https://www.respektforvand.dk/forebyg-ulykker/find-livreddere.

Elgaards analyseside for redningsnumre (https://osm.elgaard.net/) ser ud til at have mistet forbindelsen til sin datakilde, så den viste heller ikke at der var et problem.

Jeg tilføjer dog kun dem jeg ved selvsyn har observeret i felten, da vilkårene for de officielle data er ikke forenelig med OSM (https://www.redningsnummer.dk/#termsandconditions).