piebro/osm-data huggingface dataset:
LeTopographeFou (2015-10-08 22:58:14+00:00): Thanks for your care aseerel4c26. Because the type=broad_leaved has been declared as deprecated on the Wiki, on TagInfo, and in JOSM (where I've had more than once warnings on this fact), I did not feel the need to open any discussion with the community neither to create any page to document a fact already approved somewhere else. Sorry if I thought wrong. If the DWG thinks that it is vandalism and/or if this property is not deprecated then I don't mind about reversing it and let other guys fixing it at their own pace.
fkv (2016-07-30 22:13:22+00:00): The automated edits code of conduct does not depend on whether a tag is "deprecated". So-called deprecated tags are not necessarily wrong. First of all, many deprecations are done by single users who edit the wiki without prior discussion. Even if a formal proposal has been accepted by voting, the voters are just a handful of users, while the objects in the database have been created by thousands of users. Secondly, when you want to replace "old" tags by "new" tags, you need to make sure that no information is lost! With leave_type=broadleaved you lose the information whether the tree is a palm, so don't do that unless you add other tags like species=*. If you had discussed your edits beforehand, as you were obliged to, you would have been aware of that, and you certainly would not have done these mass edits at all.

It's also bad manners to change objects which were created by others without asking them.

I was already preparing a revert of one of your changesets (that damaged objects that I had carefully created) when I noticed that a discussion is ongoing here. Given that the DWG was informed 10 months ago, why are the abusive changesets not reverted yet? What are they waiting for?
SomeoneElse (2016-08-01 17:31:06+00:00): @fkv When I looked at the changes in here back in October last year I didn't see any evidence of data loss (though I only looked at a sample of the 5341 nodes).  
Whilst a change like type=broad_leafed => leaf_type=broadleaved should have been discussed beforehand, in case someone was aware of an edge case where the change could be wrong, in retrospect I can't think of one.
Can you give me an example of where something was removed that should not have been?
fkv (2016-08-01 18:43:39+00:00): Just take the first few nodes in this changeset as examples. They are located on Plaza de la Ciudad de la Habana, where there are palms and other trees. The non-palms were changed from type=broad_leafed (old spelling variant, but that's another issue) to leaf_type=broadleaved, losing the information that they are not palms. Interestingly, the palms were left untouched, they are still tagged with type=palm. I guess that LeTopographeFou didn't know what to do with them, or his validator didn't blink. Given that there are still 18275 type=palm and 57508 type=broad_leaved instances in the database (according to Taginfo; even after all those validator-triggered mass edits, not only by LeTopographeFou), it's obvious that these tags are still widely used to distinguish palms from other trees, and that the wiki is wrong in declaring them deprecated.
LeTopographeFou (2016-08-01 19:23:15+00:00): Hi, this changeset was made a long time ago and I thought it has been reverted (with some others of the same type and of the same period). I'm going to ask for a revert by mail if it is still feasible.
SomeoneElse (2016-08-01 20:39:36+00:00): @fkv thanks; I wasn't aware of the use of "type" as meaning "not a palm tree".
@LeTopographeFou thanks; I've got the message requesting a revert.  Before doing it I'll ask around to see if there's any better way to indicate "not a palm tree".  
As I understand it (from reading wikipedia just now) Palm Trees https://en.wikipedia.org/wiki/Arecaceae are Angiosperms , as are other broadleaved trees such as https://en.wikipedia.org/wiki/Oak .  However Palm trees are in https://en.wikipedia.org/wiki/Monocotyledon and typical temperate broadleaved trees in https://en.wikipedia.org/wiki/Eudicots .  For comparison conifers are in https://en.wikipedia.org/wiki/Gymnosperm .  Strictly speaking therefore "leaf_type=broadleaved" would be correct for both palms and non-palms, but were all of the examples in this changeset definitely NOT palms?  That's what I'll need to investigate and the tagging that I'll ask about, and I'd like to ask before the revert so that if there are other changes to be made they can be done at the same time.
fkv (2016-08-02 00:16:16+00:00): I was asking for a revert, but it might be better to restore the type=* tags while keeping the leaf_type=* tags. It does not hurt to have both.
You could use taxon=* to mark palms, but there is no single taxon that includes all non-palm broad-leaved trees. Eudicots would be missing magnoliids, Austrobaileyales etc. You also need to consider that these classifications are permanently disputed and changing. The lowercase, suffixless taxon names like "eudicots" do not even indicate a taxonomic level. It's impossible for average mappers as well as data users to use such tags.
SK53 (2016-08-02 11:56:00+00:00): I tend to agree with @fkv on all issues: 1) large scale updates often have unpredictable side effects; 2) originally we distinguished between conifers/dicots aka broad-leaved and palms (and possibly one or two others) using a range of tags wood/type etc. Ultimately these have been replaced by leaf_type. However, the palm issue (and also Gingko) highlight that leaf_type=broadleaved doesn't quite do what I think most of us expected. As @fkv nicely shows  modern systematics doesn't help either. Whereas I would expect ordinary mappers to not know that Gingkos are gymnosperms; I think most should be able to distinguish palms.

