¡Hola Rockedf! Gracias por su contribución a OpenStreetMap, pero he revertido este conjunto de cambios por un par de razones.

En primer lugar, y lo más importante, este local de Steak 'n Shake lleva cerrado desde 2023. La única razón de que la información como el nombre todavía está en el objeto es porque la marca Steak 'n Shake todavía es visible en el edificio.

En segundo lugar, su uso de la etiqueta check_date es inapropiado en este caso. Esta etiqueta se refiere a la última vez que se comprobó el objeto en su conjunto, generalmente para la existencia por encuesta presencial, lo que claramente no hizo en este caso, si no, habría visto que el restaurante está cerrado. Véase osm.wiki/ES:Key:check_date para obtener más detalles.

Además, estoy un poco preocupado por su uso de "local knowledge" en la etiqueta source de conjunto de cambios. He revisado sus conjuntos de cambios recientes y noté que ha utilizado esta etiqueta source en conjuntos de cambios en muchos lugares diferentes, que no todos pueden ser correctos. En este caso, "local knowledge" se refiere a información que el cartógrafo sabe que es cierta porque vive cerca del objeto en cuestión y está familiarizado con él, pero no necesariamente se ha complicado la vida por específicamente visitar el objeto y anotar la información (lo que sería "survey"). Puede leer más al respecto en osm.wiki/ES:Key:source#Fuentes_generales_usadas_com%C3%BAnmente_por_mapeadores_humanos.

Por tu comentario de conjunto de cambios, parece que quería decir que tu fuente era el sitio web de Steak 'n Shake, que como he verificado, de manera un poco irritante, ciertamente todavía incorrectamente lista este como local activo. Esta URL puede ir en la etiqueta source en vez de "local knowledge".

osm.org/changeset/166404142

I just noticed some of your zip_left and zip_right tags differed from the tiger:zip_left and tiger:zip_right tags. What was your data source for this information?

turn:lanes:both_ways=1 is incorrect tagging. What you're looking for is lanes:both_ways=1 + turn:lanes:both_ways=left. (I've corrected the instances of the error in this changeset, but just for future reference.)
---

Published using OSMCha: https://osmcha.org/changesets/165349269

Agh, I'm so embarrassed 😆 Nice catch, thanks!
---
#REVIEWED_GOOD #OSMCHA
Published using OSMCha: https://osmcha.org/changesets/165348123

I just fixed several ways that were tagged access=private in this changeset. Private access is only appropriate for cases where access requires explicit permission on an individual basis. For commercial areas where access should be expected for people visiting to patronize the business (in these cases, guests staying at the hotels), the correct tagging is access=customers.

Thank you for addressing my fixme, but for future reference, it seems shop=printing is the preferred tag for this kind of shop. Fixed here in changeset #165091411.
---

Published using OSMCha: https://osmcha.org/changesets/165059298

Did you read my changeset description wrong? I don't think we're in disagreement here. They were hamlets before, I changed them to neighbourhoods.

Possibly debatable but it is highlighted by Osmose as an issue: <https://github.com/osm-fr/osmose-backend/blob/dev/plugins/TagFix_MultipleTag2.py>. The rationale is one feature, one OSM element: as the generated Osmose issue says, the amenity is under the roof, not part of it. Maybe didn't need to be Fixed now that I know about how that's kinda part of the broader amenity on building debate, but I did these to resolve the Osmose issues at the time.

That's what I did, yeah. As for users who have it enabled, it's disabled by default and the warning for enabling it mentions that it's "not useful in some regions" so I think that's basically as covered as we can reasonably expect.

For future reference, I think around here if it's air_conditioning=yes then it's probably better to just leave it unspecified. It's not really useful information because it's basically expected for any given place.
---

Published using OSMCha: https://osmcha.org/changesets/155076376

This information would be better provided in the source tag. The changeset comment should describe what you changed. For more info on writing good changeset comments see osm.wiki/Good_changeset_comments
---

Published using OSMCha: https://osmcha.org/changesets/155489595

Heck, I wrote most of that comment earlier today and didn't think to refresh the page before submitting it just now 😭 Didn't mean to just reiterate something already said, hopefully my link is at least helpful

It would also be helpful in the future to separate your changes in different distant areas into different changesets. For this one, the California, USA edits could have been one changeset and the Paraná, Brazil edits could have been another. See osm.wiki/Changeset#Geographical_size_of_changesets

Allison: I've explained a bit more in my comments on changeset #113064020. I selected this changeset and the others I'm reverting because I compared the building outlines to the original dataset from Microsoft and the vast majority, if not all, of them are an exact match. Selecting the entire layer and pressing "add" is in fact what seems to have been done here.

> Yes, MapWithAI does throw an occasional "bum steer" out there but the vast majority of times it's good data that only needs relatively minor adjustments.
An excellent argument to make in a proper import discussion.

And yeah, I should've tried to contact you earlier, you're right, but this is still a violation of the import guidelines, which I'm perfectly within my rights to revert. I encourage you to compare the more recent addition of buildings by nitemoon: while they also used MapWithAI to add a lot of buildings, every single building has at least some kind of adjustment so it's clear that they inspected each one individually. That's allowed without discussion because it's ultimately no different than having drawn the building yourself, but just hitting "add" over and over without checking the buildings is not. That's a data import, which requires an import plan and discussion.

And to explain a bit more on why I decided to revert, it's because I keep running into these buildings when I'm editing in the area and I personally hate adjusting these things. I'd rather just draw them by hand to begin with and not have to worry about rotating. That was my motivation to start investigating how they got here.

Hi, sorry, I should have been a bit more diplomatic about how I started reaching out here and explained a bit more about what I'm doing and my rationale. To answer the second question, because I just recently got involved with OSM :) As for them not being an import because you used MapWithAI, not necessarily. I've verified that the buildings added in the changesets I'm examining for reverting were entirely or almost entirely directly copied from, not based on and then adjusted from, the Microsoft building footprint data release of June 2018. This constitutes an import and is therefore subject to the usual import guidelines. I'm leaving the fixme tags (which I did notice you've started working on, thank you) on buildings that aren't suitable for outright deletion because they have had meaningful information added to them, and anything that comes up when I'm going through the changesets that I can see there was some attempt to adjust the geometry on I'm leaving alone. I appreciate the intent to improve the building coverage around here but this is not the way to do it. If you want to improve building coverage in the area by directly adding the Microsoft building footprints as a starting point, it needs to be carried out as a proper import. And for what it's worth, I live in Beaumont, thank you for the work you've done mapping around here, I do appreciate it!

I reverted this undiscussed mass import with my changeset 154791445.

Sorry, had the wrong thing selected when I was checking the number. Changeset 154780652 actually.

I reverted this undiscussed mass import with my changeset 154794340.