service=drive-way is geen bestaande tag; het is zonder streepje.
Segregated=no lijkt overigens ook niet te kloppen, ik zie een duidelijke stoep aan de linkerkant

Wanneer je dit aanpast, wilde ik je ook meteen vragen de namen van het collegezalencomplex hieronder (een eerdere edit van jou) aan te passen: als er meerdere namen gangbaar zijn, is de juiste syntax
name=(primaire naam)
alt_name=(alternatieve naam)
de *:nl suffix is voor namen in het buitenland (of bijvoorbeeld Fries) die een andere Nederlandse naam hebben

Helaas is er (nog) geen specifiekere tag dan "landuse=quarry" + "resource=*" voor dit type locaties.
De standaardrenderer (Carto) is helaas extreem conservatief in het toevoegen van nieuwe items, is de ervaring...

(Puur ter informatie overigens, wat mij betreft kun je het nu laten staan; dit is zeker niet de enige situatie in Nederland waar naam gebruikt wordt voor een beschrijving, zie bijvoorbeeld way/218533092 )

Ik snap je logica, maar eigenlijk is het niet de bedoeling de name tag te gebruiken voor de beschrijving (en tagging voor de renderer is ook niet toegestaan; immers, deze kaart is maar één van de vele gebruikers van openstreetmap data).
osm.wiki/Names#Good_Practice

Meestal kun je de tag "description" het beste gebruiken in dat geval (het verschil tussen note=* en description=* is dat de laatste bedoeld is voor de eindgebruikers en de eerste puur voor OSM-onderhouddoelen).

Dit heeft soms als consequentie dat het niet onmiddellijk zichtbaar is op de kaart wat er gewonnen wordt, omdat het per "kaartleverancier" verschilt wat - en tot in welke details - zij dingen zichtbaar maken. Om maar een extreem voorbeeld te noemen: de buswegen in Nijmegen zijn niet zichtbaar omdat deze kaartleverancier dat nog niet ondersteunt. Echter, voldoende andere (navigatie- en rendering)software ondersteunt dit wel.

Hallo Carlo,

Ik je vertellen dat ik hierop kwam dankzij zo'n programma, die zich afvroeg of er misschien niet een fietsenstalling of iets dergelijks ontbreekt omdat een fietspad in het niets eindigt ;). Daarnaast dient het ook voor mappers om te zien dat mensen zich niet vergist hebben en er echt niks zit. (In dit specifieke geval is dat vrij duidelijk op de satellietfoto's, dat geef ik toe)

Er zijn meerdere redenen waarom zo'n tag er zou zijn. Lijkt me dus niet nodig 'm te verwijderen, het is niet onjuist: er is daadwerkelijk geen exit. (Maar inderdaad, hij wordt ook gebruikt voor bijna-kruisende-wegen.)

Hi Kogacarlo, vanwaar de verwijdering van noexit=yes op deze node node/6948056420/history ?

"Eigen ervaring" was van vorige changeset :S
Ontbrekende bronnen:
- https://www.breng.nl/nl/nieuws/dienstregeling-2022
- Mapillary

Bronnen vergeten:
1. Survey
2. PDOK luchtfoto's
3. BGT
4. BAG

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