To summarise: the tagging issues involved are rather more complex that initially apparent. Reversion at least would retain mapped information. Further discussion is needed on general values for leaf_type before such wholesale changes are introduced automatically.
SomeoneElse (2016-08-02 14:24:48+00:00): OK, done: See https://www.openstreetmap.org/changeset/41192016 .
LeTopographeFou (2016-08-03 18:32:07+00:00): @SomeoneElse: Thank you!
seav (2015-10-06 21:32:14+00:00): I have removed the boundary tags from the Philippines treaty lines and Kalayaan claim lines to prevent confusion with the boundary based on the baseline defined by Republic Act No. 9522.

Based on the the text of the 3 treaties, the treaty lines were not meant to be actual boundaries but rather a "selection" polygon to encompass the islands of the Philippines.

Furthermore, the lines are erroneous because they encompass Miangas Island which has been shown to be under Indonesia's jurisdiction as a result of international arbitration (see "Island of Palmas Case").
schadow1 (2015-10-09 14:17:29+00:00): How can we present the Kalayaan Group as mentioned on RA9522?
seav (2015-10-09 18:59:28+00:00): The Kalayaan Island are defined as a "regime of islands" in RA9522. Based on UNCLOS, this means that they automatically get a 12 nautical-mile territorial water, 24 nautical-mile contiguous zone, and a 200 nautical-mile EEZ (but only if the island is capable of sustaining habitation on its own).
schadow1 (2015-10-10 12:34:47+00:00): So do we use UNCLOS or PD 1956 as suggested by RA9522. If UNCLOS should we draw a 12nm territorial waters around Thitu, etc similar to what is on Scarborough?
seav (2015-10-10 21:13:35+00:00): "Regime of Islands" is from UNCLOS so that is what should be followed[1]. So this is similar to Scarborough Shoal. (However, note that Scarborough Shoal's 12-nm line is wrong. It should only be drawn around the rocks that are above water at high tide, and not around the submerged reef.)


[1] http://www.un.org/depts/los/convention_agreements/texts/unclos/part8.htm
literan (2015-10-07 12:49:47+00:00): Это по результатам съемки с дрона? отлично!!! а если возможно, нельзя ли увидеть результат съемки, ну, как подложка в JOSM выглядит?
unsungNovelty (2017-04-12 10:22:47+00:00): Hi Sascha Bischoffberger,

I just came across this changeset and observed that you changed the tag for this feature https://www.openstreetmap.org/way/37893154. This used to be a lannduse=village_green which is a correct tag but not landuse=green as per the wiki http://wiki.openstreetmap.org/wiki/Tag:landuse%3Dgrass. Can you please check this out and correct this if need? Thanks in advance.

Best Regards,
Nikhil Prabhakar.
Sascha Bischoffberger (2017-04-12 21:39:29+00:00): Hi Nikhil,

thx for your response. Actually I didn't "invented" this tag. I just edited it on it's borders (for fences etc.). But we can still discuss the issue. ;)

I checked your link for the grass right now. It's kind of funny, that the description for village green and grass in the English wiki doesn't exact correlate with the German description.

In other words, for the German wiki/users the village green is used for special places in (small) villages. All other mown and managed "green areas" are mapped as grass.

Futhermore, you wrote "landuse=green". This area is actually mapped as "landuse=grass". Do you see it in English in India tagged as "landuse=green"?

Btw, thx for checking maps in Leipzig, Germany. :)

