Smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

▪︎what makes for osm.wiki/Good_changeset_comments
▪︎much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Also tag as boundary=marker ?

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

🥳.

An impressive & daunting amount of work. Bravo 🍪. Thankyou for your diligence.

“you will see I have spent a long time making sure they are very accurate.”

Not at all. You failed to cite any source for your changes. I have nothing against which to compare, let alone verify.

There is no (explicit) indicator of how much time you spent on this changeset.

You may be convinced, but that misses the point.

When silly blunders are being made (bbox, misunderstanding of changesets), that's hardly convincing (to anyone but you). I must also question how much care you put into the changeset as a whole (including metadata), rather than only changes to map data elements.

Not to mention the revealing remarks made in other changeset discussions.

“I have not imported any data to OSM. I have exported golf course areas from OSM ready for import into the course designer used.”

Very well, then. That wasn't entirely clear from your earlier phrasing (especially talking about LIDAR & designing courses).

“This is quite a common practice whether you like it or not.”

Then you don't understand copyright or the philosophy from which OSM came. Unsurprising.

While my opinion alone doesn't overly matter, the collective opinion of many individuals does.

That you're allowed & able to use OSM data as you describe is actually entirely due to many holding the opinion that it should be so (and that you needn't ask explicit permission).
If the project were proprietary, then the story would be different (but I wouldn't care since I wouldn't be involved, then).

This relates to what it described earlier about community.

I was simply making the distinction clear for a newbie. It's a pity that you feel butthurt about it.

That it's common is irrelevant, here.

Maybe you should simply be grateful. I imagine that freely & easily available map data, greatly enhances any simulation.

“Your comments seem to insinuate that I am making changes to the golf course features that contradict what's actually there.”

I acknowledge your interpretation of what I actually said (& did not say).

That's a gross oversimplification (and thus misrepresentation) of my stated thoughts (and, keyword; concerns). For now, I'll not assume that you're being intentionally dishonest.

For clarity, what I'm seeking is confirmation & evidence that your changes are sound.
Again, you specified no source for your changes.

Your changeset; your burden of proof.

If all your changes are (for the sake of argument) perfect, then great. However, newbies making inappropriate changes isn't unheard of (I even cited some common examples).

Though, if your changesets were indeed flawless, then it's unlikely that other mappers would be questioning them. QED.

“That couldn't be further from the truth as was evidenced by BCNorwich's comment on my cayman golf course edit. Telling me off for not calling a sand trap a natural 'sand' feature.”

We must be thinking of different changesets. I saw no such thing in changeset/117198630 .

What I saw was BCNorwich expressing concern over data quality, and offering advice to a newbie.

If you interpret that as hostility, then that's quite sad.

Having been in your position (as a newbie, at least) before, my my reaction to constructive criticism via review was rather different. But, then I also sought review of my early changes, to know what could be better.

Since I'm unclear as to which bunker was being referenced, it would help (in the original set) to cite the element's URL (or at least the type & ID) for closer examination (hence one of the problems with large changesets). That would enable more focused discussion.
Why? Well, because it seemed to me that he was saying that the sand feature should NOT be tagged as natural=sand (or similar), since it's not natural. Instead, to use golf-specific tagging. Compare a sandpit in a children's playground; because it didn't form through natural processes, there's different tagging for that case than, say, a sand dune (or a golf bunker). Tagging should describe what something is, even if it ends up being rendered similarly to other elements involving sand (beach versus desert are conceptually distinct, despite both (commonly) being surface=sand).

More generally, I don't see how BCNorwich's observation counts as evidence for the veracity of your own changes. Quite the opposite.

There's a distinction between adding a feature (let's say a tree) with the honest intent of doing so faithfully (as in, there really is a tree where you placed the node), versus knowing which key=value pair is best used to represent that. Imagine I added a node for a tree with … I dunno, something like wood=tree or maybe plant=tree (because I didn't know better), then another (much more experienced) mapper remarks that it should be natural=tree (if I recall, it's been a while since in added one).
That's not a case of meaning ‘there isn't a tree there, fool’, but one of pointing out that my choice (read: guess) of tagging needs attention (to represent a tree using existing standards).
I mention this, because I wonder if it may be a factor. The concepts are quite abstract, and many (especially newbies) understandably struggle with them.

“As for splining, I'm actually amazed you think that's a [sic] golfing terminology [sic].”

