piebro/osm-data huggingface dataset:
chlenix (2021-07-25 18:52:35+00:00): завод то банкрот, но территория остается landuse=industrial
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/108433090
eggie (2021-07-22 14:38:52+00:00): Je vraagt feedback... 
Oke.. Lijkt me correct.  oneway kon dus niet hier.
living_street alleen als er een bord woonerf staat. Meestal wordt service gebruikt op 'resorts'

MVG
eggie
Nate Wessel (2021-07-22 16:32:24+00:00): I reverted this changeset because it broke the city's boundary relation.
opendcc (2021-07-23 05:45:42+00:00): Hallo,

OpenStreetmap ist eine Gemeinschaftarbeit und (nicht nur) deswegen ist es wünschenswert, die durchgeführten Änderungen kurz im Changeset-Kommentar zu beschreiben: hier z.B. Parkplatz beim Wertstoffhof ergänzt. Danke.
PT-53 (2021-07-31 07:12:56+00:00): Hallo savage2020,
Du hast diesen "Pumptrack"
https://www.openstreetmap.org/way/966490972/history
neu eingezeichnet. Dieser überschnedet sich teilweise selbser, was nicht sein sollte. Im OSM-Inspector werden deshalb auch 4 entspr. Stellen angezeigt:
http://tools.geofabrik.de/osmi/?view=geometry&lon=10.27176&lat=47.52164&zoom=18&opacity=0.34&overlays=self_intersection_ways,self_intersection_points

Wenn der Weg stellenweise über die gleiche Route hin und zurück führt, muß der Weg dort aufgetrennt werden und es darf dort nur ein Wegabschnitt eingezeichnet werden.

Schaust Du Dir das nochmal an?

Für Fragen / Anmerkungen / Rückmeldungen bitte diesen Änderungssatz aufrufen und in das leere Feld unterhalb Diskussion als neuen Kommentar eintragen.

Fragende Grüße
PT-53 (2021-08-15 07:35:29+00:00): Hallo savage2020, 
bitte schaue Dir das nochmal an.
Grüße
PT-53 (2021-08-22 09:14:22+00:00): Pumptrack überarbeitet.
Danke
Denis_Helfer (2021-07-22 19:27:29+00:00): ajout du way https://www.openstreetmap.org/way/168605760 pour assurer la continuité de la clé ref:FR:SNCF_Reseau
Nakaner (2021-07-23 13:41:47+00:00): Hi,

please avoid to edit features on different continents within the same changeset because this leads to large bounding boxes and changeset which are difficult to review.

Best regards

Michael
Friendly_Ghost (2021-07-23 16:18:07+00:00): Hi Michael,

These changesets need to be done globally to avoid fixing the same thing six or more times. As someone else I spoke to has pointed out: "Honestly it needed doing." 

If it helps you, I will make a separate changeset for the German-speaking countries next time. 

Best regards,

Casper
Lee Carré (2021-07-28 20:44:22+00:00): @Nakaner

He's been told, plenty, before. He won't engage (in good-faith or with intellectual-honesty).

See the (lengthy) discussion in http://www.openstreetmap.org/changeset/108548780

Trying to reason with him is futile.
Friendly_Ghost (2021-07-29 09:58:08+00:00): Hey Lee. If you don't have anything productive to add, then I suggest that you map something instead.
Lee Carré (2021-07-30 15:30:41+00:00): More projection & evasion. Difficult to take you at all seriously when you don't follow the same expectations you have of others.

You won't engage with community, so you're hardly one to judge the merits of how others do so. Nor do you get to dictate what's (socially) productive.

Since you seem oblivious; I, having consideration for others, was attempting to save Nakaner the time & trouble of a fruitless argument with you, given your attitude elsewhere.
Just because you don't see it as productive, doesn't mean that it isn't.
The very nature of changeset discussions are about doing something other than changing the map. They're at a meta-level. This suggests that you don't understand that which isn't absolute & tangible. Or, possibly, that you're a narcissist (especially given some other factors).

As I said; I do surveying (which depends on weather & other factors), so have added / updated plenty (without pissing off other people).
s/color/colour/ isn't mapping anything. Remind me how many hours you spent on that; to bark at me about having nothing better to do, yet to complain when people hold little more than contempt for your misconduct? That's an impressive amount of denial.

What happened to your interest in & enthusiasm for, water features? You'd rather spend longer then I dismissing & otherwise bickering with several people trying to give you constructive advice.

In my experience, petty retorts mean that you have no rational counter-argument, yet are still butthurt. Grow up. I've met children (of <10 years age) with more maturity.

