piebro/osm-data huggingface dataset:
dhx1 (2025-07-07 09:12:39+00:00): Tags/additions are based on BOM radar information pages _and_ WMO weather radar database data for approximate location, and traced satellite imagery for accurate location.

A small number of other fields (such as frequency and antenna configuration) are solely from the WMO weather radar database which is where BOM publish such data to, and seemingly not available anywhere else. This is factual data (essentially from a single primary source who could supply such data). Factual data cannot be copyrighted in Australia, and LWG have also generally decided in https://osmfoundation.org/wiki/Licensing_Working_Group/Minutes/2023-08-14#Ticket#2023081110000064_%E2%80%94_First_party_websites_as_sources that it is fine to import factual data such as opening hours into OSM due to its factual basis and inability to be copyrighted.
dhx1 (2025-07-07 09:13:09+00:00): Also--this is not a mass import. Just Australian sites being added one by one, being modified and checked by manual human review.
dhx1 (2025-07-07 09:14:04+00:00): To clarify--seemingly 95%+ of weather radars in Australia are already existing in OSM. It's mostly just a small number of extra tags such as the frequency of the radar which are absent.
aharvey (2025-07-08 03:30:14+00:00): The Linked LWG determination doesn't really apply here, that's saying it's okay to source the opening hours of a restaurant A from their own website, then the opening hours of restaurant B from their own website and so forth. I agree that's fine, I do this sometimes too.

If someone collected and maintained a bunch of data into a database and published that it could still be covered by copyright or in some jurisdictions database rights, so we won't take that collection of data and add it to OSM. It doesn't matter if that is "factual" data it still can be copyrighted or at least the publisher claims it to be copyrighted until tested in the courts. We're not going to push those limits in OSM, if there's potential to be an issue we'll play it safe.

I think the question is then is taking selected data from http://www.bom.gov.au/australia/radar/info/nsw_info.shtml considered taking a collection of data (which we generally can't use) or considered a single data point (which we could use). I'm not sure, it's just that looking at the amount of data added in this changeset it certainly felt like mass-adding a whole collection of data.

I can see data about antenna polarisation, elevation, frequency, height, manufacturer, power rating, reference codes, start dates, tower type/construction and names.

I want to see this data in OSM, but I don't want to be testing the limits of copyright and risk the reputation of OSM and assurances we make about the data to downstream users.

The WMO site makes no mention of copyright, and therefore has full protection and isn't under an open license.
dhx1 (2025-07-10 09:37:25+00:00): Which fields are of concern and what volume is of concern?

I'm aware of Australian weather radar information being located currently in OSM (before any changes I have made), the BOM website, WMO Weather Radar Database, and ACMA RRL database. For many fields, the same information exists in multiple sources. For example, the WMO Weather Radar Database and ACMA RRL databases both share information about the frequency, power output, elevation and antenna. All four sources share some rough (not always the same) coordinates, which are not kept anyway. They also all provide a name which generally differs between source. If anything, the ability to retrieve/consolidate fields from multiple sources indicates to me a better approach may be to keep such information in Wikidata (most radars I think have a Wikidata item someplace) and remove the detailed fields from OSM to avoid duplication. Wikidata has the benefit of allowing 4 names to be listed (and one chosen as preferred), with all 4 names referenced to one of the 4 different sources.

Other fields are mostly just standard OSM fields that would get added to any weather radar such as `monitoring:weather=yes`.
aharvey (2025-07-10 09:47:17+00:00): The fields I mentioned previously "data about antenna polarisation, elevation, frequency, height, manufacturer, power rating, reference codes, start dates, tower type/construction and names" but really anything copied from other datasets is problematic.

The ACMA RRL database is not compatible for use in OSM, see their license terms at https://www.acma.gov.au/radiocomms-licence-data#terms-and-conditions.

I'm not sure what difference the the data being the same makes? If the same data is published by A, B, and C if it's not sufficiently licensed we still can't use it in OSM.