This condescension isn't helping your case. Particularly after needing & having basic shit explained to you. Perhaps if you had bothered to complete the tutorial. But, alas; that's expecting too much.

Forgive me, O snarky one, for remaining focused on the topic at hand, and assuming (much like I'm assuming that you're able to read, comprehend, and type English rather than merely imitating it (programmed responses, sort of thing; The Chinese Room Problem if you care to know more), or that you're human not an AI) that an unfamiliar term used by a golf enthusiast might plausibly be from that domain, instead.

“You can use a dictionary for that term.”

You mean, like:
▪︎http://searx.gnous.eu/search?q=define%3Asplining
▪︎http://en.wiktionary.org/wiki/splining
? Neither of which yielded anything matching your next claim 🤦‍♂️. Lots of references to woodwork & machining / fabrication. None to mapping.

Perhaps you could show me how I'm doing it wrong, and the obviously correct way to find a matching definition.

“[Splining is] the very process OSM uses to edit feature using areas, lines etc.”

OSM doesn't edit a thing. Editors & contributors do.
I'm actually amazed that you, as a newbie, are not intimately familiar with all of OSM's terminology & distinctions. 😲

Even osm.wiki/w/index.php?search=splining&title=Special%3ASearch&fulltext=1 yielded only some mentions of JOSM plugins, and curve-drawing tools.

Seems that it's originally a mathematical term, specifically related to curves. Not areas (unless that's an obscure or niche use).

Use of the term “lines” is misleading in this context. In OSM the only lines are straight. Pseudo-curves are formed from many straight segments between nodes. Roundabouts, for example, aren't (stored as) circles, but polygons.

But, yes, bad me for not being a mathematician. 40 lashes at the post! 😆
Maybe BCNorwich can sell tickets.

Yet, this is akin to a mapper not having a working knowledge of graph theory, and the associated algorithms. Obviously I don't need to mention how graphs are relevant to OSM to an omniscient expert such as yourself.

“For someone who seems to know so much and takes so much time to enforce rules of OSM editing, then I'd expect you to know what splining is.”

So, your complaint is that I don't know everything? Right. Now I'm thinking that my prediction re your (dis)honesty is being proven true. How sad.

Perhaps you should start by setting the example. Given your ignorance of OSM basics.

Based on my above reply, it seems that you're none too clear (on splines, or STFWing), yourself.

From my reading, one can draw curves without splining (that is, which are not splines). So, even your premise fails scrutiny. You should read about making valid logical arguments, then about making sound ones.

I could retort that I find it amusing that a golfer doesn't know how to map a bunker. But, that would be disingenuous, hence not lowering myself to such pettiness. Instead, preferring to focus on the facts at hand, despite the array of fallacies I must wade through.

Instead of being an ass about it, you could extend the same courtesy to others as they have to you, by either explaining or citing a relevant reference for them to read.

Enforcing rules how, precisely? I'm attempting to explain & persuade, even in the face of attempted derailing, hostility, childlike attitude & pettiness, insults, dishonesty, and various fallacies.

Interesting that you would much rather evade the point, and engage in drama (attempting to make it about a personality-dispute soap-opera).
For one who thinks so highly of himself, you have much to learn. Classic Dunning-Kruger.

This is becoming only too predictable, and thus boring, now.
At least others (interested in being reasonable, and learning) will benefit.

Not to mention adding to your track record, for when you end up facing the banhammer or other sanctions.

“the only mistake I've made is not realising the change set spanned an enormous area of Europe!”

Yet another claim. More arrogance, too.

Do you have anything fresh, substantial, or otherwise of consequence? Perhaps something salient, to start.

“that was completely not intentional.”

Which rather undermines the credibility of your previous point. Oh dear. Cognitive-dissonance for the win, eh? 👏

“I always click save after editing the golf courses”

Evidently not.

“I wasn't expecting half the UK to be included in the changes made to anfi tauro!”

So, instead of running your mouth, perhaps demonstrate your superiority by learning at least some basics. Start with completing the damn tutorial.

Demonstrate some merit, if you wish to be taken seriously.

“I have nothing to apologise for with regard to the changes I've made.”

Who (other than you) said anything about apologising?
This is pure projection. Check your assumptions.

“I use OSM editor for the changes I make and if they supply fairways, greens and sand trap features as a valid feature then I am well within the rules to use those feature tags.”

