piebro/osm-data huggingface dataset:
boototter (2020-05-23 13:33:41+00:00): Heb ook een aantal mp's laten staan, bijv. rond tuindersvereniging 'de Egelantier'.
Wel zal ik moeten studeren op de moeder-kind relatie, naar ik aanneem op geneste mp's. Wat relaties overnemen voor consequenties heeft valt nog buiten mijn beeld.
Een vraag: zowel binnen mp's als los heb ik landuse=bushnell geplaatst. Ongeveer de enige plaats in de wijk waar ze nog overvloedig voorkomen, elders als sociaal onveilig verwijderd. Zijn we dus enorm blij mee. Maar die zijn geen van allen gerenderd; is daarvoor een alternatief?
Ook in de nieuwbouw zuidkant Bijlmerdreef zijn ze, zij het getemd, als essentiële groenvoorziening geplaatst. Dat gebied heb ik al voor het grootste deel op foto's en schets, dus ook daarvoor noodzakelijk.
eggie (2020-05-23 13:36:53+00:00): Hersteld.. Klik op de achavi link en kijk wat er in werkelijkheid is gebeurd.
Je kunt weer mappen. 
Ik had nu pas in achavi gekeken en niet naar de zuidelijke wijken. Je had een grasveld van de Elsrijkdreef verplaatst naar een ander stadsdeel. Ja en daar zat het e.e.a. aan vast o.a. het stuk bos.. Vandaar al die bomen op het gras en in het water bij de gooise weg. 
Eggie
eggie (2020-05-23 13:39:31+00:00): .. en op de vraag over bosschages.. Ik gebruik weinig smaken. Meestal gebruik in natural=scrub. Heel veel andere tags renderen (nog) niet... zoals de landcover tagging . dat zijn proposals in de hoop dat het ooit wordt overgenomen.
boototter (2020-05-23 13:43:09+00:00): Oei, zag dat ik per ongeluk een knoop had verplaatst. Meteen daarna op <Ctrl>+Z gedrukt voor ik verder ging.. Punt visueel weg, terug naar echte plek, maar verder dus niet.
eggie (2020-05-23 13:51:16+00:00): Wanneer je een vlak per abuis verschuift.. komt vaak voor.. krijg je altijd een waarschuwing als popup. Dan altijd CTRL Z doen als het niet de bedoeling was. 
Zo heeft iemand ooit een hoek van een kerk verschoven vanuit Brazilië over de rest van de wereld.Ik weet niet of dat nog kan?  
Toen hadden we een vreemde bruine kaart een aantal dagen.
boototter (2020-05-23 13:52:10+00:00): Ah, daar ben ik lang niet geweest. Kun je de datum achterhalen, want dat moet één van de eerste keren dat ik inlogde bij OSM zijn geweest. Dat ongelukje met die piek vanaf Geldershoofd was van vandaag in iD, dat grasveld naar naar de F-buurt is volstrekt onbewust gebeurd, en lang terug ook.
boototter (2020-05-23 14:11:54+00:00): oké, dan zal ik de landuse=bushnell binnen het ProfJvSPark veranderen in natural=scrub, daar klopt dat voor het grootste deel wel.
Dat geldt voor Nieuw Grunder (Galant- en Glitterstraat, Gaandeweg) echt niet, daaraan is eerst de heggentrimmer, toen pas de bosjes zelf ontworpen. Uiterst strak bijgehouden, een belangrijker blikvanger dan de rijen bomen die er middenin zijn geplaatst.
eggie (2020-05-23 14:24:30+00:00): Die verplaatsing was gewoon in deze changeset van 13 uur terug...  Het was geen node maar een vlak. natural=grassland.. daar loopt normaal een paadje overheen. Maar dat pad ligt aan de Elsrijkdreef. 
Bij een node verplaatsen kijg je geen waarschuwing, maar bij een vlak verplaatsen dus wel. Dan had je onbewust iets te veel geselecteerd of de selectie stond nog actief. Dan denk ik "gloeiende"  en  druk dan steeds op ctrl z.
boototter (2020-05-23 16:36:49+00:00): shit, totaal niet doorgehad. Heb heel in het begin van de edit inderdaad wel even gekeken (dacht ik), als ongelukje omdat ik (het gebrek aan) de mogelijkheid tot pannen in JOSM nog niet kende.
Dank voor ontdekken en herstellen.
eggie (2020-05-23 16:39:10+00:00): Het is nog niet helemaal goed. Geef me even de tijd want ik zie nog meer schade..
even niet mappen tot ik het vrijgeef.
Kijk in achivi dan zie je wat ik bedoel.
eggie (2020-05-23 16:42:44+00:00): Woning EGoli 99 teruggezet
eggie (2020-05-23 16:47:46+00:00): Uitschieter naar noordoosten van grasveld teruggeplaatst

