piebro/osm-data huggingface dataset:
Alecs01 (2016-03-03 20:42:29+00:00): No spam please, in questo changeset e nel successivo hai inserito oggetti palesemente inesistenti (Obama in piazza Duomo al posto di Vittorio Emanuele?) ho fatto il revert
user_5359 (2016-03-03 18:25:34+00:00): Welcome to OSM! Short remark: You forgot to add a building=yes on your way.
5m4u9 (2016-03-04 02:25:43+00:00): Gracias por contribuir!

De casualidad sabes el nombre de la calle? sería de gran utilidad esta y de la zona...
SomeoneElse (2016-08-03 22:27:20+00:00): Hello,
I'm writing to you on behalf of OSM's Data Working Group.  Questions have been raised about the accuracy of the boundaries of Morocco, and I'm sending this message to many of the mappers who have edited in the area or expressed an interest, including you.

We're aware that there is disputed territory in the region.  Most notably the area covered by https://en.wikipedia.org/wiki/Western_Sahara , and also https://en.wikipedia.org/wiki/Ceuta and other areas to the north.

First, it's worth mentioning https://wiki.osmfoundation.org/w/images/d/d8/DisputedTerritoriesInformation.pdf .  That explains that what matters most to OSM in terms of names, borders and boundaries is the "on the ground" rule.  For example, if a majority of the population of an area speaks language "a" then it makes sense for OSM's "name" tag to be in language "a" (though of course other name tags such as name:b, name:c etc. can also be used to make maps in other languages).  Similarly, if the people of an area consider themselves to be part of country "a" and country "a" does indeed have control over the area, it makes sense for the area to be part of country "a" (and only country "a") in OSM.

Potential problems in the area covered by the Morocco admin_level 2 relation http://www.openstreetmap.org/relation/3630439 include:

1) That relation includes not only the part of https://en.wikipedia.org/wiki/Western_Sahara currently administered by Morocco (the part west of https://en.wikipedia.org/wiki/Border_Wall_%28Western_Sahara%29 ), it also includes the part of that territory east of it too.  Is this correct?  It seems at odds with OSM's "on the ground" rule, and with the UN peacekeepers' position described at http://www.un.org/en/peacekeeping/missions/minurso/background.shtml .

2) That relation also includes territories administered by Spain such as Ceuta and Melilla.  What evidence is there that Morocco controls these territories and that Spain does not?

Another major question, (largely dependant on the answer to (1) above) is:

3) If the area east of https://en.wikipedia.org/wiki/Border_Wall_%28Western_Sahara%29 isn't part of Morocco, what status should it have?  http://osm.mapki.com/history/relation.php?id=195838 did represent this territory and had several different admin levels before it was deleted.

The DWG would be grateful for your opinions on these matters.  You can either reply here or, if you prefer you can email data@osmfoundation.org directly and we'll read through all the replies.

Best Regards,