Firstly, there is no ‘OSM editor’. The editor you used is iD. There are many (quite different) editors.
This willful ignorance of such basics really isn't helping your case.

However, your description & assumptions are (yet again) not how it works. Presets are for convenience. Treat them as suggestions. It's still on you to ensure that the changes you make (including of tags) are sound.

Instead of trying to bicker, you could ask. When not being obnoxious, experienced mappers are very likely to help, willingly. Your attitude is likely why BCNorwich saw fit to not waste any further time on someone so unreceptive (to put it mildly, and say the least).

Different editors use different presets. There's a few reasons behind that (all of which are beyond the scope, here).
Some presents are known to be (and sometimes marked as) being deprecated.
Tagging schemes are, on occasion, deprecated in favour of new ones (designed from lessons learned of the problems with the previous scheme).

Just because an editor suggests something, doesn't mean that it's inherently valid.
Just because I could pick up my ball from the tee and walk it to the hole, doesn't mean that I scored a (valid) hole-in-one.

When multiple suggestions might apply, or at least exist even if you don't know of them, then how will you choose the right one?
That was evidently the case based on BCNorwich's comment.

Editors, just like QA tools, can be wrong (and are a fair fraction of the time).

Sounds like you're seeking any excuse to railroad your changes.
I've encountered other characters with similar attitudes, before. In the end, they were clearly put in their place by those who do actually enforce the rules.

Ultimately, a poor workman blames his tools.

If your contention is that an editor shouldn't allow you to do anything incorrectly, then the ultimate solution to that lack of responsibility-taking is to block you.

“End of discussion as far as I'm concerned.”

If you're not willing to engage, then that makes a bunch of decisions a whole let simpler.

Best of luck with this approach.

So sad that you're not willing to be reasonable.
That you care more about arguing, and appearing right (or at least being very defensive), than in learning to do quality work. Sloppy work will simply be reverted by someone (perhaps other golfing enthusiasts, who hold OSM as primary when editing, having learned good practice).

“Unfortunately that doesn't import into golf simulators and the like.”

Then you're engaging in osm.wiki/Tagging_for_the_renderer which is not how things are to be done on OSM.
Map data is to be accurate above all else. Mapping for any particular renderer is the opposite of this. Such poor quality changes should (& eventually will) be reverted.

The problem you described isn't one of OSM, but of the software you're importing into. It should be fixed.

