Dag Eggie,
Moet een building:part niet in een building liggen?

(Ik weet niet precies waar de ondergrondse parkeergarage eindigt, maar i.i.g. is er ook een bovengronds deel bij de Zara (rechtsonder) dat nu niet rendert, en de parkeergarage is nu geen building meer (ondergronds of niet))

Oeps, dat was de vorige... Ik bedoelde natuurlijk "wegen toegevoegd n.a.v. notes; vijver toegevoegd"

Vergeten bron bij te werken: ook:
zicht uit trein, PDOK van voorgaande jaren (m.b.t. die container)

Dag Jaap, deze wijziging was twee jaar terug, dus herinneren doe ik het me niet, maar ik weet wel dat ik mij meestal op de highways focus en in mindere mate op de landuse, behalve als ik daar expliciet voor ga zitten (maar het changeset comment doet mij vermoeden van niet: dan had er wel iets gestaan van park uitlijnen). Dus grote kans dat ik hooguit her en der het gras van een (grotere) weg heb gehaald, zonder naar de rest van het park te kijken.

Oh, ik zie dat je het gisteren landelijk hebt aangepast... Wellicht even forumtopicje openen over de noodzaak van een gehele revert of niet?

Hi A67, ik zag dit pas na ik het al aangepast had in een changeset ('t kwam op in mijn validatorregels), maar het perron heeft geen echte naam, alleen een perronnummer. Officieel was local_ref=* de key hiervoor, in de praktijk is het overal ref=*.

public_transport=platform

*fietspaadje

Dag elv5,
Zijn beide banen open, of alleen de uitgaande weg?
Indien alleen de uitgaande weg, moet waarschijnlijk oneway=yes aan deze straat toegevoegd worden
Als dit tijdelijk tweerichtingsverkeer is (of de wijk-ingaande weg ook open is), moet:
- ofwel de wijk-ingaande weg ingetekend worden
- ofwel way/229226255 tijdelijk zonder oneway=yes gezet worden

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