Slagboom&Peeters lijkt niet publiek te zijn (https://www.slagboomenpeeters.com/nl/ortho-en-stereofotografie nodigt uit tot contact opnemen voor een offerte, en linkt onderaan naar een viewer wiens domeinnaam niet resolvt / die niet meer lijkt te bestaan) dus dat helpt me niet echt om te dateren en na te kijken. Mapillaryfoto's van 2021 als bewijs aandragen dat wat ik 4 dagen geleden gezien heb in de survey niet kan kloppen is ook een beetje vreemd.

> Luc, Kan die note eraf?

Die beslissing heb je al genomen dus het heeft geen nut te doen alsof het een vraag is. Men vraagt ook niet "Henkie, kan die weg?" om vervolgens, zonder op antwoord te wachten, de oude teddybeer in een vuilnisbak te gooien. Komt nogal sarcastisch over :P

> Geen erg in de routerelatie gehad?

De wandelroute wordt in de toegevoegde notitie genoemd samen met een suggestie voor wie die uitstippelt, dus ook hierop wist je het antwoord. Wederom snap ik niet waarom de vraag gesteld wordt als die niet indirect-suggestief bedoeld is

> Mee eens?

Tsja, ik meen wat anders te hebben gezien in het voorbijrijden maar kan het niet met zekerheid zeggen. Daarnaast is het van dusdanig onbelang (een wandelaar kan toch wel over de meter gras stappen, net als je op elk ander punt langs deze zestigweg een verbinding kan tekenen) dat ik er natuurlijk geen edit war over ga beginnen. Er moet gewoon iemand bij gelegenheid ter plaatse gaan en dan weten we het allemaal zeker. Mogelijk ben ik komende zondag weer daar: als ik degene ben die oma ophaalt kom ik waarschijnlijk weer over deze weg vanwege een wegafsluiting elders. In dat geval zou ik even bij de huizen verderop stoppen en te voet gaan kijken

Een slagboom in Nederland heet ook niet barrière=slagboom, dus een kunstwerk in Nederland een engelse tag geven vind ik niet zo vreemd :P
Het is aan de applicatie om dingen als barrier=lift_gate weer te geven in de lokale taal, zoals slagboom bij ons, boom barrier in engelstalige gebieden (lift gate kennen ze namelijk niet), Schranken in duitstalige gebieden, enz.
Het is niet zozeer "omwille van de rest van de wereld" als "omwille van dat OSM ook in Nederland bruikbaar blijft", gezien niemand met vertalingen om zou kunnen gaan:

- Als softwareontwikkelaar zou het naar mijn idee niet opschieten om alle OSM-software eerst door alle vertalingen te moeten laten zoeken wanneer het een "boomstronk"-tag tegenkomt, om dat vervolgens weer terug te vertalen naar de taal van de gebruiker (bijv. Baumstamm).

- Als mapper/tagger zie ik in dat idee ook een probleem voor mensen die de lokale taal niet kennen: je kan op vakantie dan niet aan de kaart bijdragen omdat je de lokale benaming niet kent (in het Frans gaat misschien nog, maar denk aan Polen, China, Ethiopië, ...). Om over false friends nog maar te zwijgen (waar je in Nederland een toilet tagt voor de grote boodschap, moet je het in België wellicht begrijpen als prostitutielocatie).

Ik begrijp niet waarom een voorwerp een Nederlandse tag zou moeten hebben enkel omdat het in Nederland staat of is bedacht, zolang een alom bekend Engels woord ervoor bestaat. Dit is natuurlijk uitgezonderd de freeform velden zoals description, defibrillator:location, name, enz. die wel standaard in de lokale taal zijn (en :taal suffixen kennen), waarvan ik alleen description kan bedenken als hier van toepassing zijnde

subject:nl=Boomstronk kan wellicht, al is tree_trunk al een letterlijke vertaling daarvan en zouden (wanneer die waarde bij applicaties bekend raakt) de OSM-elementen geen vertaling meer in zich hoeven dragen. Subject lijkt ook al andere subtags te hebben (zoals subject:wikidata=*) dus een vertaling-suffix botst misschien. Het gebruik van een taalcode zoals nl: als prefix heb ik nog nooit gezien dus dat zou ook afwijken van alle standaarden zover ik weet.

Wat je dus precies wil voorstellen snap ik niet helemaal (nl: als prefix? Waarden in de lokale taal in het algemeen? Alleen artworks vertalen?), maar algemeen is het denk ik zaak om eerst te overleggen met andere communityleden voor een nieuwe standaard

Van de andere kant, als jij het niet eens bent dan wil ik daar ook zeker niet tegenin gaan. Ik zou dan voorstellen bijvoorbeeld op het forum te overleggen wat het juiste schema voor deze voorwerpen is

Dat had ik inderdaad gedaan maar mocht (later op de dag waarop je de edit deed) nog niet baten

Duurde even (update de standaard render niet vrijwel live tegenwoordig?) maar het heeft gewerkt! De boompjes in het water waren me niet opgevallen, dus thanks eggie :)

Leek ook wel een beetje op golfjes in het water (als je niet goed kijkt). Zag wel oké uit; iets van detail in het water zoals golfjes is wellicht iets om de renderer aan te bevelen...

Super! Blij dat het niet iets is dat je liever niet gehad had. Het was ook een redelijke wall of text, ik snap dat het erbij ingeschoten is :D

Ben momenteel de giant_thing sculpture type aan het documenteren op de wiki. Deze sleutels zijn een mooi voorbeeld. Thanks nogmaals voor ze in kaart brengen :)

