How to edit the zipcode of a whole city or region?

Help and support
, , , ,
1

i have a question, how do i change the zipcode of a whole city in openstreetmap. My area of interest is San Felipe, Baja California. I don’t want to individually select each street and add the addr:postcode tag. is their a way to select a whole region in openstreetmap and change the zipcode to 21850. for some reason its showing a 21709 zipcode. this zipcode was used in the 70’s and its outdated.

2

As far as I know, you can draw an area and tag it with postal_code=*
Just be sure that all the building that fall within the area share the same zipcode.

If there is an outdated zipcode you have to check if it is mapped on the buildings themselves or as an area. If it is an area, just update the tag. If it’s on all the building you may use some other tools to assist you, but be sure to follow the procedures for mechanical edits.

1 Like
3

Thank you, I got a answer in the new forum. I just installed jsom, selected everything on my region of interest and changed the addr:zip code tag to 21850. The I uploaded to openstreetmap. :+1: Done :slight_smile:

4

In truth, ZIP codes (or ZACTAs) are not geographic areas, they are more like a routing algorithm for efficient mail delivery. That people believe ZIPs “are” geographic areas persists, but even as a mere belief, it is only an approximation. To delineate ZIPs accurately in a geographic sense is an exercise in futility which will only ever be no better than “approximately true.” Perhaps that’s “good enough for you,” but as they aren’t “real” geographic areas, I express my preference (despite their odd TIGER importation and questionable addr:zip=* taggings) that ZIP codes not be mapped in OSM. Because: how would you? How can you? How do you? (And nobody can really answer that, because there isn’t an answer).

As I understand it, you were making “bad data” into “less bad data.” OK, that is an improvement. I don’t believe we have a formal “let’s delete all ZIP code data in OSM, because it is noise” proposal (yet).

Edit: And I realize that I have conflated México and USA postal_code tagging. However, I sincerely doubt that you “selecting everything on my region of interest” is the correct way to say which OSM data suddenly have a new postal_code assigned to them. From what source is the authority of your knowledge? Are you also updating other areas in Baja California or greater México?

1 Like
5

Correct, but I believe it is appropriate to add addr:postcode to individual address points and individual buildings.

A better approach might be to use an overpass query for all addr:postcode=21709 where other address tags are present and change those to 21850 if we knew that all 21708 post codes became 21850

1 Like
6

Agreeing, Mike, that (I’ll speak for the USA and ZIP codes specifically, though I BELIEVE this is true of postal_codes in general around the world) placing these upon an addr:postcode is correct OSM tagging behavior.

Yeah, that’s a big, big if right there.

7

I did not suggest that an area can be used to cover all the buildings with one zipcode. When I tried to map zipcodes I quickly desisted, seeing how hard it is to be accurate about it.
That doesn’t mean that an area within which all buildings have the same zipcode cannot be defined.
While the area itself probably has no intrinsic meaning, it could make the mapping easier; especially when we’re talking about a city/suburb where all buildings share the same zipcode.

Other than that, I know nothing more about zipcodes and thus will let you advise better.

8

This can be a tricky, slippery subject. We’ve covered many of its highlights right here. If there is a “moral to this story” it is to be ever vigilant, so our data “stay at least good” and sometimes “improve by tomorrow.”

There is addr:postcode=* (often on a node denoting an “address”), there is postal_code, there is the whole topic of ZIP codes (being as defined as they are in the USA and act as a routing algorithm, not a geo-area). We’ve mashed a lot together, it’s good to sometimes talk about it all (we have here and do so) and it’s good to sometimes be aware of where to polish our data to a high gloss. Be careful with post codes, it can be a messy topic, especially as misunderstandings persist. We’re fine.

I remember San Felipe from about a half-century ago, where my family and I spent part of a summer.

9

I have some concerns about these changesets as it seems to have added postcodes to everything in the area. It’s incorrect to add address information to things that don’t have postal addresses. For example, every node in every piece of geometry:
(ex Node History: 7211813150 | OpenStreetMap). Another example is that this piece of coastline shouldn’t have a zip code: https://www.openstreetmap.org/way/376226154/history.

I would like to hear more about this changeset which adds a zipcode boundary: Changeset: 138874109 | OpenStreetMap. As noted above, zip code are not areas.

My suggestion is to revert these changes while you work out a strategy to get more precision on the edit. In my experience (3% of all address tags in the US are from me) it is quite difficult to bulk add things like this. Some strategies that tend to work better:

There’s folks here and in the OSM US Slack that have experience with all of those and will lead to much cleaner mapping. I have written a lot about adding address data in the United States [1,2,3,4] and would be happy to help.

