piebro/osm-data huggingface dataset:
enedaniel (2023-01-31 10:53:32+00:00): Ich verstehe deine Argumente nicht. Ich sehe keinen "Topologiefehler"!
Überlappende Beschriftungen für Parks und Wälder sind eine gängige Praxis in OSM. Siehe Link:
https://www.openstreetmap.org/#map=16/52.5146/13.3611

https://www.openstreetmap.org/#map=15/51.5298/-0.1497

https://www.openstreetmap.org/#map=16/55.7175/37.5919

https://www.openstreetmap.org/#map=16/55.7175/37.5919

Dafür gibt es "1000" mehr Beispiele! Wie erhalte ich das Recht, daraus ein „Etikett“ [Landbedeckung]-->[Bäume] zu machen, das NICHT offiziell von der Gemeinde genehmigt ist? Außerdem zeigen alle OSM-Karten nicht (umrandet) die "Beschriftung" [Landbedeckung]-->[Bäume]. Die Kritik bleibt also, was soll man ändern? Bitte machen Sie diese Änderung rückgängig! OSM ist kein Projekt von „Einzelgängern“ und jeder macht das, was er für richtig hält, sondern die Arbeit der ganzen Community!
Wenn das "Label" [landcover]-->[trees] in OSM offiziell ist und auf Karten gerendert wird, können Sie es ändern. Aber vorher nicht! Nutzen Sie Ihre Zeit, um neue Dinge zu OSM hinzuzufügen, die es noch nicht gibt.

Ma ei saa sinu argumentidest aru. Ma ei näe "topoloogiavigu"!
Parkide ja metsade siltide kattumine on OSM-is tavaline praktika. Vaata linki:
https://www.openstreetmap.org/#map=16/52.5146/13.3611

https://www.openstreetmap.org/#map=15/51.5298/-0.1497

https://www.openstreetmap.org/#map=16/55.7175/37.5919

https://www.openstreetmap.org/#map=16/55.7175/37.5919

Näiteid on veel "1000"! Kuidas ma saan õiguse teha sellest "silt" [maakate]-->[puud], mis EI ole ametlikult omavalitsuse poolt kinnitatud? Lisaks ei ole kõigil OSM-i kaartidel näha (joonistatud) "silt" [maakate]-->[puud]. Nii et kriitika jääb, mida peaksite muutma? Palun võtke see muudatus tagasi! OSM ei ole "üksiklaste" projekt ja igaüks teeb seda, mida õigeks peab, vaid kogu kogukonna töö!
Kui "Silt" [landcover]-->[trees] on OSM-is ametlik ja renderdatud kaartidel, saate seda muuta. Aga mitte varem! Kasutage oma aega OSM-i uute asjade lisamiseks, mida veel pole.
Pikse (2023-02-01 11:07:08+00:00): I'm afraid my message didn't get across in Estonian. It seems in turn you now Google-translated your message from German to Estonian, which isn't helpful really. Regretfully I am not fluent enough in German either. So hopefully we can discuss this further in English.

I meant overlapping landuses aren't necessarily topologically incorrect but they easily may be. Based on such tagging there isn't a way for data reusers to know if the overlap is intentional or not. Such practice does exist, as also evidenced your examples. It may be even common in some areas, but this in itself doesn't make it less messy or into something that necessarily should be copied. Especially considering that alternative and existing landcover=* tag allows clear distinction to be made between landuse and landcover, i.e. here between park and its parts with different landcovers (trees, grass etc.)

In osm.org a park is denoted by light green colour per legend. In case of relation/1384127 from one your examples where light green patches are scattered more or less all over the mapped park area we might guess the extent of the park roughly. A tree-covered area (way/28065751) in Viljandi lossipark on the other hand covered the entire eastern part of the park and so based on such data it cannot be said even roughly where the park ends and the wood begins. As mentioned, this problem roots in the data, it is/was not a problem of with given renderer.