Volgens mij was het dit wel.
Hij kan weer.
Eggie
eggie (2020-05-23 16:48:44+00:00): De effecten van al die crossing ways kun je nog een tijd zien bij in- en uitzoomen
eggie (2020-05-23 16:50:09+00:00): Pak je nog wel de Bijlmervijver aan? Al die waterinfo eraf halen.. De watertags zitten in de relatie bij een mp.. 
Je zult anders echt geen eiland zien.
eggie (2020-05-24 07:23:59+00:00): Ik heb van al die vlakken water waterway-ditch verwijderd.. Dat is iets voor een niet gesloten lijnelelement en hoort niet op een vlak.
Het bos en gras heb ik laten aansluiten aan het water daar. Dat gaat gewoon met één muisklik. 
De trucendoos van josm
boototter (2020-05-24 13:10:44+00:00): waterway=ditch verwijderd kan ik voorlopig mee leven; het feitelijke probleem is, dat ze als vlakken getekend zijn, terwijl ze onderdeel zijn van één watersysteem, met twee inlaten en een uitgang. De duikers daartoe komen echt nog aan de beurt.
Dat levert een ander probleem op. Uit jouw beschrijving bij 85669230 begrijp ik, dat multipolygons net als paden niet geraakt mogen worden. Wanneer ik (wanneer het park en het relatief eenvoudidge Nieuw Grunder af zijn) aan de Bijlmerweide ga beginnen, kom ik in de problemen met de ontbrekende duikers. Moeten die onderdeel worden van één multipolygoon (die dan door de hele Bijlmermeer, dus twee wijken zou moeten worden volgehouden) of kan ik dat op een of andere manier splitsen, zodat het én beheersbaar blijft én toch die waterway in stand kan worden gehouden? 
NW van Geerdinkhof heb jijzelf ook een MP gemaakt van water en eilandje, die noordoostelijk daarvan is nog chaos. 
Ik ga er van uit, dat met OStreetM dáár de primaire aandacht niet op ligt, maar het is een waterweg en de tags zijn beschikbaar.
Alleen, hoe dit te doen in behapbare brokken.
Voorlopig is het ProfJvSPark nog niet af, ideaal leer- en oefenmateriaal, maar ik kijk vanzelfsprekend al wel vooruit om te kunnen plannen.
eggie (2020-05-24 13:32:15+00:00): Een waterway=ditch evt. icm een tunnel=culvert zijn lijnelementen en maken geen onderdeel uit van een mp. Een mp alleen gebruiken als een vlak is ingesloten in een ander vlak.. In alle andere gevallen niet nodig. 
Voorlopig zou ik gewoon beginnen met invullen van de landuse  en je niet te veel aan trekken van mp's.
Dat kan later altijd nog. 
Het ligt er jaren zonder mp's dus een paar dagen kunnen er nog wel bij. :)

Al die wateren verderop in de wijk hebben geen mp's nodig.
Een lijn met waterway=canal  stream of ditch mag wel gewoon dwars door die vlakken heen getrokken worden van duiker naar duiker.
De naam van het water gaat dan op zo'n lijnelement. soms dwars door het vlak.. dan weer als duiker van vlak naar vlak.

