piebro/osm-data huggingface dataset:
eggie (2026-04-15 20:40:27+00:00): Hoi..
Wellicht access=permissive en footway=alley Dat is een brandgang.
..access=no beter niet gebruiken. Bij een bordje verboden toegang.. dan private gebruiken.
Groet,
eggie
MapBtch (2026-04-16 05:50:50+00:00): done!
eggie (2026-04-16 05:53:14+00:00): 👍
iandees (2026-04-15 18:42:19+00:00): Hello! I noticed that node https://www.openstreetmap.org/node/8320394308 was moved a long distance in this changeset. This is a common mistake that happens when you click on a point and drag to move the map. The point moves with your mouse instead of the map.

I moved things back to where they were before in https://www.openstreetmap.org/changeset/181382557, so no harm done!

To avoid this in the future:
- Try to click on an empty part of the map when you want to move around
- If you see a point move by mistake, press Ctrl+Z (or Cmd+Z on Mac) to undo it

Happy mapping!
Dendros (2026-04-15 20:45:43+00:00): Thank you, I was unaware of the node change.  I have noticed that my Macintosh has issues with dragging various OSM nodes. Frustrating at best.  Tough at times on a laptop with only a touch pad, with OSM slow to respond sometimes.

Thank you for the info!
iandees (2026-04-15 21:13:37+00:00): I understand! The in-browser editor can get quite slow/laggy at times. You could try using an alternate editor like https://rapideditor.org/edit. It might be faster on your computer and give a smoother experience.
Jeffry Mardyo (2026-04-23 09:03:22+00:00): Jln Kpg Iboi / Pelandok functions to connect major villages (Iboi, Pelandok and Jaie) and should be secondary, road quite busy there.
LakePoopó (2026-04-24 20:27:39+00:00): In order to keep discussion in one thread, I have replied to you on this changeset (https://www.openstreetmap.org/changeset/181674299), and also responded to your DM regarding your concerns. Thanks!
SomeoneElse (2026-04-25 10:53:16+00:00): Actually, rather than individual changeset discussions, the forum (perhaps https://community.openstreetmap.org/t/dear-adt-team-for-sarawak-please-do-better/143234 ) might be a better place.
Best Regards,
Andy Townsend on behalf of OSM's Data Working Group
LakePoopó (2026-04-27 21:46:54+00:00): Thank you for the suggestion. I have now posted on the forum, to continue the discussion there.
mikita_paloika (2026-04-17 07:24:57+00:00): Hello @klaer! Thanks for adding the garage details. I noticed you added name=Garage and loc_name=Hannalors garage. Could you please clarify the source for these names?

Usually, we avoid using the name tag for general descriptions (like "Garage"), and personal names are only added if they are officially posted on the building. Thanks! 

Best regards,
Mikita
#mapbox_editing
            ---
            #REVIEWED_BAD #OSMCHA
            Published using OSMCha: https://osmcha.org/changesets/181381960
fortera_au (2026-04-16 00:50:29+00:00): Hi, can you please be more descriptive in your changeset comments, you actually haven't changed anything to do with runways here, just surrounding buildings.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/181382484
Wildsharky (2026-04-17 12:08:37+00:00): Partially reverted in changeset id:181441653
iandees (2026-04-15 19:48:46+00:00): Hello! I noticed that nodes https://www.openstreetmap.org/node/1653197275, https://www.openstreetmap.org/node/4530226530 were moved a long distance in this changeset. This is a common mistake that happens when you click on a point and drag to move the map. The point moves with your mouse instead of the map.

I moved things back to where they were before in https://www.openstreetmap.org/changeset/181385169, so no harm done!

To avoid this in the future:
- Try to click on an empty part of the map when you want to move around
- If you see a point move by mistake, press Ctrl+Z (or Cmd+Z on Mac) to undo it

Happy mapping!
Wildsharky (2026-04-17 12:09:40+00:00): Revert of 181370524
Flynn Marquardt (2026-04-17 12:47:19+00:00): Only partial, revert only the boundary changes, keep the other changes.
literan (2026-04-15 19:16:05+00:00): не надо ломать дорожки в парке
mila123_hatrus (2026-04-15 20:34:31+00:00):  я случайно и хз как это убрать теперь.......прошу прощения!!!!!!
literan (2026-04-16 06:52:02+00:00): не волнуйтесь, я исправил
Yepoleb (2026-05-01 17:15:41+00:00): Bitte nicht einfach raten was sich verändert hat, die Bearbeitung stimmt nicht, hier gibt es kein Tor.
Wikiscout (2026-05-01 17:28:25+00:00): Da war ein Tor, als ich das letzte Mal da war
eggie (2026-04-15 19:31:36+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht.
MVG,
Eggie
Namens de OSM Community
JanezPavelZebovec (2026-04-15 19:37:30+00:00): Živjo!
Vidim, da ste vnesli že precej hišnih imen, vendar bi vas opozoril, da je za hišna imena v uporabi oznaka "addr:housename=", ne "name=" (ki so uporablja le za podjetja, trgovine, restavracije, ...), kakor sem odgovoril na https://community.openstreetmap.org/t/oznacevanje-hisnih-imen/132656/7.
Lep pozdrav in še veliko veselja z urejanjem!
ajmat (2026-04-17 08:30:51+00:00): Reverted in changeset id: 181445896
SomeoneElse (2026-04-15 19:46:34+00:00): Relation gap was subsequently filled in in https://www.openstreetmap.org/changeset/181385050#map=20/51.5021846/-0.0518008&layers=H .
tux67 (2026-04-16 07:11:16+00:00): Hi  Kelso, also grundsätzlich halte ich es für hilfreich, wenn ein POI auch vollständige Adressdaten hat - gerade wenn man - wie wir in MG die Adresse nicht am umschließenden Gebäude-Way dokumentiert. 
Natürlich sollten die Adress-Nodes nicht gehijackt werden um den POI noch zusätzlich dranzukleben (also immer ein "Nur-Adress Node" + der POI Node).
Gruß
tux67
https://wiki.openstreetmap.org/wiki/DE:Key:shop#Adressinformationen
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/181385149
user_3716049 (2026-04-17 10:29:36+00:00): Wozu hilfreich ? Ich sehe da bis jetzt nur unnötige doppelte Adressdaten, da die POI's in der Regel nah genug bei der Adresse liegen um diese einnander zuordnen zu können

Wenn einen praktischen Nutzen gibt würde ich diese lassen wo sie sind bzw. welche anfügen. 

Gruß Kelso
tux67 (2026-04-17 11:10:27+00:00): Naja, die automatische Zuordung weil POI in Gebäude mit Adresse funktioniert nicht, wenn die Adresse nicht am umschließenden Gebäude gemappt ist. 
Ohne Not die Adressdaten zu löschen macht also die Arbeit der Leute zu nichte, welche die Daten genau mit der Intention der eindeutigen Zuordnung erfasst haben. 
Spätestens bei mehreren Adress Nodes in einem Gebäude mit mehreren POIs wirds dann ganz unübersichtlich.

Gruß
tux67
user_3716049 (2026-04-17 17:32:46+00:00): Nachdem was hier steht :
https://talk-de.openstreetmap.narkive.com/qS0Kjg2o/adressdaten-in-poi-nodes

ist das ein Fall von tagging für die vielen Renderer die  z.B Overpass-turbo zur Auswertung verwenden der nicht dazu in der lage das zu erkennen.

Das hier :
https://farmshops.eu/#51.1527,6.41527,18z
wäre wohl einer davon.

Ausserdem glaube ich eher das die meisten die Adressdaten einfach dort eintragen, weil sie es nicht besser wissen. Weshalb wir auch soviele an den Gebäuden haben, obwohl im Wiki steht das die Adresse Teil des Grundstücks ist und keine Hausnummer. Es hat sich auch ausser dir auch noch niemand daran gestört  das ich die lösche oder einen Hinweis in der Karte hinterlassen weil er am POI eine Adresse vermisst. So wichtig scheint es niemanden hier zu sein.

Tagging for the Render oder nicht scheint mir hier die Frage, über der man sich wohl in der Community wohl nicht so richtig einig ist und die jeder dann so auslegt wie er es gerade für nützlich hält. 
Ich halte nichts davon Datenbanken mit redudanten Daten unnötig zu belasten.   

Gruß Kelso
tux67 (2026-04-17 18:06:12+00:00): Also bei POIs, bei denen ich die Adresse eingetragen habe darfst du die Löschung rückgänging machen.
Andere werden das vermutlich nicht mitbekommen. 

Wenn du schon selber sagst, daß man sich da uneinig ist wäre nichts machen vielleicht die beste Option.

Gruß
tux67
The Invisible Freak (2026-04-18 06:20:21+00:00): Hallo zusammen,

also ich habe bislang auch immer die Adressdaten noch zusätzlich in die POIs hinterlegt. Es gibt auch Gebäude, die mehrere Hausnummern haben, z.B. 9-11, wobei jeweils ein Geschäft in Hausnummer 9 und das andere in Hausnummer 11 liegt. Die lassen sich lediglich anhand der Gebäudedaten später nicht mehr eindeutig zuordnen.
Andersherum gibt es auch Fälle, bei denen am Gebäude keine Hausnummer hinterlegt wurde (vergessen?) aber der POI (z.B. https://www.openstreetmap.org/way/284595721).
Offenbar wird in OsmAnd aber nur die Adresse des Gebäudes angezeigt. Andere Apps könnten das aber anders handhaben.
Hier (https://www.openstreetmap.org/node/13733290384) haben wir so einen Fall. Das Gebäude hat gar keine Adresse sondern nur ein Punkt innerhalb des Gebäudes. Dem POI wurde aber jetzt die Adresse wieder genommen. Wie soll die eindeutige Zuordnung des POI zu einer Adresse in diesem Fall erfolgen?

Fazit: sicherheitshalber würde ich sowohl beim Gebäude als auch beim POI die Adressdaten hinterlegen.
Vielleicht solltest Du Deine Änderungen also besser wieder zurücknehmen.
user_3716049 (2026-04-18 18:11:55+00:00): Hi tux & inviseble Freak
Der Stammtisch Viersen hat in seinen Wiki ein kurzes Overpass-turbo Script veröffentlich das den zum POI nächstgelegen Address Node findet.

Damit ist es offensichtlich das es  wahrscheinlich über 95 % aller fällen volkommen unnötig ist an POI's Adressdaten anzuhägen und dadurch OSM Datenbank mit redudanten Daten aufzublähen.
In fällen wo das nicht funktioniert ist selbstverständlich akzeptabel das zu tun, darüber brauchen wir nicht zu diskutiern.

http://overpass-turbo.eu/s/10Mj

https://wiki.openstreetmap.org/wiki/Niederrhein/Viersen/Stammtisch/overpass#POI

MfG Kelso
tux67 (2026-04-18 18:49:31+00:00): Es wäre schön, wenn du genau die Fähigkeit zu entscheiden, was in dem Fall akzeptabel ist den Mitmappern überläßt und nicht automatisiert einem Script.

Btw. .. Genau die Art von Abfrage, die du in deinem Vorpost mit "Mapping für den Renderer" kritisierst.

Gruß
tux67
tux67 (2026-04-18 18:55:01+00:00): P.S.:Es bleibt dabei ..zumindest bei Adressdaten, die ich eingefügt habe - bitte rückgänging machen. 

Ob sich andere Mapper die regelmäßig in Gegend POIs aktualisieren sich ungefragt deiner Sichtweise anschließen kann ich nicht beurteilen ...
user_3716049 (2026-04-19 08:49:28+00:00): Tut mir leid aber ich kann deinen wirren Aufführung  nicht folgen.

Am anfang hasst du argumentiert das die Adressdaten am POI notwendig währen damit diese  gefunden werden können.

1. Ist das script der Beweis dafür das für jeden leicht möglich ist.
da 
2. Overpass-Turbo ist kein ! Renderer, sondern eine API (Schnittstelle,Auswerter) zur OSM Datenbank mit der man gezielt gewünscht Daten aus dieser herausfilten und exporrtieren kann.
Sodass jeder diese dann vom eigen Renderer zum berechnen von Induviduelen Karten für seine Webseite oder Programm nutzen kann. Die oben erwähnte Webseite ist nur ein Teil von Overpass-Turbo.

https://wiki.openstreetmap.org/wiki/DE:Overpass_API
https://de.wikipedia.org/wiki/Programmierschnittstelle

Wenn Nutzer der OSM Datenbank nicht inder Lage korrekt in die Datenbak eigetragene Daten aus der Datenbank für Ihre eigenen Zwecke aus zu lesen um, ist dies laut Wiki "tagging for the Render" wenn man Daten dann so einträgt das Karten von Webseiten oder Programme diese trozdem anzeigen.

3. Ich hatte gesagt das ich es für gerechtfertigt halte POI's Adressedaten anzufügen, wenn der laut Wiki eigentlich vorgesehen Weg durch Positionierung des POI in der nähe des Knoten einen Adresse zuzuordnen nicht möglich ist.

Wenn du das  ablehnst, weil du meinst das das gegen das Wiki verstösst, kannst du das auch lassen und dich bei denen beschweren die das tun ich halte das für akzepabel und würde darüber diskutiern wollen.

Gruß Kelso
The Invisible Freak (2026-04-19 09:27:16+00:00): Bevor das hier eskaliert versuche ich mal, die Wogen etwas zu glätten.

Ich bin nicht sicher ob die Daten im überwiegenden Maß tatsächlich von Benutzern ausgelesen werden sondern vermutlich eher von Apps und Webseiten, die auf OSM aufbauen. Aber selbst wenn nicht, finde ich es dennoch vorteilhaft wenn man einen POI auf der OSM-Webseite anklickt und bekommt  dann alle Tags angezeigt. Dazu gehört dann im besten Fall auch die komplette Adresse. Daher macht es schon Sinn, diese nicht nur am Gebäude selbst zu hinterlegen, zumal es auch Situationen geben kann wo es ansonsten unklar ist (hatte ich weiter oben schon beschrieben). Und das Argument eines unnötigen Aufblähens der OSM-Datenbank halte ich für nicht relevant. Mittlerweile sind fast 32 Milliarden Punkte hinterlegt (https://planet.openstreetmap.org/statistics/data_stats.html), da kommt es auf ein paar zusätzliche Adressdaten sicher nicht mehr an.
Wenn also jemand entscheidet, dass er die Adresse noch mal zusätzlich am POI hinterlegt, dann lass ihn doch. Es hat doch sicher einen Grund, warum es überhaupt möglich ist, das zu tun. Oder ist irgendwo festgelegt, dass man das unterlassen sollte? Und falls ja, warum und in welchen Fällen?

Wäre es nicht besser das Thema im Community Forum zu besprechen? Mich würde interessieren wie andere darüber denken bevor es hier zu emotional wird und das Thema versachlichen.
tux67 (2026-04-19 12:23:49+00:00): Danke @The Invisible Freak für die Intervention!

Um das ganze mal auf einen einfacheren Level herunterzubrechen:
- Im Wesentlichen wurden Argumente für und wider die Dokumentation von Adressen an POIs geliefert

- die Frage, ob das gewünscht / gut oder was auch immer ist, werden wir hier nicht lösen (wie auch Kelso schon in seiner 1. Reply erwähnte - die Community ist hier ca. 50:50 gespalten)

- der Vorschlag das im Community Forum zu diskutieren wäre bei anderen Themen auch meine 1. Wahl gewesen, aber wenn man sich mal die Diskussionen über die Jahre ansieht: 
https://community.openstreetmap.org/search?q=%23communities%3Ade%20POI%20Adresse
--> man findet zu beiden Positionen alle möglichen Argumente - und ich denke ein neuer Versuch wird mit genau diesem Hinweis oder einem müden Gähnen enden.

Meine Position:
- In der Vergangenheit habe ich POIs auch immer ohne Adresse gemappt, da ich auch keine Redundanzen mag.
- Nachdem ich mich lange Zeit mit den verschiedenen Positionen auseinander gesetzt habe, sehe ich das jetzt anders, da der "KISS" Ansatz hier auch für Newcomer gut verständlich ist und eine gewisse Logik dahinter liegt den POI und die Adresse zu verbinden
- Aus dem Grund die anderen 50% der Community Argumente für die höhere Weisheit zu halten und daraufhin gezielt Adressen, die mühsam erfasst wurden wieder zu löschen, halte ich inzwischen für vermessen (auch wenn ich die Ansicht vielleicht in der Vergangenheit auch vertreten hätte).

Ein letzter Gedanke zu Thema "Speicherplatz" - als Datenbank hält OSM bekannterweise  die Historie der Objekte vor: Ein Änderungssatz der Adressdaten löscht erhöht also den Speicherverbrauch (wenn auch nicht linear).

@The Invisible Freak - eine gute Übersicht um sich eine Meinung zu dem Thema zu bilden ist tatsächlich das Forum (mein Link oben) im Laufe der Jahre.
Deiner Argumentation im letzten Post für POIs an Adressen kann ich aber nur voll und ganz zustimmen.

Schönen Rest-Sonntag und Gruß
tux67
MappingMore (2026-04-16 17:42:39+00:00): Revert of 181357213
CurlingMan13 (2026-04-15 21:33:20+00:00): Looks good.  If it is a drainage basin where water is intermittent, make sure you select that box or tag it as "basin"

Thanks and welcome to OSM!
ESOSMmapper (2026-04-15 23:14:10+00:00): Thank you so much, @CurlingMan13!
vrabcak (2026-04-25 06:23:03+00:00): Prosím při upřesňování návěstidel dávej pozor na orientaci - u několika návěstidel jsi nesprávně otočil směr. 

Dále jsem si všiml, že často přidáváš do tagu ref návěstidla nesprávně mezeru. Pokud to dělá nějaký automatický nástoj, prosím oprav si ho, ref návěstidel podle D1 je vždy bez mezery.
HaPe-CZ (2026-04-26 16:56:19+00:00):  Podle TNŽ 34 2605 se mezi písmenné znaky a číslice vkládají mezery.
vrabcak (2026-04-26 17:58:49+00:00): Nikoli, TNŽ zde odkazuje na značení provozovatele dráhy (tedy na D1), která stanovuje značení bez mezer. Na starších návěstidlech by se mohlo jevit, že tam mezera je, ale to bylo mechanickým provedením plechových štítků. Na všech nově osazovaných návěstidlech je už označení zřetelně bez znaku mezery - je pouze opticky typograficky odděleno pokud je to potřeba kvůli čitelnosti (Např "odskočení" mezi "L" a "1" u L1).
Drážní technická dokumentace všetně veškeré veřejné a interní dokumentace SŽ, dopravců, DI atd. používá značení bez mezer.
vrabcak (2026-04-26 18:17:06+00:00): Pro ilustraci je ta typografie krásně vidět např. na zbrusu nových návěstidlech v Praze-Bubnech, třeba na této fotce: https://mapy.com/en/turisticka?source=pubt&id=15212553&gallery=1&gsort=takeDate&sourcep=foto&idp=16997029&x=14.4432141&y=50.0955437&z=15 - S1 je "odskočené", S2 "nalepené na sobě".
HaPe-CZ (2026-04-27 10:15:24+00:00): TNŽ je technicka norma zeleznic, ktera stitky popisuje tak, jak se maji v dokumentaci znacit. Tudiz popisuji navestidlo v dokumentaci. Od vydani TBŽ jina norma toto nezmenila. Stitek navestidla klidne muze byt proveden jinak. Je to na uvazeni vyrobce a nicemu to nevadi. S tou mezerou v popisu to mam i v plankach sranic.
HaPe-CZ (2026-04-27 10:17:58+00:00): Jestli je jina norma, ktera toto na stitku specifikuje "bez mezer", rad se s ni seznamim. Neni problem.
vrabcak (2026-04-27 22:19:30+00:00): Koukal jsem ještě pro jistotu do TNŽ 34 2605 (verze z roku 2003) a našel jsem tam pouze odkazy na D1 - konkrétně článek 7, 12 a 31 se všechny shodně odkazují na D1. 
Ještě jsem ověřoval další možné normy a TNŽ 34 2620 se také odkazuje na předpisy provozvatele dráhy (tedy D1). 
Pak jsem našel zmínku v předpise T100 - také se odkazuje na předpis D1. 
Takže mi z toho vyplývá, že závazné je značení dle D1 - tedy bez mezer.

Co se týče plánků stanic, myslíš tím ty excelové zjednodušené plánky v neveřejné části portálu provozování dráhy? Tak na ty jsem úplně zapomněl a máš pravdu, tam používají označení návěstidel s mezerami. Netuším proč to tak je, nejspíš nějaké historické důvody, protože jinak SŽ používá konzistentně téměř ve všech dokumentech označení bez mezer.
HaPe-CZ (2026-04-28 14:27:26+00:00): konkrétně to je zde: TNŽ 34 2605, kapitola: III. NÁVĚSTNÍ NÁTĚRY A NÁVĚSTNÍ ZNAČENÍ NÁVĚSTIDEL,  
bod: 32, vysvětlivka 4), druhý řádek.
Fakt to tam je s mezerama.
HaPe-CZ (2026-04-28 17:16:01+00:00): A tady taky ... https://mapy.com/cs/letecka?source=pubt&id=15212380&gallery=1&sourcep=foto&idp=5354700&x=18.2087582&y=49.8202384&z=17.
Jinak D1 nijak ty tabulky nedefinuje, kde "s" a kde "bez" mezery. To co D1 prezentuje je obrázek a skutečnost je viz. link ...
vrabcak (2026-04-28 19:28:27+00:00): Ohledně vysvětlivky 4 máš pravdu, koukám, že v té poznámce pod čarou jsou dva příklady  s mezerami [Lc 2a][L 201], dva příklady bez mezer [L][2][0][1],[2][-][3][5][2][2] a dva příklady subjetivně interpretovatelné  [Lc][2a], [2-][35][22] (je to "Lc 2a" a "2- 35 22", nebo "Lc2a" a "2-3522" ?). Z toho si asi nic rozumného neodneseme, kromě prostoru pro lidovou tvořivost a postesknutí nad typickým drážním pořádkem :-) 
To by také  vysvětlovalo, proč jsou v reálu ty tabulky různě vypadající, asi v tom nebude jen viditelnost (i když u Lc, Sc asi hraje roli i to, aby to písmeno malé c nesplývalo a nebylo zaměnitelné s o).
  
Za mě navrhuji držet se v OSM předpisu D1, který je v definici mezer konzistentní. Používá identifikátory bez mezer nejen na obrázcích, ale důsledně také všude v textu. 
Tag ref bych bral jako identifikátor návěstidla, nikoli jako "jak se vizuálně jeví tabulka", protože to je příliš subjektivní. Například ta návěstidla, která jsi v tomto changesetu změnil jsou v terénu na tabulkách bez mezer. 
     
Stejně tak bych se držel konvence D1 u přejezdníků, kde se na starších tabulkách používala pomlčka (X-123), ale identifikátor je bez pomlčky (X123).
 
V zásadě je to ale drobnost a půjde to pak hromadně přetagovat, když domluvíme jednotné schéma.
HaPe-CZ (2026-04-29 16:04:10+00:00): 1) příklady např. [L][2][0][1] jsou specifikované tak, že každý znak má svoji vlastní tabulku, to vyjadřuje právě [x].
2a) čl. 503 D1: vyobrazení tabulky na obrázcích 254-256 je bez mezer (si při tisku měli jen jednu velikost rámečku)
2b) čl. 503 D1: vyobrazení tabulky na obrázcích u bodu 12, 17 je naopak s mezerami (tam měli větší rámeček)
3) čl. 216  D1: v textu ... (např. „IOSe 4“) s mezerou ale na obrázcích zase bez.
... takže ani D1 není ve výkladu s/bez mezery konzistentní, nikde jsem tam nenašel konkrétní definici jestli s/bez mezery. Proto používám poslední známou definici z TNŽ.
4) Výhybky (např. dodatečné nebo vlečky s písmenem)  a výkolejky jsou jasně bez mezer aby se to nepletlo s popisem pro návěstidla určené pro jízdu vlaku.
5) přejezdníky nejsou definované a od počátku bez mezery nebo oddílové návěstidla s hektokilometráží.
NeisBot (2026-04-15 20:30:43+00:00): Hello, welcome and thank you for your contribution to OSM!

