piebro/osm-data huggingface dataset:
muralito (2021-11-14 00:02:41+00:00): Hi. Both islands have joined, so there is one island now, and there should be only  one place=island object. Not sure how to keep the information to the old and the new status, but in OSM we map the world as it is nowadays, so .reference to geographical elements that have changed, maybe wikipedia and wikidata should reflect the new status.
muralito (2021-11-14 17:09:48+00:00): solved in OSM and in wikidata  with a new item for the new island, and end time for the old ones existning before the join.
SomeoneElse (2021-11-03 10:57:10+00:00): Hello and welcome to OpenStreetMap!

Can you please explain what your source for your additions is?  I'm sure that the names that you have added are not visible on aerial imagery.

Best Regards,
Andy
SomeoneElse (2021-11-03 10:57:24+00:00): Привет и добро пожаловать в OpenStreetMap!

Не могли бы вы объяснить, какой у вас источник для ваших дополнений? Я уверен, что добавленные вами имена не видны на аэрофотоснимках.

С уважением,
Энди
Shaun das Schaf (2021-11-04 11:00:01+00:00): Hallo,

bei Hotels mit Restaurant ist es üblich, jeweils einen Punkt für Hotel und Restaurant zu erstellen. So lassen sich Informationen, die sich nur auf eins von beidem beziehen, besser trennen.

Ich habe die Infos deshalb auf diese beiden Punkte aufgeteilt:
https://www.openstreetmap.org/node/9223499672
https://www.openstreetmap.org/node/9223499671

Ich habe außerdem noch ein paar Angaben wie Telefonnummer, E-Mail und Website ergänzt.

Viele Grüße
Shaun das Schaf
puma515 (2021-11-03 03:23:10+00:00): Hallo, Das müsste nochmal besser überprüft und angepasst werden, welche quelle nutzt du das du meinst das dort alles ein gefängniss ist?  mindestens die 2/3 der fläche ist ein Gewerbegebiet dort befindet sich unter andrem der firmensitz der SK gruppe, Homepage: https://www.sk-unternehmensgruppe.de/de/ 
Da ich dort nicht in der nähe wohne kann ich das aus der ferne nicht genauer überprüfen.

This would have to be checked and adjusted even better, which source do you use that you mean that everything there is a prison?  at least the 2/3 of the area is an industrial area there is among other things the headquarters of the SK group, Homepage: https://www.sk-unternehmensgruppe.de/de/ 
Since I don't live there, I can't check the distance exactly.
puma515 (2021-11-03 04:04:35+00:00): Die gebäude sind auf jedenfall richtig, habe da eben ein teile von einer ndr doku drüber gesehen so wie es dort wirkt ist die haftanstallt die südlich hälfte des geländes der nördliche teil neben dem sportplatz gehört nichr dazu. ein teil der fläche ist firmengelände der sk gruppe. 
Ob die 4 gebäude im nordteil auch zu der firma gehören oder anderweitig genuzt werden sollte vor ort überprüft werden.

The small building in front of the street Am Neuendeich next to number 50 is the headquarters of the company SK 

Schön gruß
puma515

The buildings are in any case correct, have just seen a part of a ndr documentary over it as it looks there is the adhesive stable the south half of the site the northern part next to the sports field is not one of them. part of the area is company premises of the sk group. 
Whether the 4 buildings in the northern part also belong to the company or are otherwise used should be checked on site.

Nice greetings
puma515
Nearby0051 (2021-11-03 08:42:21+00:00): Moin
Ich war in den paar Gebäuden, die näher an der Straße liegen vor Ort. (beruflich)
In den hinteren Teilen nicht. 
Das area hatte ich einfach nur von der vorherigen Funktion übernommen. Von einer Flächennutzungsänderung wüsste ich nichts, kann ich aber auch nicht ausschließen, da ich nur im vorderen Bereich war. 

Als Gefängnis habe ich es eingetragen, weil es eine Hafteinrichtung ist und das vor Ort auch so aussieht. 
Quelle ist also nur ein Diensteinsatz vor Ort, bei dem ich in zwei der Gebäuden war. Die Bezeichnung der Blöcke habe ich ausm Fenster erledigt 

Wenn du mehr Informationen hast, kannst du das Gelände und die Größe gern anpassen! 

Danke dir
puma515 (2021-11-03 21:18:10+00:00): Moin, 
Danke nun verstehe ich das besser.
Was ich nun über zeitungseinträge der shz lesen konnte wird der ganze bereich umgebaut nachnutzung von der kaserne der vordere teil ist jetzt das Gefängnis habe das ganze flächentechnisch angepasst und auch gleich den firmensitz von sk hinzugefügt.