Dat kleine eilandje is niet van mij. Dat heb ik ooit een keer beter gelegd. Het is oude 3dshapes, maar inderdaad een mp. 
Succes,
Eggie
boototter (2020-05-24 14:03:46+00:00): Besefte opeens, dat ik vergelijkingsmateriaal had, dat veel vraagstukken zou kunnen oplossen: in een vergelijkbare situatie ('grubbezee´) zag ik, dat water in een mp mag aansluiten op water uit 3dshapes. Dat moet dan ook op blokjes water onder een duiker gelden, nietwaar? Anders dan de Grubbezee heeft het water verder geen naam. 
Ik zal me (later...(project 3)) in eerste instantie beperken tot het bijwerken van de ontbrekende of foute delen op de Bijlmerweide  als duikers, drains en weggelaten stukken sloot.
boototter (2020-05-24 16:09:07+00:00): Op zich ben ik trouwens niet bang voor multipolygonen. Anders benoemd en specifieker geparametriseerd, maar in structuur niet heel anders dan groepen in grafische programma's of bijv. (geneste) <div> elementen in (x)html. 
Maar... welke elementen wel of niet tot een mp kunnen behoren, hoe om te gaan met een amenity (bijv. een niet afgeschermd deel van een grasveld dat als kinderspeelplaats is bestemd) zal nog wel wat vragen tot assistentie oproepen. De wiki is daar niet echt duidelijk over.
eggie (2020-05-24 16:13:35+00:00): Speelplaatsen en pitches zet ik ook in een mp.. want anders zie je alleen het symbool op afgeleide kaarten.
boototter (2020-05-26 10:56:20+00:00): Je had het eerder over de trucendoos van josm, om vlakken van verschillende signatuur te laten aansluiten. Nu heb ik er verschillende geprobeerd, maar de juiste toets(combi) heb ik nog niet kunnen vinden. Met de giga-hoeveelheid vlakken en vlakjes is dat wel zeer welkome kennis.

Kun je een zo aaneengesloten geheel ook weer scheiden, wanneer er nog een strook van iets anders tussen moet worden gevoegd?
eggie (2020-05-26 11:39:00+00:00): Iets scheiden doe je door de G toets te gebruiken na selectie van een node of het hele lijnelement. Dan zijn wel alle lijnen los van elkaar.
De sneltoetsen van JOSM vind je hier
https://wiki.openstreetmap.org/w/images/9/99/JOSM_Keyboard_shortcuts_cheat_sheet.png

Met de trucendoos bedoel ik de plugins die je kunt inladen in josm
F12 en dan dat symbool van die contactdoos.
Water inbedden in landuse  doe ik met 
Cutout Overlapping Polygons. Na installatie vind je die onder gereedschappen. 
Soms moet je opnieuw josm opstarten.
https://wiki.openstreetmap.org/wiki/JOSM/Plugins

Groet,
Eggie
boototter (2020-05-26 18:42:28+00:00): Onder die naam vond ik de plugin niet in de lijst. Bedoelde je deze?https://wiki.openstreetmap.org/wiki/PolygonCutOut
eggie (2020-05-26 18:59:43+00:00): Klopt... dat is 'm.... Van KiaaTiX
boototter (2020-05-28 21:44:56+00:00): Ten eerste even dank voor je begeleiding tot nu toe. Veel geleerd; nu ook het gevoel, dat ik wat zelfstandiger aan de slag zou kunnen zonder de boel in één beweging te verwoesten.
Twee vragen mbt het stuk Bijlmerweide boven het JvSPark.
Dat was ook zo'n bovenliggend leisure=park, hoe ik dat tot multipolygoon heb gekregen is me een raadsel, maar zo staat ie nu in JOSM met twee elementen water erin (die open lus  NW van Gouden Leeuw). Er is vast ook wel een manier om dat weer te splitsen zonder schade aan te richten, maar die ken ik ook nog niet .

Ten tweede: op het ogenblik ben ik alle lijntjes keurig aan het leggen op die van de GBT omtrekgericht. 't  Ziet er prima uit, maar er zijn dan veel meer golvende lijnen  dan in wat ik aantrof. Is dat technisch wel verantwoord? Processorcapaciteit, opslag, laadtijd...
(Ben dus ook al aan de kop van de Bijlmerweide begonnen, lekker grote vlakken ipv alleen maar gepriegel, en het voelt vanaf hier toch als doorlopend gebied).
Kan ik trouwens voor de Bijlmerweide de tag veranderen? natural=grassland past veel beter bij het karakter dan landuse=grass. Er wordt maar eens per jaar in hooitijd gemaaid naast twee keer de berm van fiets- en wandelpaden.
eggie (2020-05-29 08:09:04+00:00): Voor die grote omtrek van de Bijlmerweide een keus maken.
Je kunt m gebruiken voor alleen de leisure=park en name=.... 
topnym (deprecated) , landuse=grass lancover=grass verwijderen.
Het is dan weer alleen de functie. Dan apart verder de landuse=grass of natural=grassland (kan ook)  invullen.
Dat iets een mp wordt kan komen omdat je iets hebt uitgesneden met cut out polygon van KiaaTiX.
Om iets echt in een vlak uit te snijden doe ik liever handmatig. Is er geen mp nodig dan gebruik ik de plugin. 

In het water west van de kinderboerderij zie ik weer eilanden (bomen in het water) niet niet in een mps liggen. Dat water moet dus de outer worden en de eilandjes de inner. 
Er kunnen meerder mp relaties staan op een lijn. Iets kan inner maar ook outer zijn als er weer een vlak inligt.
Geloof me.. De meeste mappers komen hier niet eens aan toe. 
Situatie Gouden Leeuw zal ik nog even kijken, maar eigenlijk moet je eerst die leisure park goed zien te krijgen. Weg al die landuse tags! Het is de functie. 

Succes,
Eggie
eggie (2020-05-29 08:16:57+00:00): Even het eilandje t w van de kinderboerderij als voorbeeld in mp gezet. 
Je zult merken als je de landuse van die leisure=park afhaalt dat het er allemaal niet meer uitziet. , maar dan zie je wel wat er nog moet gebeuren. 
Bij de Vogelopvang is het ook fundementeel fout. Dat eiland hoort in een vlak te liggen . Ik haal die losse stukken water even weg. Het wordt een mp. De inner is de vogelopvang. 
Kwestie van gewoon beginnen.
eggie (2020-05-29 08:34:42+00:00): Van die noordelijke "chaos" gewoon alle realteis verwijderen van de "leden". Dan ook van de outer de mp relatie afhalen.
Dan lijkt het of je alles kwijt bent. Dan zet leisure=park en name=.... er weer op... Dan is het alleen de functie lijn.. en vervolgens gewoon beginnen met de landuse invullen. Denl zelf dat die leisure=park gecombineerd moet worden met dat andere deel anders krijg je twee identieke namen. Een leisure=park ligt over alles heen. Dus ook over het water.. Het is een transparant.
Succes,
Eggie
eggie (2020-05-29 08:44:09+00:00): Nog even gekeken naar die leisure.. het is er inderdaad één. Het hoort geen mp te zijn. Dus relatie en landuse verwijderen.. Dan na rendering van de schrik bekomen en gewoon gaan beginnen.
boototter (2020-05-29 09:21:06+00:00): Is het handig, want niet bepaald snel af, om telkens bij het uploaden van een portie weer even de natural=grassland terug te zetten op het transparant, zodat er geen grote witte vlek ontstaat aan de gebruikerskant?
Behalve die ontbrekende mp's is er veel wat niet deugt aan de Bijlmerweide. Hele delen sloot ten noorden van het gemaal (45),  die dienen als waterinlaat ontbreken, de duikers hebben we het al over gehad. Ten zuiden van het gemaal heb ik ook mijn survey nog niet af, daar kom ik net wat minder vaak.

Nog een vraag: bij het leggen van transparant Bijlmerweide heb je bij de meest westelijke 'siervijver' de grens van het gebied erbuiten gelegd, bij de andere worden die ingesloten. Is dat vanwege het raakvlak met het transparant ProfJvSPark, of kunnen de twee elkaar daar gewoon raken?
eggie (2020-05-29 09:36:27+00:00): Je kunt die vlakken gewoon netjes laten aansluiten aan het water. Dat doe ik door de landuse gewoon een stukje je over het water te trekken. Daarna selecteer je het water en draait de plugin cut out overlapping polygons. De lege nodes die overblijven in het water geven dan een waarschuwing. Met Herstel van josm verwijder je ze gewoon.
Keus aan jou om het even gras te laten. 
Het wordt licht groen.. op andere kaarten ziet het er weer anders uit.
de openfietsmap maakt alles zonder tagging groen. Dus een ramp is het niet. 
Niet de plugin gebruiken om water uit te snijden als je nog landuse op die leisure park hebt staan. Zo heb je er waarschijnlijk een mp van gemaakt.
boototter (2020-05-29 11:19:10+00:00): oké.
Nog even terug op de begrenzing van de Bijlmerweide. Op BGT symbolen zie ik, dat de parkbegrenzing van de Bijlmerweide telkens ten N resp O van de siervijvers ligt, dus zoals bij het ProfJvSPark, met uitstulpingen tot halverwege de duikers. 't Heeft natuurlijk weinig consequenties, maar meteen dat aanpassen wanneer ik toch bezig ben daarmee lijkt me correct.
eggie (2020-05-29 11:24:09+00:00): Tuurlijk.. gewoon je eigen plan trekken.. de bgt is alleen maar een hulpmiddel voor de begrenzing van paden en water.
boototter (2020-05-29 12:42:27+00:00): Samen met de kadasterkaart geven ze wel een indruk over het waarom van een bepaalde indeling, da's weer een voordeel bij het tekenen.
Ik heb wel wat aanwijzingen nodig voor de eilandjes in het uiterste WNW bij Geerdinkhof. Eens ituatie die zich ook verder veel gaat voordoen, maar ik nog niet bij de hand heb gehad. De eilandjes liggen (straks) keurig in een mp, maar bruggen en het erop liggende pad moeten verbonden worden met het (reguliere) vaste land. Kan dat zomaar?
eggie (2020-05-29 13:06:15+00:00): Bruggen in osm niet verbinden met de oever.. maar er een fractie overheen laten steken.
boototter (2020-06-08 22:08:58+00:00): Nu voor het eerst die cut out polygon kunnen gebruiken; dank voor die tip. Reuze handig.
Heb ook geleerd om in kleine porties en met verse downloads te gaan werken. Ben meermaals uren een conflict met eigen bijdragen herstellen, wanneer ik nog iets gepreciseerd heb.
eggie (2020-06-09 06:30:20+00:00): Dag boototter... Yep het wordt nog wat daar.
Kijk even naar de wegklasse van het Gaasperparkpad. Klopt dat wel?
Ziet er wat wonderlijk uit.
Gr eggie
boototter (2020-06-09 16:50:52+00:00): Het ziet er heel wonderlijk uit, dat ben ik volstrekt met je eens. Maar bij het graven van dat kanaaltje tussen Gouden Leeuw en Groenhoven is ook de serviceroute aangepast, incl. de brug geschikt gemaakt voor zwaar verkeer. Vuilniswagens, verhuiskolossen enz. Op de aanvoerroutes over de Bijlmerweide is max. 5T. toegestaan, dit is, mét maaiveldontheffing, de officële route (met een ontzettend lastige knik op het Ganzenhoefpad), waar ook de container- en grofvuilplaatsen aan liggen. 
Het uiterlijk is dat van fietspad, dat wel. 
Eerlijk gezegd vind ik het erzelf niet uitzien, maar ik kon geen betere wijze bedenken om dit in kaart te brengen met alle restricties eraan gehangen. 
Eigenlijk hoort het stuk Ganzenhoefpad tussen Elsrijkdreef en de flats van GL er nog bij, hetzelfde geldt voor het stuk tussen de loopbruggen van GL en GH.
Heb je een suggestie hoe het er beter uit kan zien, graag!
boototter (2020-06-09 17:09:48+00:00): De loopbrug bij Gouden Leeuw (Groenhoven moet nog) was trouwens een lastige, hoe de feitelijke situatie in kaart te brengen. Het brugdeel tussen flattorens en parkeergarage staat grotendeels niet op de BGT-kaarten, maar je loopt er erg droog. Da's minder duidelijk, dan ik had gehoopt.
eggie (2020-06-09 19:04:35+00:00): Ideeën.. nee. Up to you. Jij bent de lokale mapper. 
Gr eggie
user_5359 (2020-05-23 04:21:17+00:00): Hello! For a better description of opening hours please have a look on https://wiki.osm.org/wiki/Key:opening_hours
keithonearth (2020-06-26 18:26:30+00:00): Thanks for such a useful edit summery. I only noticed the name change now, and was glad to have it explained.
blackboxlogic (2020-05-27 12:49:40+00:00): You marked all the houses as offices. I'm curious why? They are definitely not offices.
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/85635337
Warin61 (2020-05-23 06:29:48+00:00): Hi,
There are a number of duplicated nodes that need to be fixed in this waterway. 
See https://tools.geofabrik.de/osmi/?view=areas&lon=153.11350&lat=-27.49800&zoom=16
angys (2020-06-26 22:36:53+00:00): Please use JOSM terracer to create the box
chachafish (2020-05-23 19:10:41+00:00): Hello, welcome to Openstreetmap and thank you for your contributions. I see you are tagging railway signals once on the rail itself and again to the side of the railway. Are you familiar with the, “one feature, one element” rule in OSM? Or, is there somewhere in the OSM wiki that suggests this style of mapping? https://wiki.openstreetmap.org/wiki/One_feature,_one_OSM_element
 Also, I think you’re using old imagery with some of the edits in this changeset. The newest imagery is Maxar. You moved a service road here incorrectly. This is an active construction zone. Can you please go back and repair it? If you have any questions, please feel free to ask. Thanks :)