Get off your butt and go outside. Survey your university campus (since you can access areas which visitors can't).

Again & still with the presuppositions, I see.
ZeLonewolf (2021-07-30 15:33:59+00:00): @Lee Carré: please stop with the insulting language.  It is not helpful and does nothing to advance the discussion.
Lee Carré (2021-07-30 16:13:31+00:00): @ZeLonewolf

Seems that you're missing the relevant context. See Friendly_Ghost's recent changesets with more than a couple comments (I can cite the IDs if necessary; one is already mentioned in a previous comment). He doesn't engage when people try to reason with him, or with the community, doesn't respond or act in good faith, and so on. Thus, in this instance, reason doesn't advance anything either.
If aware of context, then you'd know that he's attempting to insult (or provoke) me by attempting to throw my own words back at me when it makes for a convenient quip, instead of confronting the relevant subject directly.

But, hey, if you wanna flog that particular dead horse, be my guest.

Personally I'd rather engage such people, rather than (as seems common on OSM) blocking them.

I don't really care for tone-policing or other (soft-)censorship, either. That not only doesn't help, but harms.
ZeLonewolf (2021-07-30 16:25:44+00:00): @Lee Carré I am well aware of the various discussions (many people at this point are subscribed to the changesets given the recent community interest in @Friendly_Ghost's large changesets), and I am following them with great interest.  I realize that you are passionate about this topic, but personal attacks are simply unacceptable and I ask you to stop.
Lee Carré (2021-07-30 20:52:50+00:00): “personal attacks are simply unacceptable”
I'll cite the words of someone wiser (and with much more net-cred) on the subject: http://linuxmafia.com/~rick/faq/crybaby.html#adhominem

I trust (read: expect to see) that you'll be applying the same to others, if this is (indeed) a matter of principle and not simply disliking that I'm direct about it (or me, for whatever reason), and that I'm willing to say what myself and others are thinking.

Unless, of course, to disagree is also a ‘personal attack’ (since you're repeating a request for something which didn't recur). I'd rather know sooner than later if OSM has succumb to SJWs.

“I realize that you are passionate about this topic”
While I won't deny passion, it's not about the topic (as you characterise it).

Don't presume to know my motivations (else you would've asked me); that's patronising. While I recognise your greater experience within OSM, don't assume that it extends to other contexts.
You're also assuming (by juxtaposing them) that any passion I have is why I question the personal credentials which were implicitly cited (since reason was long since abandoned) as justification for the changesets in question.

This is off-topic, now, so if you wish to continue I invite you to reply by PM. I'll say no more here.
user_18023081 (2025-12-01 12:51:12+00:00): OK.
user_18023081 (2025-12-01 12:51:33+00:00): Why are people this butthurt over a big bbox spanning their country??
Pikse (2021-08-14 06:44:37+00:00): Ma ennist vahetasin way/78784263 juures sildi natural=wood sildi landcover=trees vastu selleks, et maakasutust ja maakatet selgemini eristada ning et kahe maakasutuse (park + mets) kattumine oleks vähem segadust tekitav. Vt ka https://www.openstreetmap.org/changeset/105051705
qqqqqqqqqqqqqqqqqqqq (2021-08-14 08:57:42+00:00): Which maps/applications support landcover=trees?
qqqqqqqqqqqqqqqqqqqq (2021-08-14 10:00:25+00:00): I don't see a contradiction between a park and natural=wood. While your approach uses a tag which is not yet supported by most data consumers.
Pikse (2021-08-16 11:28:26+00:00): The distinction between landuse and landcover is explained more thoroughly at [1]. In some other places, like in a forest that doesn't have overlapping polygons, this distinction might not matter a lot.

Here within park however there can be various landcovers (trees, grass, paved area etc.) and overlapping natural=wood polygon is at best ambigous: it may denote landcover and it may as well be a topologically incorrect overlap of different landuses (park or wood/forest). Hence data can't be consumed accurately, and also on openstreemap.org map we don't really know, based on legend, that park extends to wood area. Also it appears to be random that on this map wood is currently displayed at the top of park, and consumers may as well display it the other way around as tagging leaves it unclear why polygons overlap in the first place.

I don't know if any consumer uses landcover=trees, but compared to natural=wood this tag at least allows clear representation of nature in given place. So that if anyone wants create map where landuse/landcover is clear then they can use this tag. Alternatively, to avoid confusion, it would probably better not to map different landcovers within park at all.

[1] https://wiki.openstreetmap.org/wiki/Proposed_features/landcover
qqqqqqqqqqqqqqqqqqqq (2021-08-16 17:49:08+00:00): Natural=wood is not a landuse tag. It may be used as such and it may be not. I didn't tag it as landuse=forest.

Could you give an example of a client consuming this data incorrectly? It IS a park and DOES have a forest. This is why I think the data is correct and it's ok for polygons to overlap. Here is an example of a client fully understanding the landuse. https://osmlanduse.org/#15.741974951963615/24.82777/59.46188/0/

While landcover may seem to offer better distinction, it is just not supported. And when having a choice between using a supported tag and an unsupported one, the choice should be clear.

Deciding if the forest or the park is more important to be on top is entirely up to the client and landcover would not fix that unless you are saying that we should rely on that it is unsupported and not drawn. BTW, it's not random, smaller areas get drawn on top of bigger.

Landcovers should be mapped in parks, amenity=park does NOT assume ANY vegetation, though you can probably expect grass by default.

Landcover may be a better tag in future, when the proposal is accepted and clients start to support it, but currently I don't see anything wrong with natural=wood.
Pikse (2021-08-16 21:00:52+00:00): Per wiki documentation, the distinction between natural=wood and landuse=forest, if there is any clear distinction at all, is not the landuse/landcover distinction. As said, in other places where given distinction doesn't matter a lot, both tags can be thought as representing both landuse and landcover.

In last comment I already brought the example of openstreetmap.org map that doesn't consume this data correctly: per its legend we can't really know that wooded area is part of park. I agree it should be up client to decide what they display, i.e. either landuse or landcover or both, but in given place it cannot be decided really as current tagging is ambigous and simply insufficient.

Generally, in relation to "tagging for the renderer" principle, tags shouldn't be chosen mainly based on which consumers use it, and hence the question of a tag being "supported" seems a bit irrelevant.

More importantly, I'd say, we should check if the tag is in common usage, what are the alternatives and is the tag useful. Tag in question, landcover=trees, has been used relatively a lot, meaning it might be already worthwhile for some client to use it, and more importantly there doesn't seem to be other common tags that allow clear representation of nature in places where clearly distinct landuse and landcover overlap.

I'm not sure what you mean by osmlanduse.org "fully understanding the landuse". As far as I can see data that it has derived from OSM data just ignores wooded area that overlaps park.

I don't necessarily oppose landcover being mapped in parks. I'm just saying that if its mappend then it should be done in a nonambiguous  way.
qqqqqqqqqqqqqqqqqqqq (2021-08-29 10:13:56+00:00): >In last comment I already brought the example of openstreetmap.org map that doesn't consume this data correctly: per its legend we can't really know that wooded area is part of park. 

This is your personal opinion, should clients start to support landcover we will probably see the same picture.

> As far as I can see data that it has derived from OSM data just ignores wooded area that overlaps park.

Exactly, this prooves landuse data can be consumed correctly with natural=wood tagging.
Pikse (2021-08-29 15:47:22+00:00): Did you check the legend on openstreetmap.org? Per this legend park has two parts, one next to Pirita tee and another part separated by forest area, while per actual OSM data the forest area in between is also part of park. This is what it explicitly displays, and so I don't think that it has got anything to do with my "personal opinion".

Another matter is how to fix this on client's side or what kind of support for landcover=trees could be added. Client indeed may mess it up further by considering landcover tag equivalent to other forest/wood tags, but then this would be client's problem, not an issue with ambigous tagging.

Wooded area being ignored proves that it's consumed correctly? How? It simply doesn't allow areas to overlap and substantially it's unclear why one area should take precedence over another. You pointed out that on openstreetmap.org larger area is displayed on top. If on osmlanduse.org similarly larger area takes precedence, then in essence it's random what data gets lost depening on if larger wood area happens to overlap smaller park or the other way around.
qqqqqqqqqqqqqqqqqqqq (2021-08-29 17:00:02+00:00): Things on maps overlap, you have to accept it. Like a grass on top of landuse=commercial will be green. It is still the same landuse, grass does not change that. I read map differently and for me it's clear that park includes the forest even if I don't see exact borders of the park in some places.

You have claimed that landuse cannot be consumed correctly  and as I've demonstrated it can be.

So for me the issue is about more popular tag and a less popular unsupported one.
Pikse (2021-08-30 12:29:22+00:00): Well, you may ignore ambigous tagging and landuse/landcover distinction in general, but this in itself does not make it go away. Also, as far as I can see you only demonstrated that client software can work around conflicting source data by ditching what is larger/smaller, older/newer (or some other arbitrary criteria). This does not demonstrate that data is consumed correctly or interpreted the way mapper meant it.

I do acknowledge that generally little effort is put into correct topology on OSM, and in that regard its data should be taken with a grain of salt. It's probably easier to ignore overlapping landuses if there is a small landuse patch within different and considerably larger landuse, but nonetheless topologically it would be incorrect. Here one the other hand it's quite hard to ignore the overlap as the question is whether over half of the park area actually isn't park. 

You say to you it's clear that park includes forest, but then you probably rely on local knowledge or something else, and not on given OSM data. After all, it is possible, at least in some other place, that similar forest area lies next to a park, isn't part of a park, and is rendered the same. Or, if in some other place park and forest overlap only partially, then we again would be able to tell it areas are just incorrectly mapped, or if tagging should be interpreted differently within overlapping/non-overlapping subareas.
qqqqqqqqqqqqqqqqqqqq (2021-08-30 15:26:06+00:00): There is no ambiguity and you failed to demonstrate it. Only argumented thing is that it's hard to see park borders to which I again made an example that it happens on osm and there is no solution for a single raster renderer which wants to include overlapping information. 

I don't see any point in continuing this argument as you ignore what I say. You may appeal to a broader public on osm help or forum and that may change my mind.
Pikse (2021-08-31 15:20:21+00:00): I also see little point in continuing this here, but for the record, the ambiguity which you claim I "failed to demonstrate", is very simple: natural=wood is generally used also for landuse, and hence here data users has no way to tell if here it should be interpreted differently (as landcover), or if areas just incorrectly overlap (also a common scenario).

I'm pretty sure I've replied to all your comments, even if it isn't evident in what way some of your remarks are relevant to given issue. While you in turn seem to overlook altogether the landuse/landcover distinction, general topology concerns and multiple examples of similar scenarios that I brought to illustrate the issue better. You only claim that to you data is clear, without even caring to explain why it should be clear to other users beside you.

The general issue of landuse/landcover mapping being unclear using common tags was outlined long ago by other users anyway in landcover proposal that I referenced above. This here is just a case where this issue is more evident.

Displaying overlapping data in a clear way is not necessarily easy indeed, but it isn't impossible either in most cases. In such situations reasonable solution often is not to overcomplicate things and hence display only a selection of available data.

Your change seem to be driven mostly by the discouraged "tagging for the renderer" principle[1], i.e. you choose tags only based on if data gets rendered on openstreetmap.org. If in essence you don't care which tag is used, then I think you also don't really have a reason to impede other users from trying to choose tags in a way that the data itself would be accurate and more usable.

[1] https://wiki.openstreetmap.org/wiki/Tagging_for_the_renderer
pio2_122 (2021-07-22 16:11:06+00:00): Drobna uwaga odnośnie tagu public_transport:version: właściwa wartość to 1, a nie 2, ponieważ te trasy są w tzw. starym schemacie tagowania. Oba schematy są używane na równi, więc nie ma sensu wywracać do góry nogami istniejących tras. Wystarczy tylko poprawić wspomnianą wartość :)
Lee Carré (2021-07-22 18:40:23+00:00): Rather an enormous changeset area, but fair enough.