Andy Townsend (SomeoneElse) on behalf of OSM's Data Working Group.
alain2003 (2016-08-06 17:24:05+00:00): Hi,
Ceuta,Melilla,Bades and a few Island in the north are for a long time claimed by Morocco but without succes.
these  territories are all administered by Spain and not by Morocco 
regarding the so called western Sahara it is integral a part of Morocco as the southern provinces or Moroccan sahara.
the eastern part of the security border(moroccan wall) is administered by Morocco and the western part is virtual  administered  by Morocco as it has no acces to it since the cease fire in the '90.
SomeoneElse (2016-08-30 21:14:15+00:00): Hello again,
Following on from my "I'm writing to you on behalf of OSM's Data Working Group" comment above, we'd had feedback from lots of OSM mappers in the area.  The findings and the changes that will be made are described at 
http://forum.openstreetmap.org/viewtopic.php?pid=606038#p606038 .  If you have any further comments you can contact the Data Working Group by email on data@osmfoundation.org
Thanks,
Andy
Hjart (2016-03-03 18:43:03+00:00): http://taginfo.openstreetmap.org/tags/building=slurry_tank
ErikBreum (2016-03-03 18:49:41+00:00): ???
Hjart (2016-03-03 18:54:29+00:00): Gravhøje tagger jeg normalt med http://wiki.openstreetmap.org/wiki/Tag:historic=archaeological_site og site_type=tumulus
Hjart (2016-03-03 18:55:12+00:00): Åh, jeg kan blot se du laver gylletanke :-)
ErikBreum (2016-03-03 19:19:41+00:00): tak for den med gravhøjene. Kunne ikke finde noget egnet.
Gylletankens tag har jeg set et andet sted, men det skal benbart være en bygning. Er den tagget ok nu?
Hjart (2016-03-03 19:27:11+00:00): Den er ok nu. Der er flere alternative måder at tagge bl.a. gylletanke. Jeg bruger normalt denne fordi den er den simpleste og mest direkte fortæller hvad det handler om.
Hjart (2016-03-03 19:23:56+00:00): Har du opdaget http://osm.expandable.dk ?
trigpoint (2016-03-04 17:22:55+00:00): Hi, just wondering why you deleted the Abergavenny node and recreated it?