Wikidata I believe has a much lower barrier in terms of copyright, they are okay with copying data from copyrighted sources under the claim "data is not copyrightatable" but generally OSM sets the bar higher that if the publisher claims their data is protected by copyright we don't try to go against them.
atchisson (2025-07-09 10:32:06+00:00): Bonjour, 

pour les parkings en bord de rue, je vous recommande d'ajouter "parking=street_side" ou "parking=lane" en fonction des cas, sinon ils sont affichés de très loin sur les cartes
Ruslan Fatih (2025-07-05 04:46:20+00:00): Нахуя ты оригинальное название переписал?
evgeniyakz (2025-07-21 11:00:05+00:00): Оно не кажет на мериканской карте 
 https://americanamap.org/#map=14.96/43.25377/76.94419
mavl (2025-07-06 14:30:13+00:00): Здравствуйте. Вы удаляете теги name.  
  
http://nrenner.github.io/achavi/?changeset=168508576  
http://nrenner.github.io/achavi/?changeset=168508537  
http://nrenner.github.io/achavi/?changeset=168508403  
http://nrenner.github.io/achavi/?changeset=168508244  
  
Это неправильно. У объектов с названиями должен быть тег name.  
  
https://wiki.openstreetmap.org/wiki/RU:Key:name
Faultis (2025-07-05 05:17:08+00:00): I'm hoping that this gets accepted and Google maps finally accept the numerous requests i sent in to remove this road from gps navigation. Its caused me a lot of issues and i've had 3 people get bogged at the back of my property over the last 2  years. The road is only in decent condition about half way through the property. It runs over the creek where there is no bridge you must cross through the water. It also crosses over a gully/creek that feeds into hardway creek that frequently gets washed out as of the moment it is impassable and i have no access to the back paddock of my property. The gates are padlocked however it doesn't stop people from driving around the back gate due to fence loss from the massive bushfires we had years ago
aharvey (2025-07-05 12:51:40+00:00): In OpenStreetMap edits like this aren't "requests", instead they immediately update the map, there's no review. Other mappers map choose to review your changes and request feedback or after discussion if we feel the changes are detrimental we might revert or roll back changes.

In this case your changes look good, and in line with community mapping standards. We get a lot of people come in and delete the whole road/track/driveway just because it's private, but we don't do that in OSM https://wiki.openstreetmap.org/wiki/Why_can%27t_I_delete_this_trail%3F so thanks for actually marking it as private instead.
Gregory Peony (2025-07-05 15:19:37+00:00): The footprints I flagged clearly contain the buildings' shadow in their size. Take care to not include the shadow while mapping the shape and size of footpritns. I recommend that you map footprints slightly smaller than the roof seen in the imagery becasue of the likely overhang. You can scale selected features in ID with shift+(-/+) after squaring or circularising them.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/168509457
NeisBot (2025-07-05 05:54:50+00:00): Hello, welcome and thank you for your contribution to OSM!

Your changeset was commented because your added description or slogan contains 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.

Could you please revise your description accordingly?

#MapWithoutSpam #Tags #Description
NeisReview (2025-07-18 04:56:32+00:00): ✅ Corrected by https://osm.org/changeset/168514765
evgenykatyshev (2025-07-06 08:56:41+00:00): Привет. Спасибо за добаленное название. Единственно, хотел бы заметить, что высота вершины — это не часть её названия, поэтому не нужно писать её в скобках. Для высоты есть отдельное поле ele.
Gregory Peony (2025-07-05 15:14:22+00:00): The L shaped footprint you mapped is more likely to be two seperate buildings.
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/168509657
NeisBot (2025-07-05 06:21:42+00:00): Hello, welcome and thank you for your contribution to OSM!

Your changeset was commented because your added description or slogan contains 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.

Could you please revise your description accordingly?