Nation ID != language ID 🙂.
user_10714872 (2021-07-23 01:28:35+00:00): 666
JuaFritz (2021-07-24 16:05:53+00:00): Ciao! In realtà in questo punto non c'è un posto auto riservato. Nel parcheggio c'è uno stallo per disabili, un po' più verso ovest, ed è già stato mappato. Tra l'altro questa area di parcheggio se non sbaglio è privata, dei condomini. Comunque gran bel lavoro quello che stai/state facendo in tutta la provincia.
eggie (2021-07-22 15:38:38+00:00): Welkom bij OpenStreetMap. Ik heb een uitgebreid welkomstbericht met wat handige tips en links gestuurd als privebericht. 
Feedback:  
Zo te zien heb je het voormalige trace van de trambaan weggehaald. 
Met 'rail' is wat bijzonders icm met kaarten. Vaak laten we die info staan. Met als tag abandoned, razed of disused.. Ligt er een beetje aan wat er nog te zien is.
Verder is alles lastig in het begin. Zi kun je fietsrouets eigenlijk niet bewerken met een simpele editot als iD. De routevolgorde gaat dan verloren.
Dat kun je uiteraard niet weten.
Het kan wel met de betere editor JOSM
editor josm stap voor stap 

https://forum.openstreetmap.org/viewtopic.php?id=53710        

 Ik kijk even of het simpel te herstellen is hier.