Thanks Phil
EoghanM (2016-06-24 19:13:16+00:00): Wikipedia says this is a village, so I've added that tag (instead of the previously incorrect town tag). Let me know if this isn't correct.
http://www.openstreetmap.org/node/310089053/history
Hjart (2016-03-03 20:55:30+00:00): What imagery are you using?
Ori952 (2016-03-03 21:10:05+00:00): Bing. Y?
Hjart (2016-03-03 21:15:50+00:00): Geodatastyrelsens is more recent (from spring 2015) and there are some differences.
Ori952 (2016-03-03 21:23:26+00:00): How do I get to see it?
Hjart (2016-03-03 21:28:05+00:00): Select in the "Background" menu. You may be using Geodatastyrelsen already though, since Potlatch seems to automatically select it for me.
Hjart (2016-03-03 21:29:37+00:00): The previous mapper here (nimapper) appears to have used outdated Bing imagery.
Ori952 (2016-03-03 21:41:43+00:00): OKAY. Thanks
DD1GJ (2016-03-03 21:02:44+00:00): Hallo fisch48, willkommen bei OpenStreetMap. Obwohl es tags für genus und species gibt, werden diese überwiegend zur näheren Beschreibung von Bäumen verwenden, Das Kartieren von bestimmten Pflanzenvorkommen ist im Projekt derzeit unüblich. Zudem ist das name-Tag dafür überhaupt nicht gedacht. Was ist Dein Ziel?
http://wiki.openstreetmap.org/wiki/DE:Key:species
fisch48 (2016-03-04 07:13:27+00:00): Hallo,
ich wollte einige Standorte von heimischen Pflanzen dokumentieren. Wenn es unüblich ist werde ich die Standorte löschen.
Gruß Jörg
user_5359 (2016-03-13 17:07:30+00:00): Thanks for the complement of the OSM dataset. Note that in OSM description of the objects has the highest priority. Objects that have only one name, have little sense. As home page for the question "How do I describe you?" I recommend the page http://wiki.openstreetmap.org/wiki/How_to_map_a.
user_5359 (2016-03-13 17:38:32+00:00): Thanks for the complement of the OSM dataset. Note that in OSM description of the objects has the highest priority. Objects that have only one name, have little sense. As home page for the question "How do I describe you?" I recommend the page http://wiki.openstreetmap.org/wiki/How_to_map_a.
user_2842609 (2016-03-05 18:12:34+00:00): Added to the Wiki (brouillon). Merci man.
Link updated : https://wiki.openstreetmap.org/wiki/User:BoFFire/sandbox/Routes_Nationales_d%27Alg%C3%A9rie
maraf24 (2016-03-05 20:05:41+00:00): Names you have added were already present in old_name:de tags.
GerdP (2016-03-04 06:32:34+00:00): Hallo!
Du hast hier zwei Wege mit unterschiedlichen Eigenschaften "zusammengeklebt" zu einem 
highway="residential;service" :
https://www.openstreetmap.org/way/30369348
Ich denke, der ganze Weg ist residential, habe es entsprechend geändert.
OK?
Oder wolltest Du nur die Relation ändern ?
fkv (2016-03-04 07:42:52+00:00): Sorry, das war ein Missgeschick. Die ganze Gegend ist noch sehr vom plan.at-Import geprägt, mit Ortsnamen fälschlicherweise als Straßennamen, das war auch bei diesen Wegstücken der Fall, und deshalb nahm ich an, dass auch die Zerteilung in 2 Wegstücke noch vom Import herrührte. Darum schaute ich nur, ob die is_in übereinstimmen und die Stücke in denselben Relationen vorkommen. Die unterschiedlichen highway-Tags hab ich übersehen. Wahrscheinlich sind sowohl residential falsch (weil außerhalb des Ortsgebiets) als auch service falsch (weil nicht nur Zufahrt zum Gehöft), sondern unclassified oder track richtig, aber das will ich ohne Kenntnis der Beschilderung vor Ort nicht alles umtaggen.
GerdP (2016-03-04 08:46:35+00:00): Kein Problem. Für mich wäre eher interessant, ob das Problem in Merkaartor liegt. Eigentlich sollte kein Editor solche Kombinationen erzeugen, in iD hat es allerdings auch ewig gedauert, bis das abgestellt wurde.
fkv (2016-03-04 09:19:49+00:00): Ich finde es gut, dass Merkaartor das macht, denn das Zusammenhängen mit Strichpunkt ist bei anderen Tags ja sinnvoll, und eine Ausnahme bei bestimmten Keys wie highway=* würde das Verhalten des Editors undurchschaubar machen. Editoren mit Eigenleben gibt es sowieso genug. Merkaartor lässt den Benutzer noch mitdenken, und auch wenn ich im konkreten Fall einen Fehler gedacht habe, sind die Ergebnisse insgesamt weitaus besser. JOSM minimiert syntaktische Fehler auf Kosten inhaltlicher Fehler, die sich mit Validatoren nicht finden lassen.
GerdP (2016-03-04 09:55:53+00:00): Oh oh, wann ist denn das Zusammenhängen mit Strichpunkt sinnvoll?
Mir fällt nur eine Ausnahmen wie source ein.
fkv (2016-03-04 15:57:13+00:00): Im Grunde ist es immer sinnvoll, damit nichts verloren geht. Wenn der Wert nicht passt, kann man ihn ja immer noch manuell kürzen. Ich nutze die Strichpunkt-Notation sehr gerne z.B. in alt_name, und in diesem Sinne wurde unlängst auch ein Proposal (http://wiki.openstreetmap.org/wiki/Proposed_features/Remove_suffixed_name-tags_from_wiki) mit 79% Zustimmung angenommen - obwohl über die Strichpunkte schon so viel in Mailinglisten und Wiki gestritten wurde und sicher auch in Zukunft wird.
GerdP (2016-03-04 16:07:13+00:00): Na ja. die Diskussion um diese Abstimmung ist immer noch im Gange, siehe http://gis.19327.n5.nabble.com/Proposal-about-suffixed-tags-has-been-approved-tt5867523.html
In den Diskussionen über dieses Thema wurde aber praktisch immer gesagt, dass es nur wenige Eigenschaften gibt, bei denen "Multivalues"  sinnvoll sein können. Für die gibt es dann auch meist entsprechende Konventionen. Für die meisten oft benutzten Tags ist aber nur ein Wert sinnvoll und eine Werte-Liste komplett falsch, meine Lieblinge sind oneway = yes;no  
surface = asphalt; unpaved
lanes = 2;5
usw. Weder Mensch noch Maschine kann
damit was anfangen.
fkv (2016-03-04 16:32:21+00:00): Diskutiert werden kann viel, aber die Abstimmung ist vorbei und das Ergebnis klar.

surface=asphalt;unpaved bedeutet, dass beides vorkommt (z.B. asphalt außen und und unpaved innen, oder in unterschiedlichen Abschnitten). oneway=yes;no ist für Anwendungen nicht nutzbar, macht den Fehler aber zumindest erkennbar, im Ggs. zu einer Ersetzung durch einfaches "yes" oder "no".
GerdP (2016-03-04 16:54:05+00:00): Wir reden wohl aneinander vorbei. Wenn Du in OSM 2 Wege hast, einen mit surface=asphalt, einen mit surface=unpaved, dann ist es eben nicht sinnvoll, die beiden Wege zu kombinieren, weil damit die Information verloren geht, wo der Wechsel stattfindet,
Ein Editor, der das ohne zu Murren macht ist Müll.
fkv (2016-03-04 17:14:45+00:00): Markaartor tut das, was man ihm anschafft, also 2 Wege kombinieren. Es gäbe an Merkaartor genug anderes zu verbessern, das wichtiger wäre, z.B., weil wir gerade vom Kombinieren von Ways sprechen: wenn einer davon eine existierende ID hat und einer eine temporäre, sollte die existierende beibehalten werden. Wenn du den Editor verbessern willst, kann ich dir eine ganze Latte solcher Anforderungen mitteilen, aber dann besser per Mail oder PN...
GerdP (2016-03-05 10:18:11+00:00): Nö, danke, falls ich Lust habe zu programmieren, dann eher an JOSM oder mkgmap. Deine Vorschläge solltest Du aber an den Author weiterleiten, falls sie nicht schon auf der TODO Liste sind.
Ich hoffe für OSM dass Du Merkaartor sehr vorsichtig anschaffst, was er tun soll, bis diese Fehler behoben sind ;-)
5m4u9 (2016-03-04 02:21:13+00:00): Dos alternativas, a) dejar cómo esta hasta que haya nueva imagen, o b) tomar fotos en proyección de las esquinas (4) y con los puntos crear los vertices del la construcción. 