In preempt of the complaint that the golf simulator in question is proprietary (or otherwise can't be changed): that isn't OSM's problem. Use software which respects your freedoms, instead.
In such a case, though, a workaround (for the sim) would be to export OSM data, then make whatever changes to the export, then import into the broken simulator.
That process could be automated, by a software tool.

“Greens, sand bunkers, fairways, tee boxes have to be marked as areas to be properly imported.”

Concerns of a game / simulator aren't relevant for OSM. Improve the map for its own sake (by following the rules), not for some secondary use-case. Else, you'll keep facing conflict, here.

“Please kindly refrain from policing my OSM edits. There's got to be something more productive you can be doing than commenting on other people's edits. Especially without finding out the full facts👌🏻”

Charming(!)

Whatever benefit of the doubt I had been extending you, has now been erased by your remark.

That's pretty arrogant of you, as a newbie, speaking to a very experienced mapper who has a long & extensive contribution history, while you have <100 changesets (which shows, given some of your statements).

OSM isn't 8chan or otherwise a place for shit-talk.

Ironically, such an attitude is likely to attract more attention from other mappers (particularly when you're careless enough to make a changeset with a huge bbox).

Aside from your poor attitude & shitty tone, in general, I'll address some specific points (to drive home the lesson):

“refrain from policing my OSM edits. There's got to be something more productive you can be doing than commenting on other people's edits.”

Reviewing changes (especially in one's local area) is part of the culture of OSM. The goal is quality data (via quality changes).

You, as a newbie, should welcome this. Regard it as a means to learn.

Even the best of us make genuine mistakes. Review is one way that mistakes can be identified.

BCNorwich was actually doing you a favour, and trying to help. No need to be obnoxious about it. Unless you'd like to be blocked, instead.

This isn't your personal playground; the rules of this arena have already been established.

“policing my OSM edits”

Interesting, your choice of words. Suggests much, both about you & your intentions.

While you may feel that you're being ‘picked on’, that is very likely not the case.
Instead, consider:
▪︎you may be editing in an area he's monitoring (perhaps it's local to him, or of some other interest)
▪︎you're a newbie; some review tools flag this because newbies are more likely to make obvious (to experienced mappers) mistakes (so it's a chance to instruct them for future improvement) & lack an established track-record. Like with other comparable projects (think Wikipedia) there are spammers & vandals; catching these early is important.
▪︎the nature of (some of) your changes may have been flagged by quality-assurance tools; a bunker in a golf course is, indeed, not a natural formation, and shouldn't be tagged as such
▪︎perhaps BCNorwich also has a particular interest in golf courses. It is common for mappers to pursue particular interests in their contributions.

Review is entirely productive, actually. Necessary & often thankless.
If you dislike how OSM operates, then you're free to leave or otherwise refrain from making dubious changes and/or voicing your butthurt.
Ultimately; you're not special. So don't assume special treatment.
Learn, instead of complaining.
Have some humility to ask questions, instead of pole-vaulting to wild conclusions.

“without finding out the full facts”

How ironic, from a newbie. 🤣🤦‍♂️🙄

It is not encumbent upon any OSM mapper to know about all the possible uses of OSM data. It is encumbent on OSM contributors to know how to do so properly and the rules by which OSM operates.

Knowledge / facts about golf aren't relevant, here. Knowledge / facts about OSM are.
I'm very sure that BCNorwich is well versed in relevant facts re OSM.
A newbie would do well to follow that example, if wishing to be taken seriously.

“Golf features are an allowable and included feature on OSM! So you're just wrong!”

He didn't say otherwise. You clearly misunderstood.

His point was that bunkers should be tagged as a golf feature, not a natural one.

🙄 pot calling the kettle black(!)

“The roads and buildings should be more of a concern if you look more closely. I will be reverting them back once I am done. Chill.”

This is ambiguous, to me (which elements & why?).

It's not for a newbie to tell a long-time mapper what his concerns should be. Quite the opposite.

If they bother you, then you be concerned about them.

Be sure of your changes before committing; avoid the need to revert.
Start small, rather than with major changes. Crawl before you walk before you run. This isn't your grandfather's map.

Take your ego out of it, too.

See also changeset/117962310 .

“the comment I selected from a previous course edit would classify the new course as being part of an old change set”

No, that's incorrect.

The comment is orthogonal to what the set contains (elements changed, area of the bounding box). The comment should describe the nature of the changes made. What makes for osm.wiki/Good_changeset_comments

The large bbox is due to editing in a distant area without first closing the set for the previous area.

In your editor of choice (iD), to close a changeset involves pressing the “Save” button.
The point / ‘suggestion’ I made was to do this between editing different golf courses (like with your other changesets).

Further reading: osm.wiki/Changeset

“open street map could make the comment selection process a bit more transparent”

OSM is a system, comprising many parts.

Sounds like your complaint is about your chosen editor.

What do you mean, exactly, by ‘make the comment selection process a bit more transparent’?
What's unclear & how could it be improved?

Comments are whatever you type in (as mentioned, they should be a clear description of the changes made in that set; what makes for osm.wiki/Good_changeset_comments ). The entries in any drop-down list are very likely to be your previously-entered values.

“changes I've been making to individual courses have not effected the actual courses”

Err, that's self-contradictory (unless you're referring to the physical courses in meat-space which are represented in OSM, but that misses the point).

Changes necessarily affect the element(s) being changed. Else, to have on effect, then the change-count would have to be zero (which is self-evidently not true).

Sounds like you're focusing on the default (Carto) rendered tileset, which misses the point. The tiles are rendered from the database. The database (of tagged elements) IS the map.