MVG, 

Eggie 

Namens de OSM Community
eggie (2021-07-22 15:47:45+00:00): De wandel- en  fietsroute heb ik hersteld en de brug iets meer uitgelijnd  net als het water.

MVG
eggie
eggie (2021-07-22 15:55:51+00:00): Dat stukje wat je had weggehaald staat er nu weer. 'k Denk dat het beter op railway=razed kan.
https://wiki.openstreetmap.org/wiki/Demolished_Railway
Up to you
gr eggie
Pyronick (2021-07-24 11:08:49+00:00): De wandel- en fietsroute heb ik hersteld en de brug iets meer uitgelijnd net als het water.

MVG
eggie"

Dank voor de feedback! Nog veel te leren hier! :)
yrtimiD (2021-08-06 18:07:53+00:00): Hello, FYI, bing images are extremely obsolete, please use them only if you have local knowledge of the area and sure that imagery is still fine.
Specifically here, this roundabout doesn't exists for several months already, so your added crosswalks are not relevant anymore and should be reverted :(
Car162 (2021-09-08 14:24:25+00:00): Okay
gscholz (2021-08-15 07:16:38+00:00): Hi Annie_Z_FS,
your buildings are of a very low quality. They do not have a rectangular shape, are mostly to big, stick together even they are clearly separated, have duplicate nodes etc.