https://www.openstreetmap.org/way/800508334#map=17/39.77754/-104.90573
fogey (2020-05-24 00:52:00+00:00): Hi, Will you be fixing the surface issues as that is not correctly tagged?
chachafish (2020-05-24 03:29:39+00:00): Howdy. Thanks for correcting the service road here. As to your question, "surface issues as that is not correctly tagged?" What exactly are you referring to? Thanks :)
camelCaseNick (2020-05-23 03:10:01+00:00): Hey,
name:wiki(data|pedia) are not common tags in OSM. You mean species:wikidata?
CamelCaseNick
Adamant1 (2020-05-23 03:17:52+00:00): Hey. Uummm I don't know. There's 3,389 uses of it for Wikipedia. I'd say that's a good number. Although, it does look like there's only 285 uses of it with Wikidata for some reason. They must just have not caught up with each other in tagging yet or something. Which is one of the reasons I'm doing this. It wouldn't work though to have the Wikipedia and Wikidata entries as different namespaces. 

That said, I wasn't sure if name was the right suffix or not, but species doesn't work because "Luna" isn't the name of the species. It's named after an event or something, or that's the name they gave it during the event. I'm not really sure. Maybe subject:wikipedia would be better or nothing. The Wikipedia article is kinda muh unfortunately.
camelCaseNick (2020-05-23 03:36:30+00:00): Sorry,
it's definitely not a species. After looking into it: It's about a specif tree. The wikidata tag was correct, the way it was before.
Adamant1 (2020-05-23 03:40:03+00:00): So, your saying the Wikidata tag was correct without the namespace? I don't know. Why's that? I think a case could be made for why both are "correct." The namespace is just adding extra details, it's not changing it into a completely different tag. I'm don't really know that super much about namespaces though since I'm generally against them. This case being one of the rare exceptions.
Adamant1 (2020-05-23 05:10:14+00:00): Also are you saying name:wikidata is wrong just in this case or is it wrong in all cases?
camelCaseNick (2020-05-23 23:21:36+00:00): In this specific case both are wrong, as the Wikipedia article and the Wikidata item describe this specific tree and not the name of the tree. (Even though the article starts with the word name, it does not actually describe the name Luna per se.)