Mapping for any particular renderer is bad practice: osm.wiki/Tagging_for_the_renderer
If a renderer is having trouble with valid & accurate data (e.g. a tag it doesn't recognise) then it is the renderer which must be fixed. Corrupting the data is the wrong approach, for so many reasons.

“The changes I've been making […] in most cases have made the splining much more accurate.”

Splining? I'm not familiar with golf terminology.

Made them more accurate how, based on what (source)?

OSM is about mapping what's on the ground, in an accurate & verifiable way.

“I had assumed that I wouldn't be intentionally upsetting any other users with my changes”

OSM is a collaborative community (by necessity). Mappers must be mindful of this.
Other mappers are the basis for quite a few meta-features:
▪︎changeset comments
▪︎best practices (like small area changesets)
▪︎citing the source of changes
▪︎…

OSM isn't purely about producing a map; it's about managing a dataset (to ensure, as best we can, quality). A whole bunch of metadata (see the above list) is useful to other mappers (in various ways, in several situations).
Where data came from is also an indication of its quality (accuracy & recentness).

Many in this community care deeply about proper management of the project & maintenance of the data.
It's not a game; important things rely on this data. Messing it up has real-world effects.

Dedicated mappers often monitor their local area for changes. Both to be aware of relevant changes (by other mappers), and to catch errors (e.g., inexperienced newbies, or someone copying from proprietary sources).

Reviewing & verifying changes is part of the culture. For many excellent reasons. Just like at Wikipedia, or a software development source-code repository.

“because I made the changes on different days, different times and at different locations.”

Irrelevant. What matters is the quality of (your) changes.

I get the impression that you may be trying to fly under the radar with dubious changes. That's not gonna be received well, if it's the case.

“Now I know that the auto comment selection is actually directly linked to the change set geography.”

Again, incorrect. See above.

I strongly suggest that you do a bunch of reading, at the wiki, before making any more changes.

“The use of OSM for golf course is a very large community and ongoing thing.”

While that's fine in and of itself, that isn't excuse or justification to alter OSM against established policies for the benefit of some niche at the detriment of others.

When editing OSM, a golf game should be the furthest thing from your mind. It's always secondary to what's best for OSM.

If, in making quality changes, you want to focus on golf courses, then fine. The problem is if those changes are done for the wrong reasons.

Ignoring the rules is taken seriously, here. Bad changesets will be reverted. Persistent disruption will invite admin-imposed blocks on your account.

“The changes made by course designers will be kept within the boundaries of the course and are only ever improving the accuracy of the splining and map features within those golf course boundaries.”

Again, irrelevant. All that matters is quality (accuracy of representing what's on the ground, being verifiable, done so within existing conventions (e.g. tags used) & policy, else adhering to consensus of other mappers).

Bad changes are bad regardless of who makes them. Likewise for good changes.

The question of if changes are an improvement is decided by the community (and ultimately the Data Working Group).

Changes are only improvements if they serve OSM's goals (an accurate map).

“Things like footpaths that are actually golf walking paths or golf cart paths.”

If that's actually the case in reality, and the tagging used is acceptable (rather than ignoring existing conventions), then yes. Similar to marking stairs (via survey) along footpaths which were added from imagery. So long as there are actually stairs there, in reality.

“Correcting these not only benefits the import into the game, but also makes the OSM for that location even more accurate.”

This is where my concern lies, and I feel that your priorities (in terms of making changes to OSM) are backward.

Using OSM data (for a game or whatever else) is fine (so long as the license is obeyed). But, using existing data is one thing. Changing it is another.

A bit more bluntly; for me, personally, I don't really care about golf. My attitude toward data being used for games is benign indifference. It's not a problem, but also isn't deserving of any special treatment.

However, if you merely perceive OSM as a means to an end, then your motivation for editing is coming from the wrong place.

Primary focus should be OSM itself. Using the data in a simulator is secondary.

Manipulating the data, in a way optimised for one particular use, isn't acceptable (and such changes should (& eventually will) be reverted).

If you're making the map (regardless of intended use) more accurate; great.
If you're ‘tweaking’ the data for the benefit of some game / simulator; definitely not.

The difference comes when the interests / incentives between what's best for OSM versus a golf game, don't match, and you must choose.
It sounds like you're always choosing the secondary use, in spite of the primary.
This is wrongheaded.

The solution is to make the secondary use (golf simulator, or whatever) match the interests of OSM. So that importing data is conflict-free.

Expecting OSM to adapt to a golf simulator, is backward, and an attempt to ice-skate uphill.

“After all it's imperative that LIDAR data and OSM data align as closely as possible to achieve a satisfactory course design on golf simulators and games.”

Again, I disagree with your priorities.

There are many problems with this approach / attitude.

Firstly; where's this LIDAR data coming from? What copyright license applies? Copying (into OSM, which includes importing) from proprietary sources, is not allowed (because copyright law).

Secondly; how is the alignment being ensured? See the wiki for details about the problems relating to alignment of aerial imagery.

Thirdly; since your concern seems to be having OSM match some other (LIDAR) dataset, rather than determining if the dataset is worthy of and acceptable for inclusion into OSM; how is the recentness of the LIDAR data being ensured?
How is it captured (to ensure accuracy)?
What QA filtering (if any) is being applied?

Fourthly; the rules for importing a dataset into OSM are even more strict than for manual editing (again, for good reason). See the wiki.

Blindly importing datasets is a bad idea.
Importing should only be done if the requirements are met. If not, and the conflicts can't be resolved (e.g. in an incompatible license), then the data shouldn't be imported.
OSM itself trumps any particular external dataset, regardless of any individual's personal interest.

You're always free to export OSM data, apply whatever changes / imports (not withstanding copyright problems; but that's then your concern & liability) to that exported set, and use the result for whatever you wish.

Wishing to apply the same changes upstream (to OSM proper) means doing so by OSM's rules.

“Hope my long winded reply helps to clarify your concerns.”

Long-windedness is fine by me. Sadly, however, my concerns are stronger, rather than satisfied.

“[…] thank you for pointing out this huge area changeset. I had no idea that was happening.”

👍

“I'm grateful for you explaining how these changesets work.”

You really should ensure that you do understand how they actually work, before making any further changes: osm.wiki/Changeset .

“I'm slightly concerned about the stated purpose of the changes” & “if the changes are optimised for the intended game-use primarily”

Seems that my concerns & suspicions were well-founded; see the discussion of changeset/117198630 .

Hello, welcome to OSM.

Thankyou for your efforts to improve golf courses.

However, some advice & questions.

Firstly; much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets
Given your (CS) comment; no more than 1 golf course per changeset would be sensible 🙂.

Among other reasons, large bounding boxes cause many mappers to be notified (instead of only local ones), and make review & verification difficult.

However, I'm slightly concerned about the stated purpose of the changes (particularly by a new contributor).
While I have zero problem with or objection to OSM data being used for a game (provided the license etc. is obeyed), my concern is if the changes are primarily what's best for OSM with the likes of games being secondary, or if the changes are optimised for the intended game-use primarily (akin to osm.wiki/Tagging_for_the_renderer or what's done by some Pokémon Go! players).
Could you elaborate on this point?