#MapWithoutSpam #Tags #Description
NeisReview (2025-07-18 04:55:44+00:00): 👎 (Partly) Reverted due to lack of response from the original contributor by https://osm.org/changeset/169088985
CAM-Gerlach_Repair (2026-06-06 03:19:06+00:00): Removed  SEO spam POI for Two Men in a Junk Truck in Baltimore with suspicious address that no longer exists at this location, if it ever did, in changeset 183720925

https://osm.org/changeset/183720925
vietnam321 (2025-07-05 06:24:40+00:00): Look like I did wrong, will be fixed shortly
Geogast (2025-09-28 14:02:00+00:00): Oi Victor(?), tudo bem?
Obrigado por mapear o Ramal de Jurubatuba, importante mapear os ramais ferroviários desaparecidos.
Mas, ele estava mapeado já: nos ways highway=track. Por exemplo: entre Barragem e Evangelista de Souza, estava há anos o way 789683408 com tags de highway=* e abandoned:railway=* – isso é suficiente. Não é recomendável desenhar um way novo sobre o way existente. De fato, agora é redundante. Tem muitas pessoas no OSM que dizem que não devemos mapear coisas do passado (como antigas ferrovias) – eu não acho isso. Mas, sim, melhor manter as coisas quanto mais simples, melhor; ou seja: deixar tags de abandoned:railway=* no way highway=* – e não desenhar ways novos. 
Abraço e bom trabalho! Geogast/Daniel
fabiotofy (2025-07-18 20:40:47+00:00): Ciao buona sera. Come già ampiamente discusso sui vari forum e secondo le regole di wikipedia, nel campo name andrebbe messo ciò che viene esposto sui cartelli stradali presenti ad inizio dei limiti Comunali. Questo per aiutare gli utenti ad orientarsi con la mappa secondo quanto effettivamente esposto sul territorio. La cosa multilingua è già gestita da OSM da illo tempore grazie ai tag specifici
Lordmcfuzz (2025-09-16 20:28:28+00:00): Why was North Beacon Street changed to Bicycle no? There is nothing to say that bikes are prohibited here.
Map_HeRo (2025-09-03 17:12:03+00:00): Hallo gmbo,

ich habe gesehen, dass du bei den Stolpersteinen in Bebra u.a. ein Tag 'memorial:addr' ergänzt hast. Das ist nicht korrekt, das der Stolperstein keine eigene Adresse hat.

Die Adressinformation ist aber trotzdem bereits vollständig vorhanden, und zwar mit den dokumentierten Tags 'object:city / street / houseno'. Ich werde daher die memorial:addr bei Gelegenheit wieder löschen.

Des weiteren ist mir das ebenfalls undokumentierte Tag 'material:de=Messing' aufgefallen, dass Du ergänzt hast. Wozu soll das gut sein? Wollen wir zukünftig alle Tags zweisprachig mappen, einmal im OSM-üblichen englisch und dann noch mal mit dem suffix :de? 

Mir ist das bisher nicht bekannt. Ist das mal in irgend einer Runde diskutiert und beschlossen worden?

Gruß Mikke
DD1GJ (2025-09-04 11:57:59+00:00): Hallo Mikke,

memorial:addr ist bei Stolpersteinen weit verbreitet und wird auch ausgewertet. Daher bitte nicht löschen.

Viele Grüße, Joachim
Map_HeRo (2025-09-04 17:27:39+00:00): Hallo Joachim,

Danke für die Info. Weit verbreitet heisst ja nicht, dass es gut ist. M.E. sollten sich die systematisch mit object:*=* gemappten Adressen besser auswerten lassen, als Adressen, bei denen alle Informationen in einem Textfeld stehen. Und warum man 2 Adressinformationen zur Auswertung benötigen soll, erschließt sich mir schon gar nicht. 

Wenn jemand das object:*=* Schema nicht kennt und stattdessen memorial:addr taggt, ist das eine Sache. Das nachträgliche Anhängen von memorial:addr=* an bereits erfasste object:*=* macht für mich überhaupt keinen Sinn.

Vielleicht kannst Du mir da mal auf die Sprünge helfen. Auch im Hinblick darauf, wozu das Tag material:de=Messing gut sein soll. Wird das auch ausgewertet? 