Más importante veo de obtener las direcciones de las calles de alrededor, te animas?

Gracias por mejorarlo.
5m4u9 (2016-03-04 03:07:59+00:00): Si miras esta presentación en la página 35 indica como usar esto que describi arriba... es muy sencillo http://www.slideshare.net/ikiya_OSM/mapping-of-historical-places-in-japan
Piskvor (2016-03-03 22:53:55+00:00): Na pražské poměry dost komplikovaná stanice. Polohy nástupišť, výtahů a přestupních chodeb jsou přibližné, zatímco podchod v -1 zhruba kopíruje obrysy budov.
Hjart (2016-03-04 07:34:35+00:00): I have completely redone the eastern part of the parking area because on Gedatastyrelsen imagery it's very different from Bing imagery.
Hjart (2016-03-04 07:32:24+00:00): I have removed the woody areas you made here, since they do not appear on Geodatastyrelsen imagery.
lokejul (2016-03-04 13:42:04+00:00): Hi Alan Trick,

I reverted the tags to building=detached in order to distinguish between freestanding homes and semi-detached homes. For examples, see near 2171 Sandalwood Cres. Verify against Abbotsford GIS http://maps.abbotsford.ca

Also, I have resolved some mis-salignments by using high-resolution BC Mosaic imagery instead of low resolution Bing imagery. If using iD editor, keyboard shortcut "B" brings the pop-up options for Background imagery.
Hjart (2016-03-04 07:30:27+00:00): Lots of people appears to use landuse=meadow whenever they see grass. I think that's a mistake. Meadow is a specific type of wet grassland and I believe landuse=grass is much more appropriate here.
Hjart (2016-03-04 07:49:05+00:00): Also you appear to have misunderstood the meaning of leisure=park
Nakaner (2016-06-15 12:44:09+00:00): Hallo WolfiDE,

