Hello Luxuskirurgi Danmark ApS,

The Danish OSM community prefers to have addresses and POIs separated and addresses to be unique. This is because the authoritative government addresses are imported and maintained daily by the autoAWS bot from data in the official Danish Address Register (DAR).

An imported address is indicated by the address node having an osak:identifier tag. Any edits to address tags or location of such a node will be reverted to the official data unless special measures are taken to prevent that.
So when editing OSM in Denmark, please refrain from adding POI tags to a node carrying an osak:identifier tag or adding address tags in general as the DAR database is a complete and authoritative representation of Danish addresses.

See more about Danish addresses at osm.wiki/Addresses#Denmark & osm.wiki/AutoAWS.

Also the main POI tag for the healthcare facility you have added in this changeset (egrn:categoryName=Healthcare Clinic) is neither common nor documented in OSM, which means that it will not be understood by data consumers and the POI will be of little value to end users. Better options as far as I can judge would be amenity=clinic and healthcare=clinic in combination with healthcare:speciality=plastic_surgery (see healthcare=* & healthcare:speciality=*).

I have changed the POI taking the two points above into consideration in changeset changeset/181715212. Please feel free to correct any mistakes I might have made regarding the nature of the POI.

Regards,
Mikkel (autoAWS bot operator)

Hej Jgdh, velkommen til OpenStreetMap og tak for dine bidrag.

Det ser ud til at du allerede er blevet opmærksom på at adresser i Danmark (tags af formen "addr:*") importeres fra det officielle adresseregister "Danmarks Adresser" (også kaldet DAR). Det er ikke tags man bør tilføje manuelt til almindelige interessepunkter. Dette vil under normale omstændigheder forårsage at der eksisterer flere adressenoder med samme vej og husnummer, hvilket giver en tvetydighed når adressen slås op. For Mosevej 1A, 6430 Guderup er den importerede adressenode; node/957756520.

De importerede adressenoder bliver løbende ajourført i forhold til DAR, derfor er det normalt en dårlig ide at ændre ved dem overhovedet, de lever så at sige sit eget liv i OpenStreetMap. Eventuelle ændringer komplicerer den automatiske opdatering, og disse ændringer risikerer alligevel at blive overskrevet med de data der er aktuelle i DAR.

Hvis en adressenode er placeret forkert, bør det rapporteres til den autoritative myndighed, som er kommunen hvori den ligger, således at fejlen kan blive rettet i DAR. Se vejledning fra DAR om dette på https://danmarksadresser.dk/om-adresser/gps-og-adresser/.

Ønsker du at tilføje et interessepunkt eller andre tags på adressenodens lokation, så opret et nyt objekt og tilføj tags herpå. Dette er en afvigelse fra den generelle OpenStreetMap-fremgangsmåde som du kan se dokumenteret i den internationale dokumentation, og som nogle værktøjer endda foretager automatisk. Find mere information fra det danske OSM-fællesskab om danske adresser på OSM-wikien; osm.wiki/Da:Adresser.

Se mere generelt om DAR på http://danmarksadresser.dk/, og detaljer om integrationen med OpenStreetMap via autoAWS-værktøjet på osm.wiki/AutoAWS.

Velkommen igen, og god mapning. Mikkel

Additionally, all address points with osak:identifier are imported and maintained daily by the autoAWS bot from data in the official Danish Address Register (DAR). Any edits will be reverted to the official data unless special measures are taken to prevent that.

See more about Danish addresses at osm.wiki/Addresses#Denmark & osm.wiki/AutoAWS.

Det var nu ikke så meget for de her småting, dem havde jeg nok fået styr på, da det er meget tæt på hvor jeg færdes.

Jeg er mere interesseret i lige at få generel opmærksomhed på ikke at ændre, med mindre ting kan bekræftes værende ukorrekte. Der mener jeg ikke at et ortofoto som er ~1 år gammelt vægter særligt højt i forhold til et objekt som nogen har gjort sig den ulejlighed at tilføje siden ortofotoet blev optaget.
Det er brandærgerligt når detaljer forsvinder på denne måde, det synes jeg ikke lever op til samarbejds- og konsensusånden i OSM.

Med hensyn til overflader forstår jeg ikke logikken i at en ændring af highway-værdien skulle have nogen som helst indflydelse på validiteten af et surface-tag. Hvis nogen har set grus eller græs og tilføjet tagget, så er det vel gyldigt, medmindre det kan bekræftes at overfladen har ændret sig siden den observation?

I min OSM-boble er highway=footway helt generelt til steder hvor man primært færdes til fods. Det har aldrig været forbeholdt fortove, jeg husker endda en tid hvor highway=path ikke eksisterede (godkendt i 2008) og alt til fods var footway eller cycleway+foot=yes.
Jeg synes wikien bekræfter dette, se f.eks. highway=*#Paths (footway:"includes walking tracks and gravel paths.") og osm.wiki/Sidewalks#History. Hvis man eksplicit vil tagge en footway som et fortov så findes footway=sidewalk til det, og et selvstændigt stiforløb uden en vej som vi taler om her ville så kunne refineres med footway=path.
For mig indikerer highway=path at vejbrugen ikke er primært for én type trafikanter (som {foot,cycle,bridle}way), men at brugen er lige mellem de taggede brugere (foot, bicycle, horse). Uden brugere er path endnu mindre eksplicit end *way-tagsne, og wikien fraråder det da nogle routere så vil undgå at anvende den pga. manglende information.