1.watmildon's Diary | Adding addresses with JOSM and MapWithAI | OpenStreetMap
2.watmildon's Diary | Using the JOSM Conflation plugin to add 1500 addresses in 10 minutes | OpenStreetMap
3.watmildon's Diary | Using the US National Address Database to assist TIGER tag cleanup | OpenStreetMap
4.watmildon's Diary | Finding areas where OSM is low in address data density | OpenStreetMap

edit: fixup brackets

7 Likes
10

It may come as some solace that I did almost this exact same mistake, but with addr:city, the first time I used JOSM!

3 Likes
11

Again, it is easy to goof up ZIP codes / postal_code tagging. Be careful, learn what you can and what others explicitly point out as true about these things (and what are the OSM conventions for tagging with them), and, oh, did I mention to be careful?

12

It occurs to me that I could be a bit more helpful by talking about how to do the necessary reverts here. One of the easiest ways is to use this site. The changeset numbers can be found in the Edits section of your user page.

I’m also happy to revert things for you if that’s easier, but it’s kinda fun to play with the tools a bit. Let me know.

3 Likes
13

Circling back to this after my holiday. I saw it was still incorrectly added onto nodes so have taken the liberty to revert the bulk additions as changsets 139371237, 139371294, 139371349,139371380. I noticed that the revert site I pointed to above doesn’t handle these reverts well so I completed them in JOSM using the revert plugin.

Definitely let me know if you find anything else needs cleaned up. I’m sure we can find a way to get this information into the DB in a cleaner manner. Happy to help.

1 Like
14

I was going to suggest doing it by neighborhood, ward, or subdivision by way of mapping the buildings around the outside of the area with zip codes and then filling in the rest inside of the area under the assumption that they are the same. I’ve done it that way a few times myself and while it’s not as efficient as just importing the whole thing in one go, it’s at least better then nothing and doesn’t lead to the type of mistakes you reverted. I’m pretty sure JOSM allows for imports on those levels to.

15

Yeah, you really do need to have SOME feature to attach the tagto. Even a bunch of nodes on buildings that are building=yes, addr:postcode=* is a lot cleaner.

2 Likes
16

US ZIP codes do not work this way. ZIP codes work by postal routes, not contiguous geographic areas.

2 Likes
17

“A short list” of logic, works for ZIP codes as addr:postcode=* values, in the USA (thanks, Paul):

It’s OK for a node to have a addr:postcode=* value. Not on any node, like a node that makes up a building, but the “node that is the address” node.

A ZIP code (as it is as a thing, a routing algorithm for efficient mail delivery) is never, ever an area represented by a polygon, including never being represented like this in OSM. Be careful with drag-selections of large numbers of nodes in an area and then SETTING an addr:*=* value. You might want to select (only) the existing nodes with addr*=* values, first (if there are any). These are often initially edited into especially residential, commercial and industrial landuse=* areas as “many nodes as addresses” in a patchy fashion: this neighborhood, that commercial zone.

There are a fair number of “edit errors” that are “that easy” (which both is easy, and isn’t, as I ponder it). The difference between selecting too much, and/or reading or setting an addr*=* value. It happens.

1 Like
18

Question re use, or otherwise, of zip codes, thanks.

We’ve had a comment come in to the DWG to say that Isle Royale https://www.openstreetmap.org/relation/1870066 has it’s own zip code (actually a Minnesota code, despite the island being part of Michigan!).

From this thread though, should it actually be added to the island as a whole?

Code given is 55606 if that helps anybody at all?

Thanks!

19

If I’m not mistaken, this thread is actually about postal codes in Mexico, despite the title. Apparently the postal code system there is modeled on the USPS ZIP code system, but I don’t know if the similarities go beyond the five digits starting with a state prefix.

Having said that, an island in the U.S. should never be directly tagged with a ZIP code, even if every single address on the island happens to have the same ZIP code. It seems quite plausible that 55606 covers all of Isle Royale, but an island and a postal delivery route are two different concepts. The better approach would be to make sure any feature that has addr:housenumber or addr:street also has addr:city=Hovland addr:state=MN addr:postcode=55606. I’m not sure it makes much sense to tag an entire national park with its mailing address, but the visitor center, ranger station, and other POIs in Windigo could have addresses.

2 Likes
20

Oops! :crazy_face: I did see Steve’s mention of Mexico & wondered how that got in there?

The only real “streets” on the Island (apart from hiking trails) seem to be in the one hamlet, Windigo OpenStreetMap, but even the Ranger Station doesn’t appear to have an actual address as such: Relation: ‪Ranger Station and Visitor Center‬ (‪16831498‬) | OpenStreetMap (& why is a simple building a multipolygon? :thinking:)

So I think you’ve answered the question nicely!

Thanks!