Hey, vraagje over de plastic boomstronken (https://overpass-turbo.eu/?w="artwork_subject"%3D"Boomstronk"+global&R): wat vind je van het idee om deze Nederlandse beschrijving in de description te zetten in plaats van in artwork_subject? Die laatste zou ik voorstellen een waarde te geven die elders op de wereld ook gebruikt en bequeried kan worden, zoals tree_stump

Helaas geen reactie van je ontvangen. Bij deze heb ik de voorgestelde wijziging doorgevoerd in: changeset/154709997

Moin!

Thanks for adding info to the map :). However, the "name" tag is not the right one to use for a housenumber.

Looking at the previous version of this house where you already added it correctly (changeset/130947168), I am guessing it did not immediately show up and so you added it to another field to see if that works? The addr:housenumber tag is the correct one to use, but different maps update their data at different rates. Sometimes the browser may also have a local cache, which may be avoided by reloading with Ctrl+F5. The openstreetmap.org default tiles are pretty fast to update nowadays, but they will serve an old version before re-rendering in the background so you'll almost always see an old version first.

Hope this helps!

Luc

Oh, I went by and saw it! Never noticed that before on a parcel locker. I guess that sign literally says "name" yeah, so the name tag (rather than ref) sounds appropriate, at least until the wiki starts to say otherwise. Thanks for the reply, I learned something :D

Moin, is it on purpose that name=ira was added to this parcel locker? node/8807920908/history

(I don't know if that may be its reference code or how to check that)

Hey, leuk dat je verschillende grote sleutels aan de kaart hebt toegevoegd :)
(Zoals ook in changeset/144482207)

Is de waarde "Sleutel" voor artwork_subject echter handig? Het is een Nederlands woord en het is nou niet alsof sleutels een uniek Nederlands ding zijn (zoals stroopwafel zou zijn) of dat het in het Engels als leenwoord gebruikt wordt (zoals Kindergarten)

De mogelijke waarden die de wiki documenteert (artwork_subject=*) lijken ook niet echt passend: is geen persoon en ook geen abstracte kunst, en dat zijn zo ongeveer alle opties. Een niet-standaard waarde is dus wel gepast denk ik, maar dan zou ik het wel Engels houden zodat de tag bruikbaar blijft.

Misschien is een betere manier van classificeren om sculpture_type toe te voegen, en daar een waarde als giant_thing voor te gebruiken? Er zijn nog niet veel waarden in gebruik voor die tag en de enige die in de buurt komt is giant_furniture (1x gebruikt), wat me een goed patroon lijkt maar hier ook niet passend is.

Ik kom hierop omdat ik hetzelfde probleem had met een gigantisch kaasblokje bij Roermond. Er lijkt geen tag voor grote voorwerpen te zijn maar "gigantisch voorwerp" komt op best veel plaatsen wereldwijd terug (zie bijvoorbeeld https://bigthingsofaustralia.com/) en lijkt me dus een redelijke onderverdeling.

Wat vind je van de volgende aanpassing aan de sleutel-kunstwerken?

1. artwork_subject van "Sleutel" naar "key"
2. description toevoegen met als waarde "Sleutel" (of misschien iets als "Grote sleutel"?)
3. sculpture_type toevoegen met een waarde als "giant_thing"

Description continued: replace highway=track with highway=service for roads meant to be used by customers (not for agricultural purposes); add lanes=1 + oneway=no to a road not wide enough for two cars to pass each other, adding passing spots as well

* and check the house number so the address node can be merged into it, I forgot to add to the description

changeset description += as part of the landuse update, I tried to unmark a part of the multipolygon forest as forest and put other things inside. Hope I did that correctly

There are street lamps, but the parking lot is not actually lit at night

forgot to mention that the path I disconnected (at node/11926393518) was not there (surveyed two days ago). Did not have an opportunity to check the other end, so it might have to be pruned back further, I don't know

Query used:
(node[highway=street_lamp]({{bbox}});
way[highway~"(unclassified|residential|primary|secondary|tertiary|[a-z]+_link|trunk|motorway|living_street)"][lit!=yes](around:35););
out geom;

Has false positives in terms of streets that branch off near where a street lamp was identified but that do not have street lamps mapped along them, so it needs quite a bit of manual checking

I just noticed you undid my change and re-tagged the whole square as a parking area again, but this is not correct.

Please be aware when playing maproulette that the aerial view is not always up-to-date. I would especially ask to double check when the object you're changing comes from a recent changeset tagged as source=survey

---

Mij viel net op dat je mijn wijziging ongedaan gemaakt hebt en het hele plein als parkeervak aangemerkt hebt, wat niet klopt.

Let s.v.p. bij het spelen van maproulette op dat de luchtfoto's niet altijd up-to-date zijn. Ik zou vooral willen vragen om te dubbel-checken wanneer je een object wijzigt dat van een recente changeset komt die met source=survey getagged is

Hi, thanks for adding the path! (way/1278644243)

Are you sure this is a highway=track though? That tag is meant for "minor land-access roads that are not considered part of the general-purpose road network" (see the wiki: highway=track). This path looks like it runs past buildings, so something like highway=residential might be more appropriate maybe?

Kein Thema, my profile says I understand German and, after all, in this international project it doesn't really matter what language is used so long as the reader(s) understand :)

I've updated it (changeset/150728290) to use the meadow=pasture tag because the wiki suggests that as the most common tagging scheme these days. Thanks for raising it!