Hi Dylan, please use more descriptive changeset comments in the future. "Local knowledge" is a source, if anything. See here: osm.wiki/Good_changeset_comments Also, land landuse tags should not be used on nodes.

It looks like the full raw address string from ATP my tools had to parse was `9150 A Alcosta Blvd, Country Club Village S.C., San Ramon, CA 94583`, and it read S.C. as South Carolina :( Most Starbucks POIs don't have that place name in their address string, and even fewer abbreviate "shopping center" like that, but I will double check the handful of nodes I see that appear to be similar. Thanks!

I did not check before uploading, but it appears the ATP info was correct, and the existing `not:brand:wikidata` tag was not. Again, (as I mentioned here: changeset/153929369) this import is not meant to go through every POI to do cleanup, I'm just adding info. So I will try to look for this going forward, but this is an edge of an edge case (an erroneous `not:brand:wikidata` tag, of which there are <3,000 in the US to begin with) that I suspect I won't encounter again.

The rules I have check for `contact:website` and only remove that in favor of `website` if the two match exactly. The whole principle of this import has been "first do no harm," and because I'm not going through every URL on every node, I'm not gonna remove URL tags just because they are potentially duplicative. In this case it looks like the URL was broken by the `#` symbol (not sure how that got there in the ATP data), which also broke the matching. I've checked and this was the only URL for 7-Eleven that has that issue.

What do you need help with?

Hi PeterDesignTowers, thanks for improving OSM in Northern Virginia. Usually, there is no need to move highway nodes a meter or two as you've done here, as different satellite imagery providers might have slightly different alignments, and it's hard to know which is the closest to reality.

FYI I have reverted all of this user's changes around the Capital Beltway

Hi Tyler, I appreciate the work you've done to add this congressional district to OSM. However, we usually avoid adding electoral districts in the US because they change at least every 10 years and are not widely useful to data consumers. Is there a reason you think this (and the other couple congressional districts you added) would be an exception to that general principle?

Yeah, not sure if the closure is permanent or temporary, hence the lifecycle prefix and not deletion, but being closed every day suggests to me some state of disuse. If you have on-the-ground insight that would be great!

FYI, just fixed the `website` tag here: changeset/152920594. I was half hoping that they would reinstate the `/store/{ref}` url pattern that GMaps also relies on, but it looks like we're stuck with all the junk at the end of the url.

I think I've fixed it in this changeset: changeset/152919606. Let me know if I did not. Now that I know this quirk (thanks!), there seems to be a lot of objects with the direction at the end of the `addr:housenumber` field, see this Overpass query: https://overpass-turbo.eu/s/1N6u. This wouldn't be too hard to fix using JOSM.

Hi dknelson, I'm happy to take a look. I've built my own parser to turn raw address strings into OSM tags. Can you point me to an example so I know what you're talking about?

Hi cotesta, where there are no weekdays listed, the opening hours are the same every day of the week. This is standard formatting for the `opening_hours` tag. I left the "Mo-Su" weekdays on the `opening_hours:drive_through` tag because that tag is not nearly as common so I wanted to be extra explicit.

Hi SomeoneElse, this data import is part of the ongoing import of All the Places data onto existing OSM objects, as linked in the changeset tags. The discussion about this import is here: https://community.openstreetmap.org/t/proposed-import-of-all-the-places-data-onto-existing-fast-food-and-cafe-pois-in-the-us/112505.

This changeset was meant to fix bad ATP data I had accidentally imported from the broken Wendy's ATP spider. See here: https://github.com/alltheplaces/alltheplaces/issues/8373

You're right. Neither link works on mobile for some reason, but the old one appears to work on "desktop view" on my phone. I'll investigate when I'm back at my computer this week.

I'm comfortable being fairly aggressive in removing address data from potential "store in store" Starbucks locations since it was flagged to me as being more prone to error than normal store data. But I'm happy to restore some of it if you all can articulate a better way for me to identify these "store in store" objects than the `branch` tag method I used for this changeset!

Hi tguen. Unless I'm misunderstanding, the website value on that way appears to be the same before and after my edit, so I don't think I touched it.

See changeset/151668196. Should all be fixed.

The thinking is just that these Starbucks are ones that are inside other stores (grocery stores, Targets, etc) that should have their own addresses, and thus these addresses are significantly more likely to be incorrect (either from parsing or because the source data is bad) and/or irrelevant.