My biggest objection to removing all these fields (not the actual values) is that it doesnt really add any value to OpenStreetMap. I look at new tagging each month in Tasmania to find records missing address data and it takes, at most, about 1/2 an hour to correct new addresses and add missing values in these fields. Its not onerous in any way and gives a complete address.
I know the values can, generally, be derived from alternate tags on other objects but if folks are willing to add them then why not give them the best and quickest way to add them via the ID editor?
There are exceptions, even whole towns/suburbs, but also plenty of building or amenities that cross boundaries or have an entrance in the next suburb over. Some of these have been changed in the past by over zealous edits without suitable checks, and have been changed back again.
Is this really such a big issue in the greater scheme of OSM tagging?
I think too that the view that the data consumer (always) has to bend to a higher level of difficulty is a bad idea. Something as simple as an overpass query gets way more complex if using multiple input sources. With all the furore that this would create I’d personally like to see the (empty) addr: fields periodically populated by the boundary records, or I’d no longer trust or use the tool to deliver the cross checking etc reports I need to rectify an issue. We already have a situation where the cardinal rule of not having multiple sources of the same data is being broken. If they are really needed then the sources need to be auto synchronised.
Yes, a can of worms..
As previously stated too, entering the full addr: data with the pulldowns visible is also a useful error rechecking tool. Having ID parse the boundary record and supplying these as (say) red text would even help me.
Removing these fields is currently the clearest option to mappers that these fields aren’t necessary, and they shouldn’t need to worry about them. Simplifying the database by reducing duplicated data and room for human error is a valuable change to make.
Do you have an example? I think boundaries are usually placed in a way that they don’t intersect with land plots, instead going around the land plot so an address should be completely unambiguous. I think NSW might be especially bad with this though. I’d like to look at processing state data to find plots that intersect with official/OSM boundaries.
This is already how the database works - if a data consumer doesn’t support filling in this data spatially, they simply don’t have addressing implemented correctly. While removing these fields from iD may make Australia one of the first/few countries to “enforce” this in iD, it is definitely not the only country to use this addressing style.
This isn’t difficult to implement either:
see this Python script from when these fields were last discussed in the VIC import.
Those are some great examples, thank you. On 78 Reynolds Road, how does the address have two suburbs? TAS address data puts it in Heybridge as well, but I don’t see how it gets Howth aside from being on that side of the boundary.
Also, I think we should choose a machine-readable tag to mark addresses like that for QA tools, regardless of whether addr:suburb is removed from iD or not. I was thinking note:addr:suburb=required; <human readable reasoning>. It may be helpful to include the expected value somehow too, so that they’re not changed to an incorrect value.
Yes. I’ve added addr2 to indicate that this address could be also considered to be in Howth, based on where it is in relation to the locality boundaries. addr being the primary address.
The Reynolds road cases may well be that the boundaries and cadastre in LIST have not been updated. Black Rock Retreat is actually on a block at 23 KENNAGLEN LANE HOWTH TAS 7316 (according to LIST) but their website indicates 77 Reynolds Road.
As we all know there are errors in both public and government data. Its just another exception that occurs on a regular basis across the country.
I think 77 Reynolds Road is assigned to the building, but the land parcel it is on is assigned 23 Kennaglen Lane. 77’s geocode type is marked as a “building centroid”, but 23 is a “rural centroid” (which I’m guessing is just centroid of rural land parcels). In this screenshot, you can see the individual land parcels but I’ve shown the property ID which means that one person/entity owns multiple parcels.
I think the main takeaway from this is that Tasmania seems to assign suburbs based on driveway entrances, which is interesting. Should probably try and find all addresses that have a locality different from it’s boundaries to check.
The suburb for the address is Heybridge, it doesn’t have a second address where the suburb is Howth. If geocoders/data consumers want to support possibly incorrect queries like this, they can do so using boundaries.
While I generally use the text entry in iD editor, the pre-formatted fields have some advantages.
Even if the ones that are displayed aren’t necessarily the ones I would pick, in general, the address ones are helpful. It’s possible that they aren’t at all for Australia.
Maybe the we could vary the surrounding colors of the fields depending on how important we consider them for a country.
OSM relies on casual mappers to bring their own local knowledge to bear on a lot of things, including contact information. This is a tradeoff. In my own part of the world, we have access to an extensive dataset of shops contributed by the shopkeepers themselves and boy it’s embarrassing how many shopkeepers get their own name and address wrong. Still, opening it up to the masses is how we find out about the edge cases that the expert-run platforms don’t have the patience to look into.
For sure, the suburb and postcode can be derived from boundaries in general, so that should at least be a geocoder’s fallback strategy. It sounds like we’re moving away from the stance that these fields always follow the boundary as a rule. So it’s unclear to me if the concern at this point is primarily about the prevalence of incorrect data or about something more technical like database optimization.
As long as addr:suburb=* differs from a boundary test, then that’s already an indication that it’s one of those edge cases. If we need to reinforce the tag against naïve attempts to normalize it to the boundaries, then consider setting not:addr:suburb=* to the naïve value. This uses an established namespace. iD already warns when the user attempts to set name=* to the value in not:name=* and can easily be made to do the same for addr:suburb=*.
We are drifting from the original topic of addr:state but I think this thread has highlighted enough instances of suburb and postcode anomolies that the suggested ‘not:addr:x’ keys would at least be useful as a standardised way of tagging those anomolies.
Another example (with the suggested tags for suburb and postcode)
As an aside, I have found 324 examples in Tasmania that I will check out over the coming days. Bound to be a mix of errors and true examples amongst that lot.
)