Hi all, I’d like to discuss importing address data for Townsville, Queensland, Australia. This is not yet a proposal as I wanted to discuss this with the local community first.
The Townsville City Council publishes a property dataset which includes address information. It is licensed under CC-BY-4.0 but someone obtained a waiver in 2019.
There’s currently just ~1750 addresses in OSM for Townsville (Overpass query) - this new data contains 80 000 addresses and would significantly improve the map around Townsville.
I’ve created a page in the wiki documenting my progress. I’ve successfully transformed the data into OSM’s XML format, and you can download it from GitHub and load it into JOSM to have a look.
I’m still unsure how to conflate this new data with the addresses currently in OSM. JOSM’s validator could be quite useful as it checks for duplicate addresses, but does anyone with more experience have any better ideas?
addr:city does not apply in Australia as we don’t have the concept of a “postal city” (the place you put on a piece of mail that’s different to the name of the place you want it to go).
addr:postcode and addr:suburb are redundant as they are already available from the admin_level=9 boundaries, so they don’t need to be imported.
As to conflation, I’d start by extracting what is already there using Overpass and see how they match up with the dataset. This’ll give you an idea of the quality of the two sources.
Would be also good to know what the propertytype represents. Looking at it I’m guessing:
STR => Strata
UNI => Unit
LEA => Lease
RESERVE => what it says on the can
PTO => ? Only one of these and it’s a helipad.
LPO => seems to be everything else. Not sure what LPO stands for.
I’ve removed these tags, thank you for pointing that out.
I loaded the existing address data into JOSM and it looks like the majority of existing addresses were added by the Annon Paper Delivery team as they don’t exist in this dataset. Seems to be mainly units in retirement villages. There’s also this patch of addresses that seems to be a mini import of this dataset, as their positions perfectly match up.
Excluding that, there’s not many addresses, but the two sources seem to match up. It also matches up with a little on the ground address mapping I did a while ago. Seems to be pretty high quality.
That’s interesting! There’s very few with LEA, UNI is only present on addresses that already have addr:unit, and I think most reserves have already been imported. Looking through the apartments/stratas they all seem quite accurate and most of them even have names which could actually be quite useful to add. I’ll add building=apartments to the properties with a STR propertytype.
Oops - I’ve assumed that all stratas are apartments. There also seems to be at least a medical center and laundromat that has this property type, so this will need to be manually reviewed. Maybe this should be added separate to the addresses?
From a brief glance it looks ok. My preference is to place a source tag in the changeset tags and avoid including it with each address object.
The property name may still be useful information to bring in, but I’d recommend it be done separate to the address import.
The idea is that once these addresses go into OSM, contributors can move them, alter them, improve them as needed, and if you include a source tag, it may discourage someone from making changes as it may seem like a special immutable object, or if they do make the change, then the source tag is ambiguous as it was partly from the import and partly from the contributors improvements.
I definitely agree with putting the source tag on the changeset - when I started contributing to OSM I was confused if I was allowed to change objects that included this tag. Thanks, I’ll fix this now.
I’m realising now that this dataset includes a lot of information aside from addresses, so I think I will add property names and types separately.