Tagging a feature with addr:country=AU is unnecessary, and existing usage is gradually being manually removed by mappers. All tagged features are within Australia’s borders (relation/80500), offering little value to data consumers. Only 2.7% of addresses Australia include it, based on addr:housenumber - taginfo.
Its usage peaked early 2025 at 125k uses, and has been somewhat declining since - graph. There was a jump of 20k new features between 2023-2024, which mostly represents new addresses being added by two users. (I’ll send a message to both of those users with a link to this post, though only one appears to still be active.) Aside from that jump, I think it’s fair to say the usage of this tag has largely stalled since 2021, and I believe the community would agree that further additions of this tag are unwanted.
Therefore, I would like to suggest a mass edit that removes all 119k uses of addr:country in Australia. With the exception of route relations (more below), no other address tags will be touched. A separate bot account will be used to make these changes. I plan to make two small changesets for Christmas Island and Norfolk Island, before then making 18 changesets where features have been sorted by longitude and grouped in batches of 10k - source code. A changeset’s bounding box might cover Australia vertically, but shouldn’t cover any other countries/regions.
There are 610 route relations that have addr:country=AU, almost always in combination with addr:state. I plan to remove both of these tags from all type=route relations in Australia as part of this mass edit, in an additional changeset that spans most of the country.
2 week poll (until Sat, 2026-09-12 at 10am AEST):
Approve
Oppose
0voters
AU voters: 17 approve (80.9%), 4 oppose. Last updated at 32 votes
addr:country is useful for editors and other data consumers to recognise which country an address belongs to, which fundamentally affects the available address fields and how addresses are displayed. Downloading and processing boundary relations of all countries in the world is often not a viable alternative here. Worldwide usage of the key is also still increasing, not that far behind addr:city, and the key is listed as de facto on the wiki.
Details of the suburb, state and postcode can generally be derived through geospatial analysis based on the mapped boundary=administrative relations and aren’t required to be added to each individual address.
Tags such as addr:country=*, addr:city=* are often redundant as features inside administrative boundaries (when mapped) “inherit” their attributes as supported by software such as Nominatim or Photon.
It’s therefore no wonder that “only 2.7% of addresses [in] Australia include it.” So I don’t think editors/data consumers should rely on this, and they should instead derive the country from boundary relations instead.
I think data consumers will just have accept they need to do some processing on the data. We should not shift that burden to mappers to have to add and maintain this on every single address node, even if you have some automated edits to maintain it, you’re cluttering the changesets cluttering object versions, all make maintaining the data in OSM harder for mappers.
Would it be useful to emphasize in the addr:country=* documentation that this key is for exceptions where an domestic address is assigned to a location outside of the country’s external border? As far as I know, no country’s postal system requires a typical address to name the country except when sending internationally. Nonpostal addressing systems might be more complex, but those edge cases would be really obscure.
Hi,
Thanks for laying this out. At the same time, are we looking at ID to remove this option (along with the suburb) as standard fields presented to the end user?
As far as I know at least JOSM, iD and StreetComplete do this the proper way and take location into account rather than asking user to manually specify it.
And expecting mappers to waste time to manually preprocess data like this is silly.
What’s the actual benefit to removing them? Just removing “cruft” from taginfo?
Have any downsides been considered? Like bumping last modified dates on a bunch of objects that haven’t actually been modified. Is it going to cause confusion with mappers who don’t know this is now an unwanted tag? Or arguments between removers and regular mappers who aren’t aware of this thread/just use tool presets?
Have any alternatives been considered? Deprecating the tag in JOSM (and iD?) that would mean this tag gets slowly removed when the object is actually modified.
Like bumping last modified dates on a bunch of objects that haven’t actually been modified.
So those useless tags would de facto stay forever.
You can’t rely on a last modified date to know the accuracy of all fields, only of the last modified ones, here removal of addr:country. You have many tools to see when which tag was modified.
…what’s the benefit of leaving them in the database? Mappers are already removing them. I strongly believe establishing consensus on this is important if the tags are unwanted - see for example addr:country=GB (graph) where I believe two users have practically doubled usage of this tag, from 800k to 1.4M just this year.
There will be a bot=yes tag on the changeset. I’m not sure what problem you’re trying to raise - users/data consumers can easily ignore this changeset if they’re trying to view “real” history of an object.
No, the tag already has little new usage. Any new usage after the mass edit can easily be removed, as this forum post would show the community has agreed for removal of this tag.
That’s not an option. The tag has valid use cases (such as postal addresses raised above), and is still in use in other countries. I don’t think editors support deprecating a tag within an area. Even then, 120k uses isn’t so significant that it needs to be gradually removed.
iD isn’t listing it, I think there may have been some confusion with recent discussion around removing addr:state, addr:suburb and addr:postcode as a field (and potentially as a tag) which GuardedBear linked above.