Best Regards,
Sascha
TinaUNM (2015-10-20 04:50:03+00:00): #vsfsmapping
ViriatoLusitano (2015-10-12 02:31:18+00:00): Sempre fizeste alguma coisa, vá. :)
Patrícia Silva Leal Coelho (2015-10-14 01:35:06+00:00): Penso que a localização está equivocada. por gentileza, verifique.
igeopr (2015-10-07 12:18:00+00:00): Excelente edición compañero OpenStreetMapper!
Carlos Martin Noriega (2015-10-07 17:55:36+00:00): Hola Bianca. El campo es leisure=pitch y sport=soccer (si es fútbol) y no es correcto que lo unas con las vialidades, no es necesario la etiqueta "area=yes".
En este enlace puedes ver un ejemplo:
http://www.openstreetmap.org/edit?editor=id&way=374212948#map=19/18.15029/-94.42722
Saludos!
Verkehrsrot (2015-10-15 14:11:24+00:00): An <anbr>
Hallo!
Ich habe mal eine Frage an Dich zu diesem Änderungssatz. Den Aufzug am Bahnhof Karlshorst hatte ich glaube ich vor einigen Wochen ursprünglich angelegt. Er ist auch immer noch drin, aber seine Historie ist verschwunden, es sieht nun so aus, als sei der Punkt ursprünglich von Dir angelegt worden.

Ich habe damit kein Problem, das ist okay. Mich interessiert nur, wie es dazu kommen kann, dass zu einem Punkt seine Historie verschwindet? Ich war bisher immer davon ausgegangen, dass man vollständige Historien in OSM sieht - offenbar gibt es Konstellationen, in denen das nicht so ist.

Für eine kurze Info vielen Dank!
anbr (2015-10-15 14:32:38+00:00): Die Änderung diente der Erhöhung der Genauigkeit, für ein besseres Routing.
 
Deine Eintrag war geographisch am falschen Ort notiert, da der verwendete Node auch Teil der Treppe war.
Deshalb habe ich mir erlaubt die Fahrstuhl-Attribute auf einen neuen Node am richtigen Ort kopiert, und die Attribute am falschen Ort entfernt.
Die Treppe ist ja am richtigen Ort.

Siehe auch http://www.openstreetmap.org/node/2485267608/history
jacek_zwik (2015-10-23 13:06:18+00:00): Dawna linia kolejowa z Olesna do Praszki nie istnieje nawet fizycznie od kilku lat. W miejscu torów jest właśnie ścieżka rowerowa. Skasuj z łaski swojej tą linię kolejową. Wąskotorówki z Praszki do Wielunia również nie ma. tory nie istnieją.
Pozdrawiam
user_717069 (2015-10-26 15:28:47+00:00): Przecież całość jest oznaczona jako railway=abandoned, czyli tor zlikwidowany fizycznie. Jeśli dokładnie jej śladem zbudowano ścieżkę, to należy obie linie połączyć w jedną.
jacek_zwik (2015-10-27 06:34:14+00:00): abandoned - to coś porzucone lub linia kolejowa fizycznie istniejąca, ale porzucona, bo nie opłaca się jej remontować. W przeciwieństwie do disused - którą można przy pomocy niewielkich środków ponownie przywrócić do użytku. A w tym przypadku linii nie ma, została zdemontowana, nawieziony został szuter, ubity i poprowadzona ścieżka rowerowa. Przecież jak budynek zniknął to też nie dasz tagu abandoned, tylko po prostu nie zaznaczysz. Po co mnożyć byty na mapie.
user_717069 (2015-10-28 15:44:17+00:00): Proponuję nie wymyślać własnych definicji, tylko stosować te ogólnie przyjęte zamieszczone na http://wiki.openstreetmap.org/ railway=abandoned znaczy tor rozebrany, ślad po dawnym torowisku. Jeśli droga dla rowerów została poprowadzona dokładnie śladem toru, jak sama nazwa wskazuje można ją uznać za ślad dawnego torowiska i dlatego sugeruję połączenie obu linii (ewentualnie zmienić tag o krok dalej, czyli na railway=razed).
jacek_zwik (2015-10-29 06:11:32+00:00): Idąc dalej tym tokiem rozumowania Obwodnicę Kluczborka też należałoby oznakować tagiem railway=abandoned? Ponieważ jest dokładnie na dawnym torowisku (obwodnicy towarowej Kluczborka) Ślad dawnego torowiska widać doskonale biegnie od ronda na DK 11 pod linią kolejową do Wrocławia i łączy się z linią na Poznań na wysokości Gortatowa. Początek tej obwodnicy kolejowej jest w Kuniowie (zaznaczony jest kawałek toru) Była to linia dwutorowa zelektryfikowana. Budynek przy rondzie na DK 11/obwodnica to dawna nastawnia. On może być abandoned, bo ma zabite dechami okna. To co przerabiamy w takim razie Obwodnicę Kluczborka też. Bo jak trzymać się definicji, to należy się trzymać bez względu czy to ścieżka czy droga.
user_717069 (2015-11-06 11:05:42+00:00): Jak najbardziej.
Gino-52 (2015-10-07 07:14:37+00:00): Warum werden die Plattformknoten am Hauptbahnhof Hanau gelöscht?
soemisch (2015-10-07 09:20:51+00:00): Ich habe sie nicht gelöscht, sondern auf die stop_position, welche auf eine Straße verknüpft werden sollte, übertragen.