I have change that in https://www.openstreetmap.org/changeset/85668050.

If something is described specifically, the wikidata and wikipedia tags should be used.

How to read prefixed keys for wikidata:
wikidata=* means the item for the object.
brand:wikidata=* means the item for the brand of the object
name:etymology:wikidata=* means the item of the origin (etymology) of the name of the object

name:wikipedia and name:wikidata are ambigous. Do they describe the name? In most cases name:etymology=* + name:etymology:wikidata=* and maybe name:etymology:wikipedia=* are better, since often they are used to describe, that some bridge is named after Kennedy or a street after Martin Luther King etc.
Since we have name:etymology=Martin Luther King then, name:etymology:wikidata=Q8027 is more accurate.

Did this explain something?
Adamant1 (2020-05-24 01:38:42+00:00): I mean, I didn't really need a broader explanation of how Wikipedia/Wikidata tags work. I'm not the main/top calibrator on the NSI because I don't understand what brand:wikidata is used for. Also, usually it's better if there is a disagreement about over tagging to wait until both sides come to an agreed on solution before re-tagging the object. Otherwise, it can just lead to animosity or edit warring. 

On this, while I agree that name:wikipedia/wikidata might be a little ambiguous,  it is suggested on the Wiki and is in wide use. So, if your against it to the point where you think it should be used, you should post about it on the Wiki/mailing list so it's not suggested anymore. Although, I could also nitpick that name:etymology:wikipedia isn't really correct for your examples. The bridged is named after "Kennedy", so IMO name:wikidata would be correct, but the name Kennedy does not originate with him. So name:etymology would not be correct IMO. I'm not deleting the etymology tag from Kennedy bridge over it though. 

More on topic, the Wiki says "Monuments, memorials, statues and similar features should have wikipedia=* only if they have their own Wikipedia article." Going off of that since this doesn't (memorial tree?) doesn't have it's own Wikipedia article (like you say it's not really about the tree per say) the best thing to do would be just to remove Wikipedia link altogether and leave the Wikidata entry. Would you agree with that? 

Although that doesn't resolve what should used in the Wikidata tag. I'm thinking either subject:wikidata or name:wikidata like how I had it.  name:etymology:wikidata doesn't work because the name "luna" didn't originate with the tree. So, which one of those two subject:wikidata or name:wikidata, do you think is more appropriate?