You may wish to peruse osm.wiki/Good_practice for more background.

“What change did [Max] actually make?”

For that element, seems to have only been the name tag, thus; s/^H\.Samuel$/H. Samuel/ (literally inserting a space between the initial & the last word).

“Yes.” [re node #1804845200]

Thankyou for the confirmation.

“Osmose on its own is not a source.” & “Osmose only makes suggestions.”

That was my concern, too. Particularly since the name for the Jersey element (shop=jewelry) was added via survey (someone using StreetComplete); see changeset/79268662 .

So, even if Osmose were (somehow) a valid source, it still wouldn't trump a survey.

I'll see if I can resurvey (as if I don't already have enough to do (as the lone surveyor) on this rock(!); drive-by changes by those in far-away armchairs (even if well meaning) become tedious); the signage outside that retailer is quite bold. I vaguely recall it being somewhat ambiguous re if there was a space after the “H.”.
it'll probably have to wait until after the weather clears, though.

As I've had to state to others; uniformity comes second to correctness / accuracy. I value a neat & tidy dataset as much as the next guy, but OSM must represent what's actually on the ground.
If QA tools are making poor suggestions, then help to refine the tools, instead of mangling data.

Separately; thankyou, Andy, for the bilingual response. My French is beyond rusty (and probably useless for technical discussion).
Thanks for also doing yet more clean-up, once again. Some of us appreciate the DWG 🙂.

I can only concur with @fghj753 👍

Much smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

osm.wiki/Good_practice

Notably:
▪︎what makes for osm.wiki/Good_changeset_comments
▪︎osm.wiki/Changeset#Geographical_size_of_changesets

Also, completing the tutorial within your chosen editor (iD) is a good idea.

Better yet; if you find it (the tutorial or editor in general) lacking in helping to guide you toward making quality changesets, then submit feedback to the developers of that editor; your perspective as a newbie is valuable. For iD you can do so at http://github.com/openstreetmap/iD .

▪︎what makes for osm.wiki/Good_changeset_comments
▪︎smaller changeset areas, please: osm.wiki/Changeset#Geographical_size_of_changesets

Reverted: changeset/116778932