Your changeset was commented because your added description, note or slogan contain detailed text that may be interpreted as promotional or SEO-related. To ensure OSM remains neutral and focused on map data, I recommend keeping descriptions concise, factual, and free from marketing or promotional language.

⚠️️ Problematic element (limit 1):
https://osm.org/node/9796101293 v3

Could you please revise your text accordingly?

✅ For example, a more neutral and factual version of your text could be: "Law office"

#MapWithoutSpam
NeisBot (2026-04-15 20:36:43+00:00): Hello, welcome and thank you for your contribution to OSM!

Your changeset was commented because your added description, note or slogan contain detailed text that may be interpreted as promotional or SEO-related. To ensure OSM remains neutral and focused on map data, I recommend keeping descriptions concise, factual, and free from marketing or promotional language.

⚠️️ Problematic element (limit 1):
https://osm.org/node/13733358853 v2

Could you please revise your text accordingly?

✅ For example, a more neutral and factual version of your text could be: "Navy Association Building"

#MapWithoutSpam
DFW-Backyard7 (2026-04-16 14:02:53+00:00): Hi! Thanks for joining and contributing. It's fixed now, but in the future try to be careful where you place nodes for new objects. This Aldi was added to a house 1/4 mile away from its actual position...

I've never used MAPS.ME so I'm not sure exactly how that happened, but try to be mindful of where it places nodes.
Glassman (2026-04-16 22:12:44+00:00): Thanks for correcting the street name. From what I see, the road is tagged as private but there isn't a no trespassing sign. If that is correct, then the tagging the road ownership=private would be appropriate. Can you review this edit.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/181387110
NeisBot (2026-04-15 21:00:42+00:00): Hello, welcome and thank you for your contribution to OSM!

Your changeset was commented because your added description, note or slogan contain detailed text that may be interpreted as promotional or SEO-related. To ensure OSM remains neutral and focused on map data, I recommend keeping descriptions concise, factual, and free from marketing or promotional language.

⚠️️ Problematic element (limit 1):
https://osm.org/node/13696090660 v5

Could you please revise your text accordingly?

✅ For example, a more neutral and factual version of your text could be: "Plumbing business"

#MapWithoutSpam
NeisAgent (2026-04-15 22:33:21+00:00): 🕵 It looks like you reintroduced text that was previously flagged as promotional and removed after a review. Could you please explain why it was added again?
CAM-Gerlach_Repair (2026-07-01 11:06:20+00:00): Reverted adding SEO spam POI with blatant advertising and malformed tags/values in changeset 184907846

https://osm.org/changeset/184907846
Piz Pachific (2026-04-15 21:21:57+00:00): Wieso addr:full? Besser und vorallem maschinenlesbar sind die aufgeschlüsselten addr:* Tags.