Es gibt eine Plattform (area) und eine Stopposition (Punkt). So habe ich Deinen Plattformknoten als Stopposition übernommen. 

Grüße, Lars
Gino-52 (2015-10-07 09:52:12+00:00): Jetzt ist aber auf der Stopposition, die sich ja auf der Straße befindet, eine Bank und eine Blindenführung. Das ist auch nicht OK. Gem. Public Transport v2 soll es für jede Haltestelle ein Stop und eine Platform geben.
Wenn man die Area-Platform in die Relaltion aufnimmt gibt es beim Routenanalyzer eine Fehlermeldung.
Mal sehen was das Forum dazu sagt.
malenki (2015-10-08 17:10:59+00:00): Hallo FD AS,

deine Bearbeitung habe ich gelöscht. In Einsiedel gibt es weder Autobahnen noch Botschaften.
Solltest du sinnvolle Bearbeitungen zu OSM beitragen wollen, ist das gern gesehen.
Rom1 (2015-10-08 09:44:21+00:00): Hi, why did you delete this node ? https://www.openstreetmap.org/node/3754918474/history Thanks
ma-rt-in (2015-10-08 09:46:45+00:00): Hey
The point was applied twice.
Rom1 (2015-10-08 09:50:32+00:00): Ok!
kayle (2015-10-07 09:19:17+00:00): Ahoj, prosím ťa to spresnenie je podľa bingu alebo čoho?
Lebo to tak úplne nesedí na stred podľa katastra. Je pravda, že ten tiež nie je vždy presný (aktuálny). Ale keď posúvam bing podľa katastra, tak ten potom v celku sedí s okrajimi v katastri. Viď http://freemap.kayle.sk/zarovnanie1.png a http://freemap.kayle.sk/zarovnanie2.png
roman7777 (2015-10-17 11:21:05+00:00): Ahoj,
robil som to podľa reálne najazdených dát z gpsiek, pokiaľ si odtiaľ a vieš si to s nejakým presnejším gpskom zmerať prípadne si si istá(ý), že to momentálny stav nezdopovedá skutočnosti uprav to.