ich habe deine Änderung soeben rückgängig gemacht, da sie der Realität widerspricht. (Und deinem "local knowledge" glaube ich daher auch nicht)

Das ist zwar eine Landesstraße, aber du scheinst nicht wirklich vor Ort gewesen zu sein. Hast du die Straße zwischen Heidelsheim und der Überquerung der Schnellfahrstrecke schon mal vor Ort gesehen? Das ist ein richtig schmales Sträßchen und daher nicht mal ansatzweise highway=secondary würdig. Die amtliche Widmung ist für diese Klassifizierung nur eine grobe Richtschnur. Recht oft muss man davon abweichen (z.B. Karlsruher Südtangente, die rechtlich eine Kreisstraße ist).

Siehe auch https://wiki.openstreetmap.org/wiki/Attributierung_von_Stra%C3%9Fen_in_Deutschland#Einstufung

Viele Grüße

Michael
Yul Brynner (2016-03-04 03:42:49+00:00): ¿Fuente y/o venero?
mavl (2016-03-04 16:42:31+00:00): Здравствуйте.  
Вы изменили статус дороги с highway=residential на highway=living_street [http://www.openstreetmap.org/way/85691482/history]. Статус highway=living_street означает, что дорога обозначена дорожным знаком «Жилая зона». Раньше такого знака там не было. Сейчас он появился?  
  
Также изменён статус дороги [http://www.openstreetmap.org/way/85691485/history] с highway=living_street на highway=service. Можно узнать причину?  
Конструкция:  
highway=service  
name=Киевская улица  
выглядит не совсем правильно. Если это улица, то почему дорога имеет на ней статус всего лишь проезда?
RSergei (2016-03-04 17:15:25+00:00): Так понимаю имелось в виду де-факто "Жилая зона". Хотя не вижу никакого смысла в понижении до living_street, Вторая часть которая сейчас service=, сейчас думаю поднять аналогично до residential (хотя сам когда-то был зачинщиком понижения статуса). Но это при условии, что действительно не поставили знаков "Жилая зона".
Второй вопрос входы в Институт транспорта и Библиотеку представляют одну ступеньку (да и та окружена пандусами со всех сторон), есть ли смысл ставить тег полноценной лестницы? Исправлял на других корпусах, так там приличные лестничные пролёты
orlov_vs (2016-03-05 04:59:58+00:00): 1. Я его там точно видел, сегодня еще раз проверю. Возможно изменю еще раз на сочетания highway=residential + living_street=yes 
2. Эта часть улицы отделена шлагбаумом и фактически улицей уже не является. Скорее выполняет функции въезда на территорию и т.д. Остальная часть улицы по всей длине содержит две полосы движения, а у Киевской 50 - только одна. Вдоль Киевской 52 проезжая часть никак не выделена, т.е. фактически идет по парковке. В общем эта часть Киевской признаками улицы (дороги) не обладает. Тем не менее ознакомившись с http://wiki.openstreetmap.org/wiki/RU:Объекты_карты#.D0.94.D0.BE.D1.80.D0.BE.D0.B3.D0.B8 и http://forum.openstreetmap.org/viewtopic.php?pid=30181#p30181 не вижу причин, по которому сервисный проезд не может сохранить своего исторического названия. (Тем более что это может помочь ориентироваться пешеходам.)
3. Знак жилая зона стоит. Но у киевской 61 или 63 сказать не могу. уточню сегодня. По поводу категории проезжей части - см. комментарии выше.
4. Там 3-4 ступеньки у 2 го корпуса и 2-3 перед библиотекой. Не знаю мне кажется так лучше, лестница хоть и короткая, но есть:)
RSergei (2016-03-05 08:07:27+00:00): 1, 2, 3) Если знак "Жилая зона" стоит то - основную часть highway=living_street так и оставить как сейчас в Вашей последней правке, а вот отросток вдоль Киевской 52, я бы повысил аналогично до highway=living_street (по простой причине негоже именованной части быть просто service ;)) )
На форуме и в вики нелюбовь к highway=living_street лежит из-за его "некрасивого" отображения на Мапнике (основной стиль ОСМ) и ничего кроме, а значт он тоже самое что и связка highway=residential + living_street=yes
4) Вопрос снят)))
Alexandre Schmidt (2016-03-24 00:28:06+00:00): Olá! Qual o motivo de existir este segmento?
https://www.openstreetmap.org/way/315892322#map=13/-29.4122/-51.8250
dbusse (2016-03-24 04:40:35+00:00): i also want to know why this way exist.
better ask the original author fbello.
user_5359 (2016-03-04 14:33:02+00:00): Welcome to OSM! But I think I've discovered a small problem: Your company isn't the whole city. I have revert your changeset. Please try again to mark your address.
Hjart (2016-03-04 08:44:41+00:00): Der er ikke noget supermarked der, så jeg har fjernet denne igen. Tak
jinalfoflia (2016-03-04 09:18:03+00:00): Hi Kurly,