Davon mal abgesehen, ist bereits material=brass Quatsch, weil der Stolperstein per se aus Beton ist und nur eine Oberfläche aus Messing hat. Das gilt für alle Stolpersteine, ist also bereits in "Stolperstein" impliziert. Wenn wenn man das trotzdem redundant zusätzlich taggen will, dann sollte man es auch richtig machen, also material=concrete + surface=brass. Oder sehe ich das falsch?

Grüße aus Hessen von Mikke
gmbo (2025-09-05 07:43:22+00:00): Hallo Mikke,
Ich finde die Änderungen, die du gemacht hast absolut nicht gut und unangebracht.
Du mekkerst Dinge an die dir nicht gefallen mögen. Darüber kann man diskutieren.
Aber, dass du einfach so etwas wie die WikidataID, das Verlegedatum Wikimedia_commons löscht istgar nicht in Ordnung.
Jedes Denkmal hat zwar keine Postanschrift, aber eine Adresse an der es steht oder in dem Fall eingelassen ist.
Der Teil des Stolpersteins der sichtbar ist ist nun mal aus Messing, auch wenn er den Namen Stolperstein trägt. Ohne den Betonstein auf dem die Messingplatte angebracht ist ließe sich der  Stolperstein nicht im Boden befestigen, so wie man keine kaum eine Statue im öffentlichen ohne einen Beton oder Steinsockel aufstellt.
Über den zusätzlichen :de Eintrag  kann man reden, da bin ich mir nicht sicher wofür der genutzt wurde. 
Wenn jeder alles was er als Quatsch bezeichnen würde einfach löscht gibt es bald kein OSM mehr
gmbo (2025-09-05 07:56:37+00:00): War vorhin wohl etwas müde, 
also das mit dem löschen der ID, des Verlegedatums usw hast du ja gaar nicht gemacht, kann das aber oben nicht mehr korregieren. Also entschuldige bitte die Bemerkung dazu.
Map_HeRo (2025-09-05 10:49:51+00:00): Hallo gmbo,

wie Du bereits bemerkt hast, lösche ich normalerweise nicht einfach Attribute, sondern hinterfrage eher den Sinn derselben. Entschuldigung ist natürlich akzeptiert.

Im Hinblick auf die Adressen muss ich Dir widersprechen: Ein Denkmal, egal welcher Art, hat im Normalfall keine Adresse. Bei Denkmalen, die sich in der Nähe von Gebäuden befinden, kann lediglich ein Bezug zu der Gebäudeadresse hergestellt werden. Dazu gibt es das noch relativ neue object:*=* Schema. Wenn das bereits am Denkmal getaggt ist, ist ein Erfassen dieser Bezugsadresse mit memorial:addr als Textstring m.E. unsinnig und als redundante Information überflüssig. Oder sehe ich da etwas verkehrt?

Ob ein Stolperstein als Objekt aus Messing oder aus Beton mit einer Messingoberfläche besteht, ist mir eigentlich egal. Das Erfassen des Plakettenmaterials mit material=brass ist ohnehin eine redundante Info, da diese Plaketten immer aus Messing sind. Aus meiner Sicht also Quatsch, würde ich aber trotzdem nicht löschen, wenn ein anderer Mapper es schön findet. 

Das material:de=Messing ist dagegen doppelt redundant und wenn Du selber nicht weißt, wofür das gut sein soll, dann frage ich mich, warum Du das an alle erfassten Steine angehängt hast. Im Wiki ist es jedenfalls nicht dokumentiert, und wenn das jetzt bei Stolpersteinen Usus wird, sehen wir als nächstes vielleicht highway=track + highwayd:de=Feldweg. Wollen wir das?

Wäre schön, wenn Du zur Klärung dieser Fragen beitragen könntest.  

