Klopt, eenheden voluit schrijven is "highly discouraged" osm.wiki/Map_features/Units

& bron survey (op basis van genoemde belachelijke navigatieinstructies :P )

Hi Leo, dankjewel voor het attenderen! Ik was daar inderdaad de oneway vergeten toe te voegen.
Over de classificatie van die weg kan ik helaas geen zekere uitspraken doen, dat moet ik aan een lokale mapper overlaten die de situatie beter kent. (Maar het klinkt mij best aannemelijk dat residential de weg niet goed beschrijft)
Nogmaals dank!

Ik zie deze nu pas; heb even een topicje gestart:
https://forum.openstreetmap.org/viewtopic.php?pid=856397

Dag Marein, gegeven dat er bij mijn weten nog altijd C16 (verboden voor voetgangers) aan beide zijden van het pad staan, haal ik deze foot=* tags er weer vanaf. Het bestaan van het pad is echter inderdaad waar (al sinds zo lang ik mij kan herinneren worden er af en toe voetgangers bekeurd :) )

Zie o.a. (slecht te zien, maar de enige foto die ik kon vinden die nà deze discussie gemaakt is) helemaal links tussen de bomen op https://www.mapillary.com/app/?pKey=599131124572085 en (van de andere kant) een paar weken voor deze discussie: https://www.mapillary.com/app/?pKey=156258026645414

changeset/117656047

Dag Nonzz, de tag capacity geeft aan hoeveel auto's er tegelijk kunnen opladen. Voor het vermogen is de tag:
charging_station:output=xxx kW
Ik neem aan dat je de laatste bedoelde?

Betreffende:
> Is dit goed gemapt?
Ik zou het niet anders gedaan hebben :)

Ik zal de fixme verwijderen

Dit ziet er goed uit!

Hallo Martien,

Dat klopt, de BAG imports zijn echt iets puur Nederlands, wij mogen die data van de overheid m.b.t. gebouwen en adressen overnemen. Er zijn wel mogelijkheden met "building:part", maar daar ben ik geen expert op.

Wat betreft het restaurant: ook dat is inderdaad een conventie in Nederland die niet door alle landen gevolgd wordt. Bedenk het eens zo: in een hypothetisch appartementencomplex zit één winkel op de begane grond en 20 appartementen erboven. Stel je koppelt de winkelgegevens aan het gebouw, dan zijn die 20 appartementen ineens ook onderdeel van de winkel, terwijl dat in werkelijkheid niet is. De winkel is slechts één van de 21 "adressen".

amenity=restaurant mag ook niet building=* vervangen. Immers, het restaurant zit 'in' het gebouw, het restaurant 'is' niet het gebouw. Het gebouw is puur die stapel aan elkaar geplakte bakstenen. Het gebouw heeft een bouwjaar, een kleur, een vorm, etc.
Wat er in het gebouw zit, is echter vluchtig: het restaurant kan morgen weggaan en vervangen worden door een bouwmarkt en het gebouw is nog precies hetzelfde. De conventie (in Nederland) is dus ook om de "benutting" aan de adresgegevens te koppelen. In dit geval zou - aannemende dat het restaurant wel degelijk een los gebouw is - de volgende tagging correct zijn:

Het gebouw zelf:
building=yes
ref:bag=268100000026066
source=BAG;eigen kennis
source:date=[de dag dat je zag dat het twee gebouwen waren]
start_date=1967 (bouwjaar)

Het adres:
addr:city=Nijmegen
addr:street=Kanunnik Faberstraat
addr:postcode=6525TP
addr:housenumber=7
source=BAG
source:date=2019-06-04
amenity=restaurant
name=De Drukkerij

(Merk ook op dat we beschrijvende namen weglaten: Restaurant De Drukkerij wordt "De Drukkerij", want dat het een restaurant is volgt uit amenity=restaurant)

Helpt dit?

Goededag Martien, als u er zeker van bent dat dit twee gescheiden gebouwen zijn, d.w.z. op geen enkele verdieping is het mogelijk van gebouw A naar B te komen, dan kunt u dit wellicht doorgeven bij de BAG registratie. Zo niet, bestaat het risico dat deze edit bij de volgende BAG import automatisch ongedaan gemaakt wordt.

Daarnaast hoort de naam van een restaurant op de adresnode, niet op het gebouw. Het gebouw is namelijk geen restaurant, het restaurant zit daar slechts gevestigd. (En momenteel staat het restaurant als appartement aangegeven)

Dag dvdhoven, foutje waarschijnlijk, maar volgens mij ben je een bron vergeten, zij het survey, zei het een site met de routes erop ;)

De bron "survey" was nog van de vorige changeset, excuus. En voor de oversteek bij nr. 19 heb ik Mapillary gebruikt om het G12a bord te spotten

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