Pekný deň, R.
kayle (2015-10-17 16:15:37+00:00): Ok, vďaka za info. Nebolo to nejak "extra" mimo (tých zhruba 3-5m nie je problém). Len ma zaujalo posunutie ulíc, keď som pozeral na Turčianske Teplice. Vidím že edituješ už dlho, takže som si nebol úplne istý čím to. Nový to sem tam zarovnajú na bing, ktorý skoro vždy treba korigovať. Pre istotu: http://wiki.freemap.sk/freemapKaPor tu je postup na plugin na kataster dáta. Tiež tam nie je všetko a aktuálne, ale ako ďalší zdroj pomôže. Veľa zdaru pri ďalšom mapovaní.
Pavel Yotov (2015-10-07 08:03:35+00:00): This street in Pleven is ул. Цар Борис III-ти
yvecai (2021-10-13 12:07:34+00:00): Hello,
I just noticed some white ski pistes on Opensnowmap(https://www.opensnowmap.org/mobile.html?zoom=3&lat=0&lon=0&layers=snowbase&marker=false#map=16/8.499/60.854&b=snowmap&m=false&h=false)
If you tag the resort as a type=multipolygon + piste:type=downhill, how am I suppose to make the difference with somebody mapping a ski piste as an area with type=multipolygon + piste:type=downhill ?

I guess you could use type=multipolygon + landuse=winter_sports like described in https://wiki.openstreetmap.org/wiki/Tag:landuse%3Dwinter_sports.

Regards,
Yves - opensnowmap
Allan Jensen (2021-10-15 12:20:10+00:00): This probably should be changed - but I don't have the time or energy to reeducate myself on this - I only remember that I wanted to be able to see the pistes actual footprint, not just a line for each piste. Feel free to change stuff around if you have the time.
Allan Jensen (2021-10-15 12:24:05+00:00): Btw, can't you just render areas below lines to have the pistes show up instead of white?
yvecai (2021-10-15 18:27:41+00:00): The thing is I render area on top of ways, because often, mappers map both (I see it like different model, or different level of detail). But in this case, they map each piste separately as an area.
trigpoint (2015-10-07 12:00:21+00:00): Hi
I don't think bridge 62 belongs in the name tag, it should be restricted to the bridge reference tag. The name should reflect what is visible on the ground and continue onto bridge 62 is very unhelpful to a rambler walking that way.
James Derrick (2015-10-07 13:50:05+00:00): Hi Trigpoint,

I'd not be offended if you removed the name tag for consistency, but thought the duplication with bridge_ref was useful in the absence other data.

Bridge numbers certainly rank below that of the name of the link carried by the span however this an agricultural accommodation bridge and I don't know an alternate name for the way.

The historic NPE sheets don't show any names, and the restoration society/ WRG/ canal press all call it 'Bridge 62':
http://www.ashbycanal.org.uk/ashby_canal_restoration.html

I'd suggest that as Ashby Canal bridges include the number on a large cast iron plate on the parapet, 'Bridge 62' would be of value to a walker. Indeed, CaRT advice is to use them if calling 999 after they passed geo data to the emergency services.

I unfortunately can't categorically evidence the latest 'ground truth' at completion, but drone pictures are published with what appear to be cast name plates on the bridge parapets.

BTW - all references I've seen to the waterway to the North are Gilwiskaw Brook, rather than the River Mease - any thoughts please? I added an alt_name to be cautious.

All the best,

James
SomeoneElse (2015-10-10 15:11:34+00:00): The most-used bridge tags in the UK are http://taginfo.openstreetmap.org.uk/search?q=bridge , so for bridge references bridge_ref wins by some margin currently (and it's already tagged as that).  I wouldn't duplicate it into the name tag as that's just duplicating information.  If a map style wants to show bridge ref it's easy for it do do so.
James Derrick (2015-10-15 10:56:27+00:00): Hi,

The ACC have turned up some additional information:
http://www.ashbycanal.org.uk/ashby_canal_restoration.html

This gives the historic name of 'Faulkes Bridge', which I've added.

All the best,

James
SomeoneElse (2015-10-16 10:27:32+00:00): Excellent, thanks.
Carlo Folini (2017-03-14 16:27:58+00:00): Ciao, ho trovato questo tag 'strano'. E' un errore?
Chrysopras (2015-10-07 09:10:30+00:00): ... und auch ein paar abwegige Tags beseitigt: leisure=common ist kein gutes Tag für simple innerstädtische Grünanlagen (siehe unser Wiki), ein simpler Parkplatz ist kein highway=rest_area :-)
Nakaner (2016-04-09 11:36:11+00:00): Relationen sind keine Kategorien. Routenrelationen führen von A nach B und sind keine reine Liste von Ways. https://wiki.openstreetmap.org/wiki/Relations/Relations_are_not_Categories

Bitte verwende lcn/rcn/ncn/icn=yes an den einzelnen Ways um ihre Beschilderung als Fahrradroute zu taggen, wenn sie nicht Teil einer ausgeschilderten Route von A nach B sind, z.B. https://www.openstreetmap.org/relation/3419553. Das genügt für eine Darstellung auf den einschlägigen Karten. Dass es sich um Radwege auf Fehmarn handelt, kann man mit räumlichen Abfrage ermitteln. Relationen sind dafür das falsche Mittel.