Gruß Mikke
gmbo (2025-09-05 12:53:10+00:00): Hallo Mikke,
Das mit dem :de=Messing wäre ich auch mit dir einig.  Die :de Tags sollten nur verwendet werden wenn es einen englischen Begriff dafür nicht gibt. Da der wohl in das Preset Stolpersteine eingeflossen ist, werde ich schauen, dass der da wieder raus kommt. 
Wie oben beschrieben wird der Tag memorial:addr der zu den ältesten Tags der Stolpersteine gehört, noch oft benutzt. Früher gab es dann noch die Tags addr:street usw. Die sind nach einigen Diskussionen in object:street usw. geändert worden.

Gruß
Gisbert
Map_HeRo (2025-09-05 19:20:43+00:00): Hallo Gisbert,

Danke für die Info. Wenn das material:de im JOSM preset steht, ist mir auch klar, warum das Verwendung gefunden hat. Wäre sicher gut, das aus dem preset zu entfernen, bei iD ist es nicht enthalten.

Dass memorial:addr für einen Vollständigkeitsabgleich verwendet wird, habe ich im Wiki gesehen, bin aber davon ausgegangen, dass für diesen Abgleich auch die object:*=* Tags Verwendung finden.

Möglich ist es auf jeden Fall, es liegt nur an den Auswertern, das zu realisieren. Welches Tagging dafür verwendet wird, ist mir im Prinzip egal, auch wenn ich das object:*=* Schema wesentlich besser finde, weil es universal anwendbar ist und keine Sonderlösung wie memorial:addr. Sinnvoll fände ich auf jeden Fall, sich hier auf eine Lösung zu einigen, damit  der Adressbezug nicht redundant erfasst wird, im schlimmsten Fall noch mit 2 verschiedenen Adressen.

Ich werde das bei Gelegenheit mal im Forum ansprechen.

Gruß Mikke
adiatmad (2025-09-01 03:24:22+00:00): Hi, hope you are doing well. Just out of curiosity, could you please share the source of this edit? 
You only mentioned ATRBPN, but which one?
Thanks!
relaemanila (2025-09-01 03:56:28+00:00): Hello! I used Copernicus imagery to mark the progress of the tollway. They provide the latest imagery anywhere around the world.

As for ATRBPN, I neither use it nor mention it as I do not know what that is. Thank you!
adiatmad (2025-09-01 04:21:45+00:00): Cool, you mentioned Sentinel-2 already in your source.

