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

Ruten findes nu som en ny relation; relation/12128557

Synes nu at der er indikationer[1][2] på at dette er (blevet?) en fint opmærket rute.

[1]: https://genforeningen2020.dk/arrangementskalender/?place=Kolding+Kommune&activity=4094
[2]: https://facebook.com/graensestien/