I came across few of your changesets like the current one where the roads seem to meet at a point. Is there a particular reason for this to happen so often?

Best,
Jinal Foflia 

These are the changesets:

http://www.openstreetmap.org/changeset/37601982

http://www.openstreetmap.org/changeset/37601649

http://www.openstreetmap.org/changeset/37590856
mavl (2019-03-07 16:29:21+00:00): This changeset was redacted.
mavl (2019-03-07 16:29:24+00:00): This changeset was redacted.
mavl (2019-03-07 16:29:27+00:00): This changeset was redacted.
mavl (2019-03-07 16:29:30+00:00): This changeset was redacted.
mavl (2019-03-07 16:29:33+00:00): This changeset was redacted.
mavl (2019-03-07 16:29:37+00:00): This changeset was redacted.
mueschel (2016-03-06 18:04:13+00:00): Hi,
I found a way with two maxspeed tags:
  maxspeed:forward = 35 mph
  maxspeed:forward_1 = 40 mph
http://osm.org/way/399867361

Could you check which of the two is correct?
Cheers, Jan
TheDutchMan13 (2016-03-06 19:37:44+00:00): Fixed, thanks for noticing this.
mavl (2019-03-07 16:29:40+00:00): This changeset was redacted.
SomeoneElse (2016-03-05 00:55:08+00:00): Hello and welcome to OpenStreetMap!

Something's gone a bit wrong here I think - http://www.openstreetmap.org/node/4039786191 seems to be up in the Arctic Circle.

Presumably it should be somewhere else?
Cheers,
Andy
mavl (2019-03-08 16:15:43+00:00): This changeset was redacted.
mavl (2019-03-08 16:15:54+00:00): This changeset was redacted.
mavl (2019-03-08 16:15:58+00:00): This changeset was redacted.
mavl (2019-03-08 16:16:01+00:00): This changeset was redacted.
mavl (2019-03-08 16:16:05+00:00): This changeset was redacted.
mavl (2019-03-08 16:16:08+00:00): This changeset was redacted.
mavl (2019-03-08 16:16:12+00:00): This changeset was redacted.
mavl (2019-03-08 16:16:15+00:00): This changeset was redacted.
mavl (2019-03-08 16:16:19+00:00): This changeset was redacted.
mavl (2019-03-08 16:16:23+00:00): This changeset was redacted.
mavl (2019-03-08 16:16:27+00:00): This changeset was redacted.
maraf24 (2016-03-05 20:48:31+00:00): Nie ma potrzeby wpisywania adresów w budynek, bo tutaj już adresy są - w postaci punktów, zaczerpnięte z ewidencji gminnej.
Można natomiast przenosić istniejące adresy na budynek - służy do tego funkcja Scalanie (ikonka z plusem) - należy zaznaczyć z Shiftem adres i budynek i scalić.
maraf24 (2016-03-05 20:51:36+00:00): http://www.openstreetmap.org/way/401564946
Co to jest i dlaczego miałoby nie zostać usunięte?
user_5359 (2016-03-04 14:23:39+00:00): Welcome to OSM! Is your hotel different to https://www.openstreetmap.org/way/211541653 or https://www.openstreetmap.org/node/2012696210 ? If not please cleanup! You are welcome, if you need help.
mavl (2019-03-08 16:16:31+00:00): This changeset was redacted.
mavl (2019-03-08 16:16:34+00:00): This changeset was redacted.
mavl (2019-03-08 16:16:37+00:00): This changeset was redacted.
user_5359 (2016-03-04 14:20:59+00:00): Thanks for the complement of the OSM dataset. Note that in OSM description of the objects has the highest priority. Objects that have only one name, have little sense. As home page for the question "How do I describe you?" I recommend the page http://wiki.openstreetmap.org/wiki/How_to_map_a.