Habe nun alles was ich aus der distanz auch nicht weiß an den noch offenen fehlerhinweiß in dem bereich geschreiben so das jemand der dort mal in der nähe ist anpassen kann.
https://www.openstreetmap.org/note/2845467
puma515 (2021-11-03 21:19:47+00:00): als kleiner tipp wen was erstellst wo nicht genau weißt ob das so passend ist oder da es noch nicht auf satbild zu sehen ist nur ungenau geht einfach beim erstellen den fixme wert hinzufügen. https://wiki.openstreetmap.org/wiki/DE:Key:fixme

Schön Gruß puma515
Владимир К (2021-12-24 14:52:44+00:00): Добрый день!
Эти участки еще не открыты?
Александр Карацуба (2021-12-25 06:19:06+00:00): Между Октябрьской и Красноармейской ещё закрыто, между Горького и Амурской открыли, внёс исправления.
Владимир К (2021-12-25 06:59:48+00:00): Спасибо.
Jakka (2021-12-27 21:29:30+00:00): iedere paal kan onmogelijk vier vtg laden ?
Sorcix (2022-01-08 14:36:06+00:00): Je hebt gelijk! Verwarrende vraag van Streetcomplete, het was mij niet duidelijk dat het over afzonderlijke palen ging. Heb 't rechtgezet.
fkv (2022-07-18 17:26:38+00:00): This changeset has been reverted fully or in part by changeset 123773269 where the changeset comment is: 113231318 revertiert, weil falsche inner-Members hinzugefuegt wurden; siehe auch meinen Kommentar zu CS 84477499
Map47 (2022-07-18 20:08:49+00:00): Salve,
Con la tua versione del multipoligono, hai creato delle isole interne con dei buchi non descritti.

Per questo OSMI avverte della mancanza di descrizione.

Le regole da adottare per la costruzione dei multipoligoni sono qui: 

https://wiki.openstreetmap.org/wiki/Relation:multipolygon

In particolare quella riferita a:"Island within a hole"
fkv (2022-07-18 20:20:30+00:00): Please write in English or German. I don't understand Italian, and this area is not in Italy.
Map47 (2022-07-19 08:00:49+00:00): Sorry... with DeepL Translate

Hallo,
Mit Ihrer Version des Multipolygons haben Sie interne Inseln mit nicht beschreibenden Löchern erstellt.

Deshalb warnt das OSMI vor dem Fehlen von Beschreibungen.

Die Regeln für die Konstruktion von Multipolygonen finden Sie hier:

https://wiki.openstreetmap.org/wiki/Relation:multipolygon

Insbesondere der Hinweis auf die "Island within a hole".

Hi,
With your version of multipolygon, you have created internal islands with nondescript holes.

This is why OSMI warns about the lack of description.

The rules to be adopted for constructing multipolygons are here:

https://wiki.openstreetmap.org/wiki/Relation:multipolygon

In particular the one referring to: "Island within a hole"
Map47 (2022-07-19 08:22:22+00:00): In OSMI
http://tools.geofabrik.de/osmi/?view=areas&lon=15.80947&lat=47.73963&zoom=14&baselayer=Geofabrik%20Standard&opacity=0.67&overlays=duplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways%2Cduplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways
fkv (2022-07-19 09:32:55+00:00): This is an OSMI bug. I've now reported it at: https://github.com/geofabrik/osmi_simple_views/issues/49

You should never trust validators blindly, but always use your own brain to determine what is wrong and what is right. First of all, when you edit landuse, you should check with recent aerial images. In this case, you would immediately see that there are forest areas between the scree and the bare_rock, and therefore it can't be right to add them as inner members to the forest multipolygon.

When you add inner members to a forest multipolygon, thus specifiying that these areas are not forest, you should also ask yourself what landuse there is instead. If you don't know, don't edit it. Create a map note or ask/tell the original mappers.

Austria is a country with a high density of competent mappers. Many of us check for errors regularly. So you don't need to do this, particularly if you don't speak the local language and don't know the specifics of alpine regions. You better focus on countries with a low density of mappers, or the area(s) where you live and have local knowledge.
Map47 (2022-07-19 10:10:25+00:00): Evidently your brain is superior to that of others.
I did not meditate your data, but simply specified that the holes in the inner area of the polygon are still forest in compliance with the rules of multipolygons.
fkv (2022-07-19 10:23:13+00:00): No, you didn't specify that they are forest. You did exactly the opposite by chosing the "inner" role for them, thereby exempting them from the forest.