As for ATRBPN, I meant this one, sorry for not providing this earlier
- (https://pewu.github.io/osm-history/#/way/1412416584)
- (https://pewu.github.io/osm-history/#/way/1412416590)
relaemanila (2025-09-01 04:48:17+00:00): About the ATRBPN, I didn't originally add the source (ATRBPN) when I first modified the section. When I came back to modify the section again (for the completion status), the source was there, but I didn't touch it at all.
NeisBot (2025-07-05 07:18:43+00:00): Hello, welcome and thank you for your contribution to OSM!

Your changeset was commented because your added description or slogan contains 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.

Could you please revise your description accordingly?

#MapWithoutSpam #Tags #Description
AkaruiAikidoWebPresenceEdits (2025-07-05 09:10:02+00:00): What information specifically is the problem?
NeisReview (2025-07-05 12:01:31+00:00): Please see https://wiki.openstreetmap.org/wiki/Spam#SEO_Spam
AkaruiAikidoWebPresenceEdits (2025-07-05 13:10:58+00:00): Hi, thanks I just read that. I've made some changes along those lines to anything that look like it could violate that
NeisReview (2025-07-18 04:55:02+00:00): 👍 Thank you for updating the element https://osm.org/changeset/168522896
aixbrick (2025-07-05 09:09:04+00:00): Hallo,
bitte Geschäfte nicht einfach löschen, wenn dort noch ein Ladenlokal existiert, sondern ein https://wiki.openstreetmap.org/wiki/DE:Lebenszyklus-Pr%C3%A4fix verwenden.
Umgesetzt mit https://www.openstreetmap.org/changeset/168514261.
Gruß
AurélienQ (2025-07-06 13:29:20+00:00): Non, c'est un tram-train, pas un tram. Les tags étaient bon, je révoque le changeset.
BubbaJuice (2025-07-05 07:36:26+00:00): And USGS 3DEP!
Kovoschiz (2025-07-06 04:38:32+00:00): Please don't directly delete them, as they still represent a store space, and may contain addresses. It makes tracking and updating them later more difficult, wasting effort to locate them. Change them to a plain "point", or "vacant".
NeisBot (2025-07-05 08:15:45+00:00): Hello, welcome and thank you for your contribution to OSM!

Your changeset was commented because your added description or slogan contains 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.

Could you please revise your description accordingly?

#MapWithoutSpam #Tags #Description
NeisReview (2025-07-18 05:09:38+00:00): Reverted by https://www.openstreetmap.org/changeset/168556772
luisforte (2025-07-05 08:33:18+00:00): Estes boundary census têm pouco em comum com os limites e designações definidas pelo INE.
A relação 19323791 por si designada de Vila de Sintra aglomera na realidade duas entidades censitárias oficiais distintas, com nomes distintos (Sintra e Vila de Sintra). 
Os limites, estão longe de ser coincidentes com os limites oficiais. Não faz qualquer sentido definir estes limites a olho, deixam de ser limites oficiais, sendo por isso  boundary_type=census ficticios.
Esta informação não acrescenta qualquer valor. Considere, por favor, substituir estes elementos por uma importação dos dados e geometrias emitidas pelo INE.
Jota Cartas (2025-07-09 03:00:15+00:00): Hi luisforte,
Desculpe so responder agora, mas os mails da OSM estavam a ir todos para SPAM. Efetivamente tem razão, a relação Sintra (vila) (19323791) criada por mim não existe nos mapas do INE. Devo apaga-la? Se achar bem, assim farei.
Cumprimentos
João Lemos
luisforte (2025-07-09 22:59:11+00:00): Viva
Na minha opinião, o melhor seria importar os dados do INE.
Já o inconveniente de as duas áreas estarem fundidas, é que resultam numa nova área que não tem a ver com o census e assim sem utilidade.
Luís
Jota Cartas (2025-07-10 01:48:25+00:00): Ok, vou eliminar a relação Sintra (vila) 19323791 , e ficam só as relações importadas do INE: Vila de Sintra(038622) e Sintra (subúrbio) (022713)
CrisR87 (2025-07-05 08:29:17+00:00): https://12ft.io/https://www.innsalzach24.de/innsalzach/region-waldkraiburg/waldkraiburg-ort46534/grundwasser-verseuchung-in-waldkraiburg-beseitigung-chemischer-altlasten-pfos-pfas-ewigkeitschemikalien-93813487.html
citrula (2025-07-05 19:15:23+00:00): Please use the expanded suffix ("Parkway" instead of "Pkwy") for street names
NeisBot (2025-07-05 08:51:44+00:00): Hello, welcome and thank you for your contribution to OSM!

Your changeset was commented because your added description or slogan contains 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.

Could you please revise your description accordingly?

#MapWithoutSpam #Tags #Description
NeisReview (2025-07-18 05:08:34+00:00): 👎 (Partly) Reverted due to lack of response from the original contributor by https://osm.org/changeset/169089236
NeisBot (2025-07-05 09:06:33+00:00): Hi Chu Myat Noe, welcome and thank you for your contribution to the OSM project!

To help improve collaboration and make your edits easier for others to understand, please consider providing brief descriptions of your changes in the comment field. This will make it easier for the community to follow your adjustments. You can find some helpful tips on good comments here: https://osm.org/wiki/Good_changeset_comments

Furthermore, based on your map edits in this changeset, I’ve drafted a suggestion for what a comment could look like: "Added new buildings and their outlines to the map."

PS: I’ve also sent this message via the OSM messaging system for your convenience.

#HelpfulComment #NoComment #AIgenerated