Beispiel Abfrage für Fehmarn, die die Sammelrelation ignoriert (deshalb so wenige Ergebnisse):
http://overpass-turbo.eu/s/fxL

Beispiel Abfrage für ein Gebiet nahe Hannover, das die Sammelrelation ignoriert (dort ist das Mapping deutlich besser als auf Fehmarn):
http://overpass-turbo.eu/s/fxK

Ich behalte mir vor, in Kürze diese Relation zu löschen und ihre Mitglieder mit lcn=yes zu taggen.
masju + Team (2016-04-09 12:08:40+00:00): Okay, danke für den Hinweis und die Berichtigung. Das war mir nicht bekannt. Ich hatte mich beim Anlegen des lcr hier orientiert:
http://www.openstreetmap.org/relation/3524160
Nakaner (2016-04-10 07:42:12+00:00): Danke für den Hinweis auf Ostfriesland. Die Relationen dort sind Überbleibsel eines undiskutierten Imports von Radrouten aus amtlichen Daten (mit allen Fehlern). Der Import wurde aber nur oberflächlich revertiert. http://forum.openstreetmap.org/viewtopic.php?id=25115 http://forum.openstreetmap.org/viewtopic.php?id=24876

Dann kann man dir keinen Vorwurf machen.
masju + Team (2016-04-11 06:42:32+00:00): Die Anlage als lcn-Relation hilft bei der Fehlersuche enorm (Lücken etc.), siehe http://ra.osmsurround.org/analyzeRelation?relationId=5563555, daher bitte noch nicht löschen.

Ich werde nach getaner Arbeit Deinem Vorschlag folgen (Danke dafür), die Relation in Kürze löschen und die einzelnen Mitglieder jeweils mit lcr=yes taggen.
rakesh_cept (2015-10-08 09:34:42+00:00): updated area of university hostel area,ahmedabad,gujarat
Chrysopras (2015-10-07 09:47:25+00:00): D.h. ich habe 3 Flächen mit landuse=residential, die durch keinerlei physische Hindernisse = andere landuses oder Baulücken getrennt waren, zu einer großen Fläche zusammengefasst, was keinerlei Informationsverlust bedeutet, aber das Bearbeiten der Straßen (die bisher mit den unnötigen landuse-Grenzen verknüpft waren) deutlich erleichtert.
Morten Lange (2018-02-28 22:02:42+00:00): Hei,  Det blir vel feil å merke disse stiene som highway=cycleway.  Da vil de fleste (folk og programmer) tolke dette som segregerte sykkeveier slik som vi har  langs deler av ring 3.
Se https://wiki.openstreetmap.org/wiki/Cycleway

"Note that ways, mostly not marked as cycleway by signs, that are not restricted to cyclists only can better be tagged as highway=path instead of highway=cycleway. "

For MTB merking brukes et litt annet sett.
Jeg tenker det riktige er higway=path, bicycle=yes   og eventuelt mtb:scale=0 
er det mest relevante for stiene i denne redigeringer fra 2 år siden. 

https://wiki.openstreetmap.org/wiki/No:Mountain_biking
Morten Lange (2018-02-28 22:05:19+00:00): Ser du har brukt higway=path og mtb:scale  på denne nylige endringen  :-) 
Way: 82781804
boneco (2015-10-13 14:08:34+00:00): Você chegou a olhar o contorno do cemitério e do Hiper Sales por imagem de satélite para alterar a área do mesmo?
Você apagou o estacionamento do Hiper Sales.
Você deve representar com a tag de prédio, a área do prédio e o resto, caso seja necessário, com "uso da terra" no iD e landeuse=comercial no JOSM.
GerdP (2015-11-13 15:22:02+00:00): please review:
you have added some tags with
higway=residential instead of highway=residential in this area.
I've changed them to highway=residential.
OK?
Kika Lino (2015-10-07 11:47:43+00:00): Übergang zwischen Fußweg und Straße hinzugefügt
BCNorwich (2015-11-24 08:07:02+00:00): Hi, you have to be very careful to check your edits. You broke Thickthorn roundabout by somehow disconnecting two nodes. I've fixed it. Regards
nizmo (2015-11-24 21:19:32+00:00): My understanding was that this have already been fixed by another user