I have reverted this bulk addition as well as 138903689, 138903683, 138903673. My change sets are: 139371237, 139371294, 139371349,139371380.

As I noted here:https://community.openstreetmap.org/t/how-to-edit-the-zipcode-of-a-whole-city-or-region/101555/8 I'm sure we can find another way to get this into the DB a bit more cleanly.

The geometry here looks so nice! Great work!

This changeset should have the comment: Adding addresses into the greater Phoenix area from the ESRI prepared National Address Database #OSMUSProject377 #phoenixaddress

Love the detail! Nice work!

Love the detail in these changes! Nice work!

Perfect. Much appreciated.

Oh my! Thank you for catching this!!

Did this pop up in a QA tool somewhere? Would love to check other areas to make sure I haven’t botched anything else.

Wonderful.

Hello!

Love the detail in your edits on this area. Just a heads up that addr:street should have all shortened portions expanded to their full text. ex: "E Virgil Dr" -> "East Virgil Drive". Not a big deal but does help alleviate confusion and keep tools happy.

I'm rolling through with address data for this area as part of this project (https://tasks.openstreetmap.us/projects/377) so anything here will be noticed and patched up by me. Happy to do so.

Keep up the great mapping!

Matt

Had some extra time this weekend. I think the address data has now been all added and corrected in this changset: changeset/137772589

Definitely let me know if you seem something amiss. I've also posted in the OSM US Slack (arizona local channel) asking for a set of eyes to make sure it's all good to go.

Leaving this here as another breadcrumb for me. Sorry for the spam! https://en.wikipedia.org/wiki/Sun_Lakes,_Arizona

Of course I post this and immediately think about looking at the admin boundaries to see if that's a sensible way to distinguish things. I'll try that tomorrow afternoon.

That's great! I'm always happy to get a bit of an assist from folks on the ground. I see that the ZIP locator on USPS also lists both.

So I think my plan will be to finish the additions from NAD for this area (avoiding any further overwriting), then sample addresses from company websites and the USPS address lookup to get a sense where the boundary is and make the Chandler/Sun Lakes update en masse. I'll also post over in the OSMUS Slack to see if another AZ mapper can double check. Does that seem sensible?

For full context, I'm about 60% done with this project: https://tasks.openstreetmap.us/projects/377. I should be able to get through the plan up above by mid next week.

Let me know if you have thoughts/concerns. I appreciate the response!

Hello!

I was adding address data into this area from the National Address Database file and some of the addresses you have as addr:city="Sun Lakes", have now been updated to "Chandler". I'm not local enough to know make a precise call on this and would love any feedback you have. Happy to update things around here as necessary.

Thanks!

I have completed the US update for this type of issue.

Hello!

At a minimum, I see there's a bit of doc deficiency here. Thanks for pointing it out. There was more information in the tasking manager project but I see that the detailed info is no longer available after the projected is completed and in "archive" status.

The short version is that several mappers in KS had identified that this area could use an overhaul of address data (and other information) due to the low quality of a few previous imports. One of the issues was somewhat dodgy mapping of building tagging from the original dataset to OSM tags. When discussing with mappers in the Kansas channel of the OSMUS Slack and the global Discord, the consensus was to "downgrade" some of the specific tagging to buliding=yes so it could be reviewed/resurveyed by local folks (ex:StreetComplete has a popular building=yes quest).

As for addr:country, the ESRI data endpoint had exceptionally good unit level address information so almost every address tag got remove for the refresh. There were also a lot of things (random nodes, roadways etc) that, in my experience, don't have addr:country tags in the United States.

All that said, if there's an area you'd like me to review or a set of tags you think should be returned to items, that's super useful information and I'm happy to work on it.

Matt

You got it. I have a big cleanup of these in my work queue. Hopefully get to them all over the next few weeks.

Hello!

While doing some cleanup of cities from the ESRI Address feed, I noticed some of the addr:city here ended up as "Unincorporated". I'm happy to patch them up using the USPS zip locator but wanted to let you know in case you think there's a better solution.

Matt

For folks using iD and JOSM, having a bunch of relations in the editing area can make things quite frustrating to edit.

I totally hear you about selecting can be a bother. iD has '\' as a hotkey for "select the next way that shares this node" and JOSM has the rather cumbersome "middle click to cycle through coincident objects". It's also not helped by iD trying pretty hard to hide that relations are a thing or JOSM pulling all relation selection/editing into it's own side interface. And don't get me started on relations of relations ha.

I'll have to fire up Merkaartor sometime, differences in editors definitely can make "best practice" more difficult.

Hello!

I would love to continue the discussion over at: changeset/136645299 regarding your addition of relations with only outer ways (ex: relation/15953082#map=18/57.64039/-1.96913) vs leaving the ways as is.

Again, I currently think this is generally not great practice and would love to hear more from you about this practice. I don't see anything on the wiki (osm.wiki/Relation:multipolygon) that supports editing the map in this fashion but perhaps I've missed something obvious.

If there's no articulatable benefit, it would best to discontinue the practice.