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=[out:json];node[%22osak:identifier%22][https://wiki.openstreetmap.org/wiki/Tag:%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

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

Corrected by [141973796](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 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).

Now done, including adjacent similar shop=online; changeset/133917431

Hello Mateusz,

Thanks for noticing! This is my local neighborhood so I pass by there often ;).

Remember I was a bit doubtful at the time whether there was a shop because the place never presented itself as a shop.
Now I think office=company, company=it would be the best fit. The shop does advertise in local newspapers as if it is a regular computer shop but there is no shop as such on the ground.

I guess it would be possible to collect items if buying something by phone/website but not as organized as I perceive shop=outpost to be.

--
Regards,
Mikkel

Hej b-hold,

Ja, det er helt bevidst gjort, da den omtales sådan lokalt og er benævnt sådan på flere skilte i området, hvilket er helt konsistent med Naturstyrelsens side i website-tagget og [andre kilder][1]. Kan dog godt se at Stednavneudvalgtet øjensynligt bruger ubestemt ental i stedet for bestemt (af en eller anden grund kan den ikke fremsøges på http://www.stednavne.info).

Nogle steder omtales hele området, ikke bare søen, som Skavemose(n), og søen som Husby Badesø, bl.a. på [skiltet der står ved søen][2] og [noget marketingsmateriale][3].

Jeg har rettet tilbage til Skavemose, og suppleret med Husby Badesø i alt_name i [Ændringssæt: 118570186][4].

Mikkel

[1]: https://www.visitnordvestkysten.dk/nordvestkysten/planlaeg-din-tur/badesoe-skavemosen-gdk1042050
[2]: https://mikini.dk/wp-content/uploads/2022/03/wp-1647469735063.jpg
[3]: https://discoverdenmark.dk/activities/husby-badesoe
[4]: changeset/118570186

Sure did. Thanks for the heads-up. Fixed in [117980218][1].

[1]: changeset/117980218

Halløjsa.
Hvorfor tilretter du ikke den eksisterende mast der er placeret få meter væk (node/8843353149) i stedet for at tilføje en dublet?

Det er jo meningen vi skal samarbejde om et fælles kort, ikke skabe oprydningsarbejde for hinanden.

--
Hilsner,
Mikkel