Hejsa i Viborg.

Hvilke KDS-kort og geodata er det konkret du tegner efter her? De virker ikke til at være aktuelle.

Du har fjernet ting i mit lokalområde i Tjæreborgs Gamle Grusgrave som er nyetablerede i sommeren 2025 og som blev tilføjet OSM i 2025-06, altså efter ortofotos 2025;

* ny sti mod Ejlif Krogagers Vej; way/1410598896
* stier om sydlige sø inklusiv gangbro over grøft (som godt nok er oversvømmede på ortofotos 2025 men det er jo altid et øjebliksbillede), de var omlagte og farbare i 2025-06 (@mikini/traces/12298513) og er stadig vedligeholdte og fuldt farbare ved survey i denne uge; way/880803830 & way/880803820
* hegn, som godt nok er omlagt omkring de nye bygninger, men som stadig delvist eksisterer langs mark/sti; way/955886905

Du fjerner også uden videre surface på de fleste stier; way/386795074, way/1410598897, way/484439751, way/96321785, way/414811075, way/96321790

Jeg synes det er lidt bisset bare at komme tromlende på den måde. Tjek i det mindste om seneste redigering er efter det ortofoto der bruges som kilde.
Det skulle jo gerne være muligt at udvide detaljegraden uden at risikere at det bliver tilbagestillet til status på senest tilgængelige ortofoto.

Hilsner,
Mikkel

Helt ok, man lader sig nemt rive med, men vi skulle jo helst arbejde i samme retning ;).

Super med reverten, det ser rigtigt ud. Havde ikke lige mulighed for selv at se på det.

Havde også et track på lager af dette stykke, men det er ikke særligt præcist så jeg afventer lige at kunne komme forbi igen før jeg gør mere (mener også nogle stier mod Østre Havnevej er fjernet);
@mikini/traces/12269163

Hejsa.
Har du været på stedet for nyligt?
Mine redigeringer i [changeset/175781292][1] var lavet på baggrund af en runde dernede i december under færdiggørelsen af etape 2 af [omdannelsen til "Byens Bjerg"][2].

Første etape ved friluftscenen blev lavet i foråret 2025 og [indviet d. 8. august 2025][3]. Mens anden etape omkring legepladsen [blev indviet d. 18. januar 2026][4].
Så det der kan ses på GeoDanmark Ortofotos fra foråret 2025 er ikke aktuelt. Bl.a. er indkørslen til musikhusets sceneindgang fra Englandsgade som, du har gentegnet, lukket helt og fjernet, så der nu kun er adgang med bil via den nye indkørsel med bom fra Havnegade.

--
Hilsner,
Mikkel

[1]: changeset/175781292
[2]: https://www.esbjerg.dk/planer-projekter-og-trafik/byudviklingsprojekter/esbjerg-bypark
[3]: https://jv.dk/esbjerg/velkommen-til-byens-bjerg-denne-dag-indvies-foerste-etape-af-byparkens-store-forvandling
[4]: https://jv.dk/esbjerg/noget-helt-nyt-aabnede-i-byparken-og-folk-dukkede-op-i-hobetal

Hi Mateusz,

Thank you for the attention.

I don't recall deliberately choosing that scheme or having studied the differences and controversies between repair=yes, *:repair=yes and service:*:repair=yes before.
My hunch was therefore that iD had made the choice for me from a simpler UI choice, but I can see that at least the current v2.37.3 chooses the service-variant instead when using the UI to select just "repair" in "Bicycle Services". So I can't explain why I ended up with the least used variant.

I am leaning towards the simpler repair=yes because with shop=bicycle the context is present to defer unambiguously what kind of repair it is about.
That is also the vibe I get from from the text in the “questioned” box warning in documentation of [repair][1] and [*:repair][2]; "It's not explained why shop=* + repair=* isn't sufficient".

But it gets a bit confusing when looking at shop=bicycle which in ["Tags used in combination"][3] starts by explaining to use repair=yes solely, but then goes on to say completely the opposite in the "Additional keys" chapter; "if a bicycle shop does not have a service:bicycle:repair=* tag, nothing has been stated about its repair service".

This latter interpretation seems to deviate from the traditional use of "repair=*" on shops and amenities to indicate repair services.
Is it the current recommendation to do so for shop=bicycle and vechicles (ie. shop=car & shop=car_repair)?

I cannot find that documented anywhere, except maybe it could be the intention behind the chapter ["Car, vehicle and bicycle services (including repair)" of repair][4]. although I find it very unclear.

For now I chose to follow your and iD's lead and changed this to the service-approach in [changeset/175644314][5].

--
Regards,
Mikkel

[1]: repair=*#Indicating_that_a_specific_type_of_item_is_repaired
[2]: osm.wiki/Key:*:repair
[3]: shop=bicycle#Tags_used_in_combination
[4]: repair=*#Car,_vehicle_and_bicycle_services_(including_repair)
[5]: changeset/175644314

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=[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