By the way, the "outer" role would also be wrong, because they are not "holes in a hole" in a technical sense. They are areas between inner members, not inside inner members.
Map47 (2022-07-19 11:42:47+00:00): Consider what is written below, see also the figure

https://wiki.openstreetmap.org/wiki/Relation:multipolygon

Island within a hole
From the possibility of having multiple outer rings in one relation, it also follows that you can easily model "islands" within a hole:

<relation id="1">
  <tag k="type" v="multipolygon" />
  <member type="way" id="1" role="outer" />
  <member type="way" id="2" role="inner" />
  <member type="way" id="3" role="outer" />
</relation>

A construct like this would previously have required different multipolygon relations, one with way 1 being outer and way 2 being inner, as well as one with way 2 being outer and way 3 being inner. Such cascading is still needed when the "island" in the middle is something else than the area on the outside, but where the "island" is the same stuff it can just be made a hole in the hole. Beware though, that following this method, still a dual determination of the area mapped by way 3 will be created, as the hole and the island DO overlap!
fkv (2022-07-19 12:15:23+00:00): I studied that page 12 years ago. You don't need to copy&paste dozens of lines from it. As I've already explained, the forest spots here are technically NOT holes in holes. If they were, you'd need to assign them the "outer" role, not the "inner" role as you did.
Map47 (2022-07-19 12:37:08+00:00): A review never hurts.
However, it is not recommended to create inner eras formed by small adjacent areas as in this case.
You left in the middle of these adjacent areas two unspecified areas.
To avoid creating problems you should have drawn one large inner area, then filled this created hole with the various ground covers that would obviously not be part of the forest relationship.
fkv (2022-07-19 12:54:57+00:00): What problems are you talking about? There were no problems before you started your edits, and there are no more problems since I reverted them. Renderers handle such a case with ease. You can see that the forest spots reappeared in the standard map after I did the revert.

