Hej antonr,
Kan du hjælpe Lostmonkey med denne note?
osm.org/note/3193655

Jeg kan se at Væksthusene har flere underobjekter og da de hver er en del af huset, så kommer de hver til at fremstå som enkelte museer.

Er det noget der kan gøres for at få bygningen udenom til at være museet og de enkelte bygningsdele indeni som være en del af en samlet enhed?

Men som du selv peger på i wikien så er acces implicit givet via lovgivning. Her er det Danmark jeg har linket til.
osm.wiki/OSM_tags_for_routing/Access_restrictions#Denmark

Det er op til routing-programmerne at have styr på denne del.
Du kan jo risikere at et land som "Fantasiland" finder på at ændre lovgivningen for trunk og så skal du ud og ændre alle steder i OSM fordi du har sat access-tagget på.

motorroad er i DK defineret som Motortrafikvej og Motorvej.

I færdselsloven i DK er definitionen:
"17. Motorvej og motortrafikvej:
vej, som er forbeholdt færdsel med motorkøretøjer, og som med færdselstavler er afmærket som henholdsvis motorvej og motortrafikvej."

Og ikke mindst:
"§ 44. Færdsel på motorvej samt på tilkørsels- og frakørselsvej til en sådan vej må kun ske med motorkøretøjer, som på vandret vej kan og må fremføres med en hastighed af mindst 50 km i timen."

Dette betyder at man skal benytte køretøj på denne strækning.
Altså ikke noget til fods eller på cykel, der kører mindre en 50 km/t

Så derfor er det, som osmviborg bemærker, ikke nødvendigt at overinformere med tags, da alt er implicit givet.

Hvorfor footway i skoven?

osm.wiki/Tag:highway=footway?uselang=da

Normalt ville man vælge path i forbindelse med stier i skoven, da der også vil være cykeltrafik.
Med mindre der er skiltet af.

Rettet i osm.org/changeset/120943973

Men vi kan vel være enige om denne mapning?
osm.org/way/1059862237

Ahh.. det kan jeg godt se nu. Havhusene er vist ikke lige "town"-størrelse endnu.
Jeg fik det fra osm.elgaard.net så den må levere det forkerte tag.

https://www.retsinformation.dk/eli/lta/2021/1986#idd8a31e5c-14c7-4f6d-a9d9-388a41680b4c

Den bliver især brugt af de omkringboende ud fra mine egne erfaringer, for ved højvande er det svært at benytte kysten.
Desuden er der ikke markeret noget om privat eller anden skiltning i området. Den bliver vedligeholdt med græsklipning, så det ser ud til at grundejerforeningen holder den vedlige.

Kunne du så ikke dele skovområdet op i to og give luft til alleen mellem dem?

Jeg har da ikke noget imod at du flytter punktet lidt til højre.

Helt fint at du spørger.
Jeg kan ikke svare dig på, hvordan programmer og brugere agerer i forhold til POI, det kræver specialviden og indsigt i en helt særlig grad. Måske ved nogen noget om det på Talk-dk?

Jeg undskylder gerne at jeg, ligesom mange andre mapppere, ikke lige fik angivet kilden til mine ændring.

Det er baseret på lokal viden om stedet og jeg har stået udenfor butikken og set det. Jeg kan sende dig et billede af stedet, hvis det giver mere ro.

Hvad er grunden til din pludselige historiske interesse i mine ændringers kilder og ikke andre mapperes ændringssæt?

Fordi punktet er flyttet hen til der hvor butikken fysik ligger.
Til højre for opgangen til nummer 48 set fra gaden.

Blot et godt råd.
Kunne du ikke være lidt mere åben med kildeangivelser?

Eks. Æblelunden, som viser sig at være en ting fra en hjemmeside:

http://smagpaaaarhus.dk/byhave/aeblelunden-i-skejby/

Du kan sætte den slags som kilde i dit ændringssæt eller som web-tag på skoven. Ellers kommer du til at opleve, at dine rettelser bliver sat tilbage eller fjernet af andre mappere, som ikke har din viden om stedet og kilderne.

Jeg ved du følger med på Talk og her kan du se at selv Lufthavnen ligger et forkert sted.
Almindelige brugere er derfor afhængig af datakvaliteten og uden adresseoplysninger i POI, så mangler disse data i applikationerne.
Det er stadig OSM der leverer data til brugerne.

Ja og netop derfor bør POI indeholde adresseoplysninger på databaseniveau.
POI er jo et objekt på linje med alle andre objekter i databasen og egenskaben Adresse er en af dem, der kan gives til den.
Det kan ikke være slutbrugeren, der efter at have fundet sit POI, skal skifte til en anden applikation for at finde flere oplysninger.
Jo flere enkeltoplysninger, der kan findes i et POI, jo enklere er det for applikationerne at finde eks. adressen.
Eks. http://openpoimap.org/ som viser POI udfra OSM-data. Kigger på i eks. Tyskland, så findes adressen også på POI-objektet. Tilsvarende er alle adresseoplysninger rydder i Danmark.
Så der er en tydelig afvigelse med POI-data i DK i forhold til resten af verden.
Jeg er stadig ikke overbevist, at metoden med at man i DK fjerne adresseoplysninger på POI giver nogen mening i forhold til OSM i det hele taget, eller om det er noget vi i DK er blevet "opdraget" til af en eller flere progressive mappere.

Hvis jeg i OSM søger på 'Bruuns Antikvariat', så får jeg

"Boghandel Bruuns Antikvariat, Herluf Trolles Gade, Trøjborg, Aarhus Ø, Aarhus, Aarhus Kommune, 8000, Danmark"

Gadenavnet kom med her.

Så langt så godt. Nu skal jeg så blot finde ud af hvor på gaden jeg finder punktet. Havde det været Frederikssundsvej ved Kbh, så ville det tage lidt tid finde.

Et eller andet siger mig, at man skal have den rette søgemaskine, for at få kombineret POI og adressepunkt.

Kan jeg få dig til at søge på et andet antikvariat i nærheden nemlig 'Clemens Antikvariat' i OSMand? Dette punkt er der ikke rørt ved i 9 år.
Får du "Tordenskjoldsgade 59", så tilføjer OSMand selv info.

Hvis det er tilfældet, så skal du altså have adgang til Planet-filen, for at lave udtrækket af POI, da du skal kende det nærmeste adressepunkt for den søgte POI.

Og i wikien omkring shop:

osm.wiki/Key:shop

Der er adresse faktisk en af mulighederne. Så der er ikke rigtig noget argument for at slette adresserne på POI

Ser man på wikien, så er det kun bygninger man ikke vil have adresser på i DK:
osm.wiki/Addresses