<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Nov 8, 2021 at 5:36 AM Brian M. Sperlongano <<a href="mailto:zelonewolf@gmail.com">zelonewolf@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">I don't have a problem with the large size of the bounding box, as it is clear from the changeset description what the change is, and it is topically consistent (i.e. - it's not a changeset with a park in New York, an ice cream shop in Albuquerque, and a river in St. Louis!).</div></blockquote><div>I do have a problem with the large changeset bounding box, although without the large bbox this changeset - that is problematic for additional reasons - wouldn't have come to our attention.  </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div><br></div><div>I *DO* have a problem with the change itself, as name:en is redundant when the name is already in English.  The data consumers that I'm familiar with (namely, OpenMapTiles, and my own service) that are tasked with extracting names in English are perfectly capable of looking for name:en first, and then falling back to name if name:en is not present.  So IMO, this is tag bloat.  I have added a changeset comment requesting an explanation for the change and will link to this discussion.</div></div></blockquote><div>Agree, like most mechanical edits, this adds little value.   Generally, if it was easy for the person making the mechanical edit to do, it would be easy for the data user consumer to do.  Also since it wasn't discussed on one of the official mailing lists and documented on the wiki, it violates our policies and norms.  Finally, there is a risk with mechanical edits to do great harm as a small error can be systematically spread over many objects.  I am not sure that happened here, but the burden should not be on the community to assess that after the fact, rather the burden should be on the person proposing the mechanical edit to convince the community ahead of time that this is unlikely (by documenting their process and tools), and that the benefits outweigh the risks.</div><div><br></div><div>Mike</div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
</blockquote></div></div>