These in-between areas are not "unspecified". They specified as part of the forest by being within the outer ring and not within any inner ring.
Map47 (2022-07-19 13:06:15+00:00): What you write does not correspond to the truth. Check OSMI`s reports on the affected area now.

http://tools.geofabrik.de/osmi/?view=areas&lon=15.83117&lat=47.73110&zoom=13&baselayer=Geofabrik%20Standard&opacity=0.71&overlays=duplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways%2Cduplicate_node%2Csingle_node_in_way%2Cduplicate_segment%2Cway_in_multiple_rings%2Cintersection%2Cintersecting_segments%2Cring_not_closed%2Ctouching_rings%2Crole_should_be_inner%2Crole_should_be_outer%2Cinner_with_same_tags%2Cways
fkv (2022-07-19 13:16:31+00:00): I already told you that this is due to a bug in OSMI and I filed a bug report.
Map47 (2022-07-19 13:25:28+00:00): I disagree this is your opinion.
Luzandro (2022-07-19 13:27:45+00:00): as far as I can see, this is a special case of touching inner rings, which is valid in OSM

see also https://github.com/osmlab/fixing-polygons-in-osm/issues/31#issuecomment-294312299
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/113231318
Map47 (2022-07-19 13:57:52+00:00): It is true, however, in between there cannot be empty areas.
Luzandro (2022-07-20 06:50:34+00:00): Have you even read the link that I shared? That's your interpretation but it's not the way it's defined. There is no empty area as it's part of the outer but part of no inner and mapnik here or JOSM don‘t have a problem with it - actually this matches pretty much the part you have quoted with 'Such cascading is still needed when the "island" in the middle is something else than the area on the outside, but where the "island" is the same stuff it can just be made a hole in the hole', only that there isn't a single bigger hole where you have to cut out the smaller hole, but rather the "inner hole" results from multiple areas around it and doesn't have to be cut out anywhere.
You could of course restructure it to prevent such cases, but then you would need such cascading and create a surrounding helper object without attributes as inner and specify the enclosed forest areas as OUTER (or make them separate independent forest objects inside the inner that are no part of the multipolygon - arguably a somewhat worse representation)
Your change on the other hand, to create additional areas with role inner, was definitely wrong and lead to incorrect results.
Map47 (2022-07-21 08:29:27+00:00): Hi Luzandro
Let me preface this by saying that I use an automatic translator so maybe we don't understand each other.
You have written a whole treatise to justify the use of a mapping mode that is not recommended because it also creates problems when validating data with both OSMI and JOSM and perhaps to rendering software.
While restructuring the data as you mentioned and for that matter also the way described by WIKI, using a multipolygon with an outer and an inner perimeter to enclose the forest area getting the advantage of reducing the members of the multipolygon and also making it simpler. Then the area enclosed by the inner perimeter can be filled in at will without creating any problems for both OSMI and JOSM data validation and that will be rendered correctly. As you can see, the thing seems simple and trivial to me.
Luzandro (2022-07-22 10:37:39+00:00): It's questionable whether it's simpler for the average mapper if you need more objects, one of them without any tags. The only reason you have given so far, is to get rid of a WARNING in a single QA tool (unlike what you said, it does not raise problems with josm), but didn't name a single application that actually can't handle this case correctly. I don't mind if someone changes the structure while adding new information (maybe I would do it myself) or fixing an actual issue, but don't try to fix it, if it ain't broken, especially if you don't know the region, the language, or even english.

Your change may have eliminated the warning, but broken the data and that's not the first time you did this with such a change (it's only the first time you've responded to comments) - you even made exactly the same mistake at the very same location a few months earlier, so maybe it's not that trivial after all

https://www.openstreetmap.org/changeset/99633616

https://osmcha.org/changesets/104357642/
Map47 (2022-07-22 12:30:00+00:00): In fact, we are discussing it. The rules depend neither on knowledge of the language or the region but on their knowledge.
My edit did not break or change the input data but added a annel to signify that area is not empty. The mapping style created an undefined area that renders still display but that OSMI flags as possibly missing an outer annel. By entering the missing area as a forest and validating the data with JOSM it removes the tags from the annel as they match those in the multipolygon. After this change OSMI no longer reports this area as empty. OSMI cannot know if an empty area is left so intentionally or instead is a plotting error and rightly reports it. It does not seem appropriate to leave an area blank and rely on the render to display it. Therefore, I do not think it is appropriate to use this way of mapping in the case of multipolygons where you do not completely define all the adjacent interior areas. I would be a little more cautious about calling my mapping an error and deeming the one currently applied to the area to be correct.
Luzandro (2022-07-24 04:29:10+00:00): You did exactly the opposite and declared the areas as empty. You have even given 3 different sources of aerial pictures - all of which are inferior to the local provider basemap.at, but anyway the forest is clearly recognizable on any of them and you still managed to say that those areas are not part of the forest and contain nothing else. 

Whatever, I'm giving up now, that's pointless
Map47 (2022-07-24 20:07:36+00:00): I never questioned that those areas are forest. I tried to INSERT the areas with correct tags but having, at the end before loading the data, used the JOMS Update Multipolygon Tool I did not realize that these tags were removed with the now known result.
In the original mapping, the area had not been included (wrong) settling for visualizing a virtual area (thus not present in the data) thanks to the render (you don't map to the render).
I hope I have made myself clear by summarizing:

OSMI is very strict in checking the inner areas of multipolygons, in fact it punctually reports the presence of empty areas between the inner rings that touch each other. I would not call this behavior a known Bug.
It is wrong to intentionally leave gaps between the inner areas of multipolygons because the render shows what is expected.
JOSM generates problems with the Update Multipolygon Tool when among the inner areas of the multipolygon it finds an area with the characteristics of the outer area of the multipolygon (it removes the tags to the area ring since it is already present in the characteristics of the multipolygon).
It follows that if in JOSM we use the Update Multipolygon Tool the inner areas, with characteristic equal to the outer area of the multipolygon, these are not displayed by the render because they are considered empty (ring without tags).
To avoid the problems in these cases, the way to go is to create a large area inside the multipolygon, then insert the micro areas that make it into this newly created area. In this way, data validations by OSMI and JOSM will not give warnings, and the renders will display the areas correctly.
In multipolygons use mapping with adjacent inner areas only IF there are no holes between areas AND the areas are all different from the outer area.

If there are no contraindications I will update the multipolygon as it still has empty areas highlighted by OSMI
fkv (2022-07-24 20:22:44+00:00): If you ever touch this multipolygon (or any of my other multipolygons) again, I will file a complaint to the DWG.
Map47 (2022-07-25 21:12:30+00:00): OK! Then see to it personally that YOUR? multipolygons are updated according to the findings of the discussion, otherwise make explicit a valid reason for not doing so.
I highlight, once again, that a multipolygon only carats its outer area, while the inner area(s) must all be different from the outer area. Because of the above, special care must be taken not to include as internal areas of a multipolygon areas equal to its external area. Finally, in the specific case you have not included the two areas covered by forest (missing perimeter and tag).
Dimitar155 (2021-11-03 09:04:15+00:00): Здравей ivanatora,

Възможно ли е да използваш таговете natural=water + water=river за областите на реките вместо waterway=riverbank? Благодаря предварително.

Поздрави,
Димитър
ivanatora (2021-11-03 10:54:21+00:00): Ахой,

Да, рядко чертая речни русла и от едно време си знам waterway=riverbank. Сега научавам че имало по-нова комбинация за тагване :)

Поздрави,
Иван
Felis Pimeja (2021-11-22 19:16:01+00:00): Привет. Пожалуйста, не надо добавлять лишнего в отношения границ. Это приводит к ошибкам. 

На викиесть подробная статься про границы (https://wiki.openstreetmap.org/wiki/RU:Key:boundary). Если после её прочтения у тебя останутся вопросы, напиши мне - я постараюсь помочь.
Sandal man (2021-11-02 22:26:22+00:00): Hola, gracias por los cambios, pero ¿cuáles son esas dos líneas?
No tienen etiquetas
Saludos juan 
https://www.openstreetmap.org/way/998134575
https://www.openstreetmap.org/way/998134574#map=17/42.59921/-5.56958
Sandal man (2021-11-07 15:41:07+00:00): Eliminado debido a una respuesta incorrecta y sin respuesta del editor
harahu (2022-01-25 12:03:00+00:00): This changeset deleted this way: https://www.openstreetmap.org/way/211234843

That seems a rather controversial move.
Want to elaborate on reasons?
breno-au (2022-01-30 10:43:41+00:00): Apologies, this came up on the OSM Inspector "Ways with no tags" report by mistake. I've undeleted so the way is restored now.
harahu (2022-02-02 16:16:03+00:00): No worries! That can happen to the best of us. 

For context: This way featured in a discussion about "fuzzy areas" on the tagging mailing list. I wanted to have a look since it was mentioned and found it deleted.
eggie (2021-11-01 13:21:19+00:00): There is no traffic_sign maxspeed=60 here.
motor_vehicle= not allowed here?
Only agricultural.. moped and bicycle.
What is your source in this matter?


Greetz,
eggie
eggie (2021-11-01 13:16:14+00:00): Hi.. c128 

What do you mean with kerb=raized?
https://wiki.openstreetmap.org/wiki/Key:kerb

No  kerb in the middle of the road.

Greetz,
eggie



Greetz,
eggie
eggie (2021-11-01 13:05:58+00:00): Beste c 128 Hier is geen cycleway=track  
Dat zijn parallelfietspaden. 
Het is een fietsstrook... Dus cycleway=lane..
Ik draai je aanpassing terug.. 

MVG
eggie
eggie (2021-11-01 13:07:18+00:00): reverted by changeset #113235664
eggie (2021-11-01 13:10:36+00:00): Have a look here please

https://wiki.openstreetmap.org/wiki/Tag:cycleway%3Dlane

cycleway=lane was correct.
Greetz,
eggie
Andrea Musuruane (2021-11-02 10:16:28+00:00): Ciao. In questo nodo manca il punto e virgola per separare i numeri di telefono. Ciao, Andrea
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/113232902
Andrea Musuruane (2021-11-02 10:21:31+00:00): Ciao. Ignora il commento precedente che si riferisce ad altro changeset. In questo nei nodi https://www.openstreetmap.org/node/9216117353 e https://www.openstreetmap.org/node/9216117356 non ci vogliono le virgolette nel tag contact:mobile. Ciao, Andrea
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/113232902
Dino Michelini (2021-11-01 18:26:01+00:00): Ciao, ti segnalo che nel changeset hai modificato i limiti amministrativi dei comuni di Trevignano e Bracciano. Quali dati hai preso come riferimento?
RivalgoAV (2021-11-02 20:40:32+00:00): Ciao, credo di averlo fatto inavvertitamente mentre navigavo e me ne scuso. È possibile ripristinare la modifica?
89r (2023-10-19 14:08:35+00:00): а тут точно есть АЗС? когда я проезжал это место в сентябре, тут даже намёка заправочные колонки не было — просто место для отдыха.
literan (2023-10-19 18:26:16+00:00): правке два года)) тут была контейнерная АЗС, временная. Видимо, ее убрали. Смело удаляйте!
martinst (2022-06-09 18:07:30+00:00): Sollte das nicht "Jagdhütte" heißen?
user_5359 (2021-12-16 10:02:54+00:00): Hello! Please this entry! We use british english words for the keys! And a atm doesn't have a name (he can have a operator or description).
canfe (2022-07-26 18:17:05+00:00): Really rooftop???
Rodrigo Rega (2022-07-30 12:04:39+00:00): Fixed, thank you!
Heinz_V (2022-01-11 16:33:41+00:00): Why do you delete a NH-relation?