Before I forget: Your changeset comment is very helpful!
Commodoortje (2016-03-20 13:00:45+00:00): BAG id is niet juist. Vermoedelijk heb je de tags en contouren gekopieerd van het pand naast Zweedsestraat 1, waar voorheen Nefit industrial was gevestigd. Het is niet de bedoeling dat je (per ongeluk) deze tags kopieert naar een nieuw pand.
Het lijkt erop dat de adresnode ook niet de juiste is.
Commodoortje (2016-03-23 08:12:09+00:00): Brisco, 
Ik heb inmiddels de juiste contouren en het juiste bag-id aangepast.
Goed van je dat je je start op OSM gemaakt hebt, maar let op als je gegevens dupliceert. In dit geval heb je een onjuist BAG id en verkeerd bouwjaar meegekopieert. Vermoedelijk heb je de contouren iets aangepast naar de geschatte positie.
Commodoortje (2016-03-20 13:04:33+00:00): Wat bedoel je met een kleine tweak?
mavl (2019-03-08 16:16:40+00:00): This changeset was redacted.
mavl (2019-03-08 16:16:44+00:00): This changeset was redacted.
user_5359 (2016-03-04 14:19:22+00:00): Welcome to OSM! Is your hotel a different hotel to https://www.openstreetmap.org/node/271776177 ? If no, please cleanup! You are welcome, if you need help!
SomeoneElse (2016-03-04 15:42:48+00:00): @user_5359 as you suspect there's only one hotel here (I've stayed in it).  

I'd suggest merging the "new" details from https://www.openstreetmap.org/node/4039853977 onto https://www.openstreetmap.org/node/271776177 , but keep the old name and losing the spammy "description".  The operator isn't Best Western (in OSM terms that's the "brand"); unless there's been some major consolidation the operator will probably be a local company with 2 or 3 hotels in the area.
Jose Riha (2016-03-05 14:27:20+00:00): naco su taketo (a podobne) changesety dobre?
Marek Šebo (2016-03-05 16:40:13+00:00): Ked si das vyhladavat budovy alebo tag "apartments" , vyhodi ti tisicky vysledkov. Ale ak clovek chce vyslovene vyhladavat a aj exportovat bytove projekty ktore maju aj nejaky svoj nazov a nie su iba anonymne panelaky tak sa musia dat nejako odlisit. Tak napriklad takto.
TZorn (2018-12-17 10:44:13+00:00): Hallo rama_ge

Was hat es mit den ganzen denotation=no_authorization_to_forward_to_PRD auf sich. Ich nehme an, dir ist da ein Fehler unterlaufen?
rama_ge (2018-12-17 15:56:38+00:00): Hallo TZorn, oh, das kann auf jeden Fall nur ein Fehler gewesen sein, ist sicher nicht absichtlich passiert. Der Spruch hört sich nach meiner beruflichen Tätigkeit an, aber wie kam der da rein? Bekommt man die Einträge gesammelt weg?