Tip: als je te weinig tekens hebt (limiet: 256 tekens), kun je altijd aanvullende informatie als opmerking eronder zetten (waar ik nu mijn reactie schrijf). Maar meestal is dat niet nodig, een korte beschrijving is meestal afdoende

Top! Wellicht een kleine suggestie, maar in OSM werken we zo min mogelijk (liefst: helemaal niet) met afkortingen. Dus St. -> Sint

You marked the entire island as a coffee house...

missende bron: survey

En welkom bij OSM / in Nijmegen :)

Wellicht goed om toe te voegen betreffende het gebouw in het Centrum (van Broeckhuysenstraat 55): bij mijn weten is die locatie niet open voor "bezoekers" en dient het vooral als soort-van server/apparatuurruimte (geen idee hoe dat precies heet), zonder al te veel personeel naast service/onderhoud, en in dat geval is waarschijnlijk building=service de meer specifieke tag voor het gebouw. (Dus niet landuse=service)
building=service .
Mocht er toch veel personeel vaste kantoortjes hebben (en dit de hoofdfunctie zijn), dan is building=office of (breder) building=commercial een optie. Beiden zijn meer specifiek dan building=yes.

building=* beschrijft het gebouw zelf, landuse=* ligt om (bijvoorbeeld) een gebouw heen. Landuses beschrijven dus het doel van een gebied (waar gebouwen en/of omgeving bij kunnen horen), building tags het doel van een gebouw (maar merk op: gebieden èn gebouwen kunnen gecombineerde doelen hebben, bijvoorbeeld woon- en winkelfuncties)

Dankjewel! Ach, klein foutje ;). Op basis van de recentste satellietfoto's (satellietdataportaal.nl) gok ik dat het (bijna) voltooid is

De tag opening_date (op weg 979353274 ) geeft aan wanneer de site gereed gaat zijn (en dus geen constructiesite meer is). Omdat deze is toegevoegd op september 2021 met een datum in 2020, vermoed ik dat je ofwel de key "start_date" bedoelt (en iets anders dan landuse=construction, ofwel een datum in de toekomst :) )

opening_date=*

En bron: BAG

Minus de Mapillary bron... dat was de vorige changeset, hier niet gebruikt...

Hi S0796,
In Nederland maken we onderscheid tussen het adres en het gebouw.

Ik kan het niet heel goed uitleggen, maar het gebouw is een tastbaar object, bestaande uit stenen, met een bouwjaar, een vorm etc.
Een adres daarentegen is een administratief iets. Wat er gevestigd is, is gekoppeld aan het adres, en niet aan het gebouw. Daarom zijn adressen altijd losse nodes met daarop bijvoorbeeld wat er gevestigd is, terwijl het gebouw de vorm, bouwjaar etc. van het stenen object betreft. Graag niet verwijderen, en deze ook weer terugzetten waar je ze verwijderd hebt. Dankjewel :)

(Om in dit specifieke voorbeeld te noemen: het gebouw zelf is niet religieus, en het gebouw zelf heeft geen telefoonnummer of website. (Een wiki-pagina over het gebouw kan echter wel bestaan, bijvoorbeeld) Het adres daarentegen wel, op dit adres zit een moskee gevestigd, met een religieuze functie, een website, een telefoonnummer etcetera. Stel het object brandt af, dan bestaat de organisatie nog steeds. Stel de organisatie gaat failliet, dan komt er een ander iets op het adres te zitten).

+ bron: survey

Reverted in changeset/114040686

Eenrichtingsverkeer bestaat nog steeds, zelfs al lijkt het onlogisch. Ga maar kijken.

+ bron: BAG

Je hebt het aangepast zie ik, top! Ik denk echter dat je er nog ééntje gemist heb:
way/947395327

+ bron: Mapillary (2020-2021 data)

Geen probleem, daar is deze feedbackfunctie voor :)

access=* is letterlijk alles. Daaronder heb je vehicle=* (alles behalve voetgangers, paarden, skaters en skieërs, welke foot=*, horse=*, etc als tag hebben), daaronder heb je weer motor_vehicle=* (waar bijvoorbeeld auto's en brommers wel, maar fietsers niet onder vallen)

Maar heel veel tags hebben ook standaardwaarden. Zo is het op een voetpad niet nodig om foot=yes te zetten, en op een snelweg is foot=no de standaard. Je tagt pas als het afwijkt van de normale situatie (bijvoorbeeld als dit een privétrap was)

Hallo S0796,
access=yes betekent dat je er ook met de auto en boot vanaf kan gaan. Hoewel technisch (i.i.g. eenmalig) mogelijk, lijkt mij dit niet het beoogde doel van deze trap, en tweerichtingsverkeer is het dan zeker niet. Dus access=yes is hier incorrect.

Iets serieuzer: het lijkt mij niet nodig om access-tags op deze trappen te hebben. foot=yes is geïmpliceerd en hoeft niet getagd te worden, terwijl andere verkeersdeelnemers af moeten stappen (en dus voetgangers zijn) / om moeten rijden.

Zou je de tag 'access=yes' weer kunnen verwijderen? Dank!

(Het toevoegen van de handrail is wel handig, dank daarvoor!)

Dankjewel voor je reactie! En handmatige bronnen (zoals "survey", "Mapillary", "BAG") voeg je dan wel handmatig toe?

Bron: zonder RCE en survey, met Mapillary...

(Mocht iemand weten hoe je JOSM zegt dat hij de bronnen niet moet herinneren van de vorige sessie......?)