I would like to suggest we remove the addr:state field from the Address UI in iD. For the majority of addresses, this field isn’t that useful in Australia given official state borders have been imported into OSM. Data consumers can easily infer addr:state for an address using these borders, and it doesn’t make much sense to be asking users to fill in this field when it’s rarely useful. It is also somewhat common for new mappers to use the long form of a state (Victoria instead of VIC) in this field, which is incorrect and continually needs to be fixed/removed.
For features that intersect with state borders, addr:state can still be manually added in iD in the tags area at the bottom of the editor if necessary. The only example of this in Australia seems to be this caravan park.
I believe many mappers fill in these fields when manually adding addresses so that it is “complete”. There isn’t really a way to know addr:state, addr:suburb and addr:postcode aren’t required unless another mapper tells you or you find it on the wiki.
Depending on feedback on this post, I would like to also consider removing addr:suburb and addr:postcode from the UI in iD (in a future poll), or at least finding a better way to present these as optional in iD. Similar to addr:state, we have official suburb boundaries that should match how addresses are officially assigned. Postcodes are slightly more complicated given we technically don’t have official postcode boundaries (they are assigned by Australia Post, and their data is a commercial product). @TheSwavu may want to comment on this further detail.
There is some previous discussion on this in this mailing list thread (May 2021), as well as various messages in the #oceania channel on Discord (search “postcode”).
Personally I prefer a full address and as always there are exceptions to the rules where its useful to add (State, postcode or suburb) but highlighting they are optional I suspect is in the wiki if you press the information icon. I dont see an immediate benefit of removing them from the ID editor despite the fact most can be implied by other boundaries (minus the exceptions).
Good point, there aren’t actually any addr:state values in OSM that represent an external territory (taginfo).
I’m not familiar with what codes external territories would use as part of their address. Looking at them with overpass (admin_level=4) it looks like some seem to use nearby states, but some of them also don’t have a state_code tag. Someone else may need to answer this.
Small inhabited islands shouldn’t be impacted by this, my understanding is that they should be a part of a state admin boundary. I don’t know how to check if there are any islands that are outside of state boundaries though.
The bottom screen tags entry area doesn’t have previous entry or nearby area data pulldowns. ie the risk of errors is higher and it takes longer to accomplish. Mouse clicks are better than typing.
Might be smart to improve that feature to input from a larger area too. eg Charters Towers requires manual typing when “too far” from its CBD (or however it works)
You can copy and paste tags in iD as if they were text (button in the top right, shown below), but if reducing errors/spending less time is really a priority, not adding it at all is also an option.
iD auto-completes from nearby addresses, it should probably make use of these boundaries now that we have them (though the accuracy of these boundaries varies between countries).
That’s because addr:state has been defined as the “postal state” in the AU tagging guidelines and you can’t send a letter to Ashmore or McDonald Islands for example. It should be also noted that this is different to AS4819, which specifies the use of the state or territory name.
The suburb name is actually Charters Towers City, iD must be picking that up from somewhere else.
I get the impression the pulldown data comes from existing objects nearby rather than (say) suburb boundaries. I speculate the distance is only a few hundred metres. Have also seen multiple postcode pulldown data which kind of suggests one of them is wrong in some nearby object. I can’t remember where I saw them though.
Generally I find that the street number is the only thing that needs typing. Everything else can be done by mouse clicks/drags, so quite fast. If reasonably near a prior entry that will mostly populate the next. Have also found some street naming errors that way, mostly the need to alt_name major highway names whilst adding local names. (ie the street name on the finger sign or overhead overlay isn’t visible on the pulldown list)
For what it’s worth, I added the addr:state=* field to iD, originally only for the U.S. In this country, the postal city and ZIP code generally can’t be inferred from mapped boundaries for various reasons. Americans know to always say “City, State” in speech and “City, State Postcode” in an address. So when we showed just the City and Postcode fields, addr:city=* and addr:postcode=* were getting heavily polluted with the state, or people were replacing the postcode with the state.
Australia’s addressing system sounds more predictable. If everything in the last line of the address is reliably and trivially inferrable and the community doesn’t expect mappers to tag any of it, then you could delete all three fields from the address format in iD. However, if you leave Suburb in there, I suggest also leaving State in there to avoid confusion and tag pollution.
Correct, iD only populates the dropdown menu with nearby and enclosing features that it has already loaded. It doesn’t call out to Nominatim for this purpose. The distance threshold is up to 200 meters away for the fields that Australia uses.
This is something I’ve only really come to appreciate recently. Both AU and NZ use the same addressing standard (AS/NZ 4819), which means that both countries have reasonably rational address systems.
I’ve seen @TheSwavu do a bit of editing to remove incorrect addr:postcode, I suspect that sometimes it’s someone just choosing the first dropdown option, even though that might not be correct.
Given these fields seem to cause more harm (incorrect values being assigned) then good (genuine cases where it should be specified explicitly), I’d support removing the fields from iD, at least that pushes changes to more informed edits. We already decided addr:country isn’t usually needed and don’t have a preset field for it, so I see no reason against doing the same for addr:suburb, addr:state, addr:postcode.
We’re not throwing away complete addresses, it’s similar to how you don’t need addr:country because it’s usually pretty obvious what country an address is in, based on nearby boundaries.
No one is discussing throwing away addresses, what we are talking about is getting rid of the pattern that makes mappers feel the need to add more. If they want to add “complete” addresses, then they are welcome to ATYL.
Well, there is a stronger principle there. Postal systems are organized on a national level. You only need the country name for international mail, not domestic mail. So the country can be reliably derived from the enclosing boundary anywhere, with very few exceptions. Even the United Nations Headquarters and its UPU-run post office can go without addr:country=US.[1] Regardless, a global geocoder has to have the ability to infer some parts of an address, just because addresses in OSM so commonly lack the less specific details, even where editors make it easy to add them.
There’s a separate collection box for domestic matter, no “USA” required on the postcard. ↩︎
By the way, the French community has been asking for something along these lines too. I think the human factors are not to be taken lightly. From past experience, it’s basically a tradeoff between allowing users to put in redundant, sometimes wrong values in addr:postcode=* versus leading them to stuff extra information in addr:street=* that renders that tag unusable. At least the former is easy to validate if the boundaries are as reliable as we think they are. It may be possible to mitigate this risk by further tweaking the UI design, but there aren’t any concrete proposals about that yet.
I agree that simply removing the fields probably isn’t amazing UX, but in my opinion “only put the street name in addr:street” is easier to explain + understand compared to “please don’t fill these fields in even though the editor asks you for them”. I think that removing the fields along with the idea of changing “Address” to “Street Address” (mentioned in that GitHub issue) is probably the cleanest solution.
The only other solution I see is having iD try and guess+manage these tags on behalf of the user, but I don’t see how that could be implemented in a way that mappers know when/when not to add these tags if a feature intersects a boundary. For example, while this building intersects boundaries and a mapper would need to manually source it’s suburb/postcode tags, this building in Brisbane actually has the same house number and street for a separate land plot in each suburb and therefore does not need a suburb tag.
Because of oddities like this, I think it’s best that the fields are removed in AU and mappers can manually add these tags depending on the situation. I think that a more experienced mapper needs to check what suburb is correct when a feature intersects a boundary, not the editor/casual mappers.
Also, I do plan on making another poll to remove addr:suburb and addr:postcode if this poll is successful, I just thought it would be a less controversial “first step” to do addr:state separately.
Not really, the building’s centroid is in the appropriate suburb. The problem will be cases where this doesn’t happen, at which point you need to start thinking about addr2:*.
I’m with @Minh_Nguyen here in thinking that just taking out one of the optional components will be confusing.
Ok, what should I do here then? Should I add an “Approve, also remove addr:suburb and addr:postcode” option to the poll, or is there something simpler I should do?
