[Imports] Importing addresses in New South Wales, Australia

Tue Jun 26 22:04:32 UTC 2018

Thanks for the response Andrew! Absolutely, sometimes government information is wrong, sometimes we represent it in a better way, etc: this method allows the mapper to make a judgement on a small case by case of exactly what to do.

Probably something I didn't explicitly mention before, but of course as I add address information I plan to do it slowly and post it on talk-au for regular review and local QA.

If there aren't any issues I will create an import plan on the wiki this weekend, along with some data to review.

Dion Moult
-------- Original Message --------
On 24 Jun 2018, 13:54, Andrew Harvey wrote:

> Overall I'm okay with the approach you've outlined.
>
>> and then upload the changeset tagged as `source:import=NSW LPI Web Services`, this will allow anybody who is checking the history to know how this data was gotten.
>
> +1
>
>> There will be no automatic data overwriting or data conflicts.
>
> That's good! I commented on the talk-au list, but to expand on a few points, OSM is all about mapping what's on the ground. There are many cases where the government supplied address points database conflicts with information on the ground. The on the ground scenario is what should prevail in OSM, in my opinion. If anyone wants a government supplied address points database, OpenAddresess does a great job at collating that.
>
> Attached or at https://snag.gy/3jBX5a.jpg you can see a place where I've mapped out an address different to the NSW LPI Basemap, and different to GNAF, instead reflecting what's on the ground.
>
> There's also differing views of how to map addresses in OSM, eg. on an entrance node, on a building, on a residential land parcel, as an unconnected address node. Additionally addresses can be duplicated, eg. shops or offices with the same address.
>
> My point is, I'm not against importing this data, but I think we should pick and choose what makes sense to bring in, and do it in a way that doesn't scare mappers away from deleting or changing that imported address data when they find it doesn't represent what's on the ground.
>
> On 23 June 2018 at 21:15, Dion Moult <dion at thinkmoult.com> wrote:
>
>> Good morning all!
>>
>> The state of New South Wales (where Sydney is) in Australia currently has very minimal address information. I am looking to speed up the mapping of addresses. These can be simply nodes which have addr:street and addr:housenumber tags at a bare minimum, but of course could be better things like part of a building.
>>
>> Currently, apart from local knowledge, addresses can be mapped using the LPI (Land and Property Information) Base Map that we have explicit permission provided by the NSW government to use.
>>
>> https://wiki.openstreetmap.org/wiki/Contributors#Australia
>> https://wiki.openstreetmap.org/wiki/Attribution/New_South_Wales_Government_Data
>>
>> The map provides raster tiles of property boundaries, along with the housenumber of the property. It is a little ambiguous, however, at intersections which street the address belongs to. A mapper is currently able to create a node, interpret the base map background, and then tag it as necessary.
>>
>> However, we have explicit permission to use all of the LPI web services, and the service API allows us to do two things:
>>
>> 1. Ask the question "At this coordinate, what is the address?"
>> 2. Ask the question "What is the coordinate of this address?"
>>
>> Therefore, by roughly choosing coordinates (JOSM has the Edit->Copy Coordinates feature) that we know is within property boundaries (the boundary is shown in the LPI Base Map in JOSM that we always have turned on anyway), we can use a small script that will query the LPI Web Services API, ask those two questions, and then automatically place nodes at the accurate government centroid of the address. We can then review the results manually, and then upload the changeset tagged as `source:import=NSW LPI Web Services`, this will allow anybody who is checking the history to know how this data was gotten. This speeds up the adding and tagging of nodes as the mapper does not need to manually type in data (which is prone to spelling mistakes, and the housenumber in the raster base map is not a high resolution and can be misread), does not need to interpret ambiguous intersections where street is not so clear, and will improve the quality of the node placement as it will be at the actual centroid of the property, not randomly to the mapper's liking.
>>
>> As you can see I am not proposing a huge data import, so there is no actual data to review. Just a semi-automation of the manual address tagging that we do now anyway. However by some interpretation it could be called an "import" as it is semi-automated node placement based off a government API query. It is up to the individual mapper to manually choose coordinates that they want to tag addresses at - so if the mapper sees that addresses have already been tagged, they will simply not query the LPI services for the address at that point. There will be no automatic data overwriting or data conflicts.
>>
>> I have discussed this on the talk-au mailing list, and the responses seem positive. It's quite a conservative proposal, after all. You can see the thread here:
>>
>> https://lists.openstreetmap.org/pipermail/talk-au/2018-June/011937.html
>>
>> The small script along with sample data is shown here:
>>
>> https://gist.github.com/Moult/5821c74fb792b7afa5d758aebea68e40
>>
>> I did a small test of 17 nodes in this changeset to show how it would work. I manually reviewed it and I know this area based off local knowledge.
>>
>> https://www.openstreetmap.org/changeset/59909707
>>
>> Looking forward to your comments!
>>
>> Dion Moult
>>
>> _______________________________________________
>> Imports mailing list
>> Imports at openstreetmap.org
>> https://lists.openstreetmap.org/listinfo/imports
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/imports/attachments/20180626/c86f41be/attachment.html>