http://tools.geofabrik.de/osmi/?view=geometry&lon=-91.56024&lat=16.00533&zoom=12&overlays=self_intersection_ways,self_intersection_points,single_node_in_way,duplicate_node_in_way


Please urgently improve your mapping style.
Kind Regards
Guido
gscholz (2021-08-01 07:16:15+00:00): Hi Annie_Z_FS,
your buildings are of a very low quality. They do not have a rectangular shape, are mostly to big, stick together even they are clearly separated, hzave duplicate nodes etc. 

http://tools.geofabrik.de/osmi/?view=geometry&lon=-91.57947&lat=15.54063&zoom=10&overlays=self_intersection_ways,self_intersection_points,single_node_in_way,duplicate_node_in_way

Please urgently improve your mapping style.
Kind Regards
Guido
luisforte (2021-07-22 19:53:10+00:00): Olá Rui,
Considera pf o comentário do utuilzador mueschel numa tua  edição anterior; ele não está a embirrar contigo ou com o facto das tags estarem em português, mas só a lembrar que tal não tem qualquer utilidade.
Qualquer mapa temático, como https://openrecyclemap.org/map, não apresenta resultados se procurares reciclagem de vidro, onde tens [recycling:vidro=yes].
Na prática essa informação é informação inútil que fica em osm sem qualquer uso.
Luis
archpdx (2021-07-22 17:59:02+00:00): Hi Crestmont,

I see that you've removed some private roads in both this changeset and some of your past changesets. It generally is better practice to add the 'access=private' tag to these roads instead of removing them.

-archpdx
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/108439643
Mateusz Konieczny (2025-05-14 14:26:30+00:00): Hello! https://www.openstreetmap.org/node/6022575104/history has guest_house = hotel that was added in this edit
Would it be hotel? ( tourism=hotel - https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dhotel )
Guest house? ( tourism=guest_house - https://wiki.openstreetmap.org/wiki/Tag:tourism%3Dguest_house )

Something else?
maraf24 (2021-07-31 12:07:39+00:00): Dlaczego ewidentny park oznaczasz jako landuse=grass?
felipeeugenio (2021-07-22 18:36:09+00:00): Hola.
para las calles de servicio siempre es bueno usar el tag access=
para este caso access=customers quizas es lo mejor.
saludos
            ---
            
            Published using OSMCha: https://osmcha.org/changesets/108440417
bhietsch (2021-07-26 03:20:25+00:00): Please do not add landcover tags to protected areas! It is a gross oversimplification to say that all of the area within these boundaries is either forest or meadows. Unless you have any objections, I am going to revert your recent changesets that added landcover tags.
BiscuitsandTea (2021-08-04 21:05:57+00:00): Fair enough.
BiscuitsandTea (2021-08-04 21:15:39+00:00): Although, did you remove landscape features that I took time to draw in? I've been to many WMAs in my area and many can be defined as grasslands, which I don't think is an oversimplification. As a grassland can include wetlands and trees and I usually add in those features. I agree with you for large forests and features generally greater than just a few square miles.
user_5239402 (2021-07-24 11:12:51+00:00): 안녕하세요. 왜 존재하지 않는 3번 국도를 연장하고 도로를 만드시나요? 존재하지 않는 지물을 만드는 곳이 아니라 존재하는 지물을 만드는 곳입니다. 3번 국도는 철원이 종점이고 북한은 명목상 종점입니다.