To my knowledge an "official" set of tags doesn't exist in OSM really. Most tags, including natural=wood, haven't been approved through some special procedure. Generally tags are just created and used as deemed necessary. The tag in question, landcover=trees, after all isn't some unknown tag that I just invented. Approval status is relevant to landcover proposal[1], but this has another more general subject concerning also how landuse=*, natural=* etc. should be used differently, it's not about the approval of landcover=* tag in particular. landcover=trees indeed isn't rendered in osm.org, but tags are not supposed to be chosen only based on if they are rendered in particular renderer, see [2].

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/landcover
[2] https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer
qqqqqqqqqqqqqqqqqqqq (2023-02-04 17:35:56+00:00): https://www.openstreetmap.org/changeset/108435775

I've already had such discussion with Pikse. 

My only conclusion from it is that he tags for the renderer while accusing others in tagging for the renderer.

>A tree-covered area (way/28065751) in Viljandi lossipark on the other hand covered the entire eastern part of the park and so based on such data it cannot be said even roughly where the park ends and the wood begins

>tags are not supposed to be chosen only based on if they are rendered in particular renderer, see [2].
Pikse (2023-02-04 18:24:47+00:00): In context this Viljandi example was to illustrate how the data issue became/becomes evident with osm.org styles. The issue itself is not specific to a renderer, as explained above.
qqqqqqqqqqqqqqqqqqqq (2023-02-04 19:32:40+00:00): I just don't see this as a good way for migration to a new tagging schema. Breaking something which works for many uses of OSM data to have a better landuse in the future. 

It's not wrong to add some new tags to better describe a feature, but I believe that it's wrong to break something working for an unconfirmed proposal. The sad reality natural=wood is NOT a landuse de facto (even more sadly landuse=forest isn't). Anyone consuming it as such without some additional logic will not get correct results. Today it means "There are some trees there".

landuse proposal needs a migration plan :/ . It's also not clear if landuse=forest will become an actual landuse or get deprecated.
Pikse (2023-02-05 13:49:59+00:00): I of course realize that landcover proposal altogether, concerning landuse=*, natural=* and all, isn't approved, and I'm not trying to enforce it nor "migrate to a new schema". I've only tried to clear up some sites where distinct landuse and landcover polygons overlap, using another existing tag (landcover=*) that isn't ambiguous. Such sites were more or less broken anyway as there was no way to interpret the data in a clear way.

In most cases landuse=forest and natural=wood don't overlap with other landuse or landcover areas. Then it's quite straightforward to think that both of these tags denote both landuse and landcover. This indeed also generally means that "there are some trees", but I'm not sure from where you get the idea that these other tags also denote only landcover, espesically in case of the first one that explicitly says "landuse" in its name.

You also claimed in our previous discussion that things are already fine and work but you didn't really explain in what way is that. There you instead referred to yet another renderer (osmlanduse.org) that is unable to intpret overlapping polygons in a meaningful way (it just discards either of the overlapping areas based an arbitrary critera).
qqqqqqqqqqqqqqqqqqqq (2023-02-05 14:10:07+00:00): >I'm not sure from where you get the idea that these other tags also denote only landcover

I get it from the situation we are in and it's also described in the wiki https://wiki.openstreetmap.org/wiki/Forest

We both would like them to denote something more, but the reality is different.

>There you instead referred to yet another renderer (osmlanduse.org) that is unable to intpret overlapping polygons in a meaningful way (it just discards either of the overlapping areas based an arbitrary critera).

I think it just didn't re-render at the time I've referenced it. 

You'd still need to be able to decide what to do with overlapping landuses if you want to consume such data. And in park you can just prioritize parks if you need it.

No matter how many times you say it, natural=wood is not a landuse. If you consume it as such, it's your problem. But it's strange that your want to break other clients which don't support unconfirmed proposal yet.
Pikse (2023-02-05 15:07:51+00:00): What exactly in "Forest" wiki page you refer to? This page as well as natural=wood wiki page cover aspects of both landcover and landuse. "There are some trees there" by itself doesn't really rule out landuse. See also "The current situation" section in landcover proposal where it's outlined that these older tags don't make distinction between landuse and landcover. So yes, why wouldn't I also say that both of these tags may and often do denote both landuse and landcover. While I don't see any evidence for your claim that natural=wood is for only landcover (or even evidence to claim that majority of users interpret it like that).

My idea was to avoid overlapping landuses, so that data reusers could know which of these overlapping landuses is actually landcover not landuse. If renderer wants do display both of these where they overlap then yes it of course needs to be decided how to do it correctly, but then at least it's indicated what the overlap is about and renderer can interpret it.

"Prioritize parks" is one way to approach overlap, but this is yet another arbitrary criteria to discard some of the data without really knowing if correct or incorrect data is kept.

We sort of go in circles. You raise points that I already answered in our previous discussion.
qqqqqqqqqqqqqqqqqqqq (2023-02-05 16:18:36+00:00): >So yes, why wouldn't I also say that both of these tags may and often do denote both landuse and landcover.

And often they do not.

>While I don't see any evidence for your claim that natural=wood is for only landcover (or even evidence to claim that majority of users interpret it like that).

Since we can't trust natural=wood to denote landuse, as described in the wiki and reality, the conclusion from it is that it correctly represents landcover and may or may not represent landuse. You for some reason decided that it has to represent landuse.

You kind of ignore the point where you break data consumers which don't care about the landcover yet.
Pikse (2023-02-06 13:57:00+00:00): No I don't decide that natural=wood has to represent landuse. Above I asserted that there's no way to know if in case of an overlap it represents landuse or only landcover. Landuses often overlap in OSM and often it means there's an obvious error, e.g. if forest overlaps water. If forest/wood overlaps park or cemetery or alike then it may be intentional and it may as well be yet another error so that actually only forest landuse is true.

My response to me "breaking" data consumers was broadly that it's hard to break something that generally seems broken already anyway. If anything I think I rather fixed it for consumers that can't handle overlapping landuses properly. I wouldn't say that a data consumer is broken if it simply doesn't use some of the available data.
enedaniel (2023-02-08 13:26:13+00:00): @Pikse
Warum diskutieren Sie, wenn Sie doch alles besser wissen? Interessanter Weise haben Sie sich selbst schon widersprochenen. (natural=wood steht für Landnutzung?... ja?, ... nein? ...vielleicht!)
Also, was soll das! OSM ist nicht der richtige Ort für Glaubenskriege! Bitte halten Sie sich an die Regeln und bearbeiten Sie erfassten Daten von anderen OSM-Mapper respektvoll! Da heißt: verändern Sie nur dann Daten, wenn alle etwas davon haben. Ich habe keine Zeit, um hier noch weiter zu labern. Es führt ja bei Ihnen auch nicht zum Ziel, da Sie ja nur  diskutieren, um zu  diskutieren! Bitte nutzen Sie doch Ihre Zeit sinnvoller, OSM braucht Ihre konstruktive Mitarbeit!!!

Mit freundlichen Grüßen
Daniel Schmitt

Why are you arguing when you know everything better? Interestingly, you've already contradicted yourself. (natural=wood stands for land use?...yes?,...no?...maybe!)
So what's the point? OSM is not the place for religious wars! Please stick to the rules and process data collected by other OSM mappers respectfully! This means: Only change data if everyone benefits from it. I don't have time to ramble on any further here. It doesn't get you where you want to go either, since you're only discussing in order to discuss! Please use your time more sensibly, OSM needs your constructive cooperation!!!

Best regards
Daniel Schmitt
Pikse (2023-02-08 14:56:46+00:00): As for the contradiction you try to attribute to me, I stand by what I said in first comment above: natural=wood is ambiguous when it comes to landuse/landcover. As referenced above, this is also discussed in OSM wiki pages, other users have observed the same.

To the best of my knowledge I haven't broken any rules. I do try to respect other people's work. I didn't delete your data or alike, I only tried to make it more clear using another existing tag, as I also explained beforehand in another changeset referenced in edit comment.

I also think that OSM needs constructive cooperation. Your kind of cooperation though doesn't seem constructive to me based on above discussion where you ignore pretty much all substantial content related comments, and where you basically just demand your discussion counterpart to go away and do something else.
qqqqqqqqqqqqqqqqqqqq (2023-02-11 17:58:17+00:00): Relevant information about this topic. Someone dropped a v2 landuse proposal.

It suggest double tagging for migration.
https://wiki.openstreetmap.org/wiki/Proposed_features/landcover_proposal_V2#Migration
Pikse (2023-02-13 14:17:34+00:00): In case of standalone (non-overlapping) landuse, sure, why not dual tag. However, I'm a bit reluctant to do so in case of an overlap where the goal is not only to have clearer tag name but also to resolve the landuse overlap. Dual-tagging in this case would more or less mean that later every invdividual overlap needs to be checked again.

I think the main purpose of dual-tagging is that then some mapped areas wouldn't be displayed just empty till consumer hasn't migrated to different tagging. In case of an overlap however there is another landuse anyway and this probably is still displayed.
Shaun das Schaf (2023-01-23 17:50:48+00:00): Hallo Ines vom Naturpark Frankenwald, willkommen bei OSM!

Ist die Brücke in Echt wirklich so komisch um die Ecke:
https://www.openstreetmap.org/way/1134497088
https://www.openstreetmap.org/way/1134497089 ?

Ich nehme an, dass der westliche Teil ( https://www.openstreetmap.org/way/1134497088 ) keine Brücke mehr ist, oder? Dann dort bitte die Eigenschaften "bridge=yes" und "layer=1" wieder entfernen.

Danke und viele Grüße
Shaun das Schaf
DD1GJ (2023-01-23 23:01:18+00:00): Hallo Ines,

wichtig wäre noch die Umletung des Dreiherren-Weg RT 32. Momentan führt die Relation noch uber den gesperrten Weg an der Schnappenmühle vorbei: https://www.openstreetmap.org/relation/83956#map=18/50.37396/11.51982

@Shaun das Schaf: Die Ecke war schon zuvor drin. Die "Brücke" dürfte ein Fehler sein.
bxl-forever (2023-01-23 15:09:33+00:00): Hello,

Are those massive data imports allowed by Tesla?  Are they documented somewhere on our wiki?

According to their terms of service, information from their website may not be distributed (and this also restricts importing to OSM): https://www.tesla.com/legal/additional-resources#intellectual-property

You work for them, do you?  If all this data was obtained from their website, did you get permission to use it?

That being said, adding addr:* tags on charging stations is a bit weird.  Especially when street names do not match.
e.g. in Brussels "Boulevard Lambermont" is only the French version of the name.
e.g in Arlon, "Parc d'activitee Economique Weyler II" looks strange and does not match OSM data
e.g. in Hasselt, "Kempische Steenweg" is quite far from the POI
e.g. in Liège, the "addr" tag copying the full address should be removed.
…

Thanks in advance.
cae42 (2023-01-23 15:26:38+00:00): Bonjour
Je n'ai fait que corriger quelques données. J'ai peut-être ajouté un noeud de mémoire.
Du coup, votre question serait plus à remonter à tous ceux ayant saisis les entités initialement... Moi je n'ai fait que copmpléter le plus souvent l'accessibilité (access=yes ou access=customers) afin de préciser aux personnes qui consultent les données si les bornes sont accessibles à tout type de VE.
D'autre part, mes modifications attraits à la géolocalisation Administrative (Adr:country, adr:city, ....)
bien à vous
cae42 (2023-01-23 15:28:02+00:00): Etant fançais, je ne suis certainement pas assez connaisseur des rouages linguistiques de votre pays...
eggie (2023-01-23 14:41:59+00:00): Svp geen adresnodes van het Kadaster verwijderen.
Adressen worden dan onvindbaar.
Adresnr 320  hersteld..
Bedrijven kunnen beter op de adresnodes worden bijgetagd conform afspraken in OSM Nederland.
Doe je dat zelf?
Het hoeft niet direct. 

MVG
eggie
eggie (2023-01-23 14:38:17+00:00): Beste ErEr   Probeer svp op de BAG adresnode  bij te taggen. 
Dan is adresnode gekoppeld met het bedrijf.
MVG
eggie
Claudio Tam (2023-06-19 21:15:48+00:00): Way: 1134499829
Esiste realmente? Formale o informale? Visibile o invisibile? Se esiste, rappresenta un ottimo sentiero per andare da valle dell'inferno a casa capo di porco.
Strubbl (2023-01-26 18:13:06+00:00): Danke, das hat doch gut funktioniert mit dem wikimedia_commons-Tag. Der wikimedia_commons-Tag funktioniert so super und man gelangt mit einem Klick direkt zu deinem Bild auf Commons.
Ich habe jetzt nur noch den image-Tag entfernt, damit das Bild nicht doppelt an dem Objekt kartiert ist.
Interteutones (2023-01-23 22:40:50+00:00): Hinsichtlich Klärung "abgebaute Bahnlinie" kann ich dir nach Rückinfo folgendes vorschlagen: Ich melde mal deine hier eingezeichnete aber abgebaute Bahnlinie ins ehem. Werk Tanne und wir warten ab was passiert. Das sollte in deinem Interesse sein und den Sachverhalt final klären. Einverstanden ?
Langlaeufer (2023-01-24 05:23:37+00:00): Tue was du nicht lassen kannst.
Die Problematik wird aber hier schon diskutiert!
https://community.openstreetmap.org/t/ehemalige-gleisverlaufe-im-werk-tanne-wurden-geloscht/8106
Herr Ramm hat sich übrigens auch schon geäußert.
emersonveenstra (2023-01-23 14:37:53+00:00): Hi,

Thanks for the contributions! Please note that road names must not be abbreviated, can you please change the road name to "Lister Court Northeast"? Thanks!
mcliquid (2023-01-23 14:53:48+00:00): Herzlich Willkommen bei OpenStreetMap!
emersonveenstra (2023-01-23 14:36:59+00:00): Hi,

Thanks for the contributions! As a note, you can mark the gate with a barrier=gate tag on the point where the gate is, that way it's more clear there's a gate.
jrschuur (2023-01-23 14:54:01+00:00): New at editing here, but how do you make that change?  When I try to edit the point(s), I'm not seeing how to add a barrier or edit it.
emersonveenstra (2023-01-23 15:02:59+00:00): So if you click on the point, under the Feature Type dropdown it says "point", you can click on that and search for Gate, it will prefill the correct tag for a gate, and then you can add more detail if you know it.
jrschuur (2023-01-23 15:09:00+00:00): Perfect, thanks.  Think I was able to figure it out
emersonveenstra (2023-01-23 15:13:33+00:00): Looks like you did, thanks!
eggie (2023-01-23 14:34:11+00:00): Beste ErEr

Wanneer een bedrijf sluit graag de adresnode intact laten en alleen de bedrijfdinfo verwijderen.
Dat is belangrijke info op de kaart. 
Er wordt gescreend in het begin op beginnersfouten.. en uiteraard om te helpen.

MVG
eggie
eggie (2023-01-23 14:36:48+00:00): Jagerlaan 1 hersteld.
Mocht dat adres niet meer bestaan laat het dan even weten.
MVG
eggie
eggie (2023-01-23 14:55:50+00:00): Zou 	website=https://www.randstad.nl/ nog correct zijn?
https://overpass-api.de/achavi/?changeset=131608764

Tip .. Kies voor alle tags zichtbaar dan zie je wat er nog meer in het riedeltje staat. 
Groet
eggie
ErEr99 (2023-01-23 15:36:01+00:00): Ah logisch inderdaad, zal de node laten staan alleen de naam verwijderen als die niet meer relevant is. Ook detailinfo zoals website zal ik beter checken
eggie (2023-01-23 16:19:58+00:00): .... en prima natuurlijk om het winkelbestand weer actueel te krijgen.
Mapse..
eggie
NorthCrab (2023-01-24 04:33:23+00:00): Witaj na OpenStreetMap!

Nie używaj nazw opisowych, zawsze istnieje jakiś tag który poprawnie oznaczy obiekt. Używanie wyłącznie nazw jest często nie wspierane przez aplikacje i ciężko z takimi danymi się współpracuje.

Transformator w budynku oznaczamy: budynek typu service, node w środku zgodnie z dokumentacją: https://wiki.openstreetmap.org/wiki/Tag%3Apower%3Dtransformer.

Pozdrawiam!
_torsten_ (2023-01-23 18:04:39+00:00): Hallo OMME-OSM, wir hatten neulich erst die Diskussion in einem CS zu den Hausgärten. Als Ergebnis haben wir festgestellt, dass wir das großflächige Darstellen von Hausgärten nicht wollen. Das Wohngebiet (landuse=residential) stellt ja alles (auch Hausgärten) dar. Wenn du die Hausgärten wirklich darstellen willst, dann bitte viel kleinteiliger in den Bereich wo sie auch wirklich sind. Aber dann muss du das Mirkomapping auch pflegen.
Herzliche Grüße, Torsten.

https://www.openstreetmap.org/changeset/120829661
literan (2024-03-11 14:18:21+00:00): какую-то фигню вы внесли: https://www.openstreetmap.org/note/4134742
mcliquid (2023-01-23 15:00:04+00:00): Herzlich Willkommen bei OpenStreetMap!
Diógenes de Sinope (2023-01-23 21:20:45+00:00): Olá FDC KIKUXI SHOPPING,

algumas das etiquetas que acrescentou ao ponto de interesse que estabeleceu neste conjunto de alterações sugere que é em referência a um estabelecimento retalhista, no entanto, não a designou realmente como uma 'loja'. a etiqueta que a deve utilizar para representar isto é 'shop=surveillance' [ https://wiki.openstreetmap.org/wiki/Pt:Key:shop ]

as etiquetas actuais do nó sugerem uma variedade de coisas, algumas das quais são mutuamente exclusivas, as etiquetas descrevem sobretudo que o nó representa uma câmara de segurança mas não uma loja onde vende-se câmaras de segurança
AkuAnakTimur (2023-01-23 14:31:12+00:00): Remote mappers near or far, please go further fixing the mess. I believe Strava heatmap + Esri is probably close to 99% accuracy
AkuAnakTimur (2023-01-23 14:44:44+00:00): Nightmare continues... please adjust existing highways with respect to a more accurate imagery...
Leo Slager (2023-01-24 11:51:36+00:00): Je hebt de perrons in Zwolle toegevoegd aan de routerelaties van IC23 en serie 3600.
Daarbij zijn de perrons niet op de juiste plaats in de routerelatie geplaatst maar achter in de route toegevoegd. dat leidt dan tot foutmeldingen omdat de perrons op de juiste plaats in de route moeten worden toegevoegd.
Ik heb de fouten hersteld.
Fizzie-DWG (2023-01-23 22:52:52+00:00): Reverted by DWG due to vandalism: changeset/131627514
Fizzie-DWG (2023-01-23 22:52:42+00:00): Reverted by DWG due to vandalism: changeset/131627514
eggie (2023-01-23 16:44:09+00:00): Dag Jordi.. Je vraagt feedback   Staat dat gebouwtje nog wel op het Dorpsplein? Zo te zien niet meer. 
Zoniet dan kan het weg.  

MVG
eggie
JordidB (2023-01-23 17:31:01+00:00): Nee, dat staat er niet meer, had er overheen gekeken. Ik haal het weg.
MVG JordidB
eggie (2023-01-23 17:44:02+00:00): Top!
marczoutendijk (2023-07-27 18:31:43+00:00): What is the meaning of leisure=*
What is the meaning of landuse=*
scarapella (2023-05-22 12:31:43+00:00): hi t2editme,

I think in this edit you have the inner and outer polygons roles reversed.  You can use some of the validation tools such as OSMI to check your polygons

https://tools.geofabrik.de/osmi/?view=areas&lon=-69.63657&lat=43.83386&zoom=13&baselayer=Geofabrik%20Standard&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

scarapella
habi (2023-01-23 15:05:20+00:00): Da warst du quasi etwas schneller als ich.
Ich war grad (virtuell) in der Gegend und habe die Öffnungszeiten nochmals angepasst: https://www.openstreetmap.org/changeset/131611654
mcliquid (2023-01-23 15:09:01+00:00): Danke, die Leerzeichen hab ich übersehen :)