[talk-au] Mapping houses and addresses in Sydney
andrew.harvey4 at gmail.com
Mon Jun 18 10:30:25 UTC 2018
On 18 June 2018 at 19:21, Dion Moult <dion at thinkmoult.com> wrote:
> Thanks Andrew for your reply!
> 1. Thanks for the link to the import guidelines. My responses to the
> import guidelines below:
First up I think any changesets that import addresses in this way should
have an extra changeset tag so if we need to we can identify which
changesets did the import (so more than just source=LPI NSW Base Map).
Something like import=NSW Address Points or something.
I'm not sure about separating the address with a ";" like
could they not be two separate points? If it's a duplex, then I'd do it as
a single building with addr:housenumber=11, then if you want two nodes
inside the building for 11A and 11B.
While I don't think there's anything wrong with 2/18 as a first pass, eg
https://www.openstreetmap.org/node/5667899003, I think it's better to use
1. I am aware that big automatic updates can cause problems. I will only
> import addr:housenumber and addr:street and a single node.
What are you planning on doing where the address in already in OSM? I think
in this case we should just not import that point and leave the existing
> 2. Yes, you are absolutely right that this is not a huge automatic import
> - it relies on a human choosing what addresses to add and a human
> submitting it as a change. All it does it automate the address lookup and
> make sure that the node is neatly positioned at the correct location.
> 3. It looks like you're grabbing their entire dataset. That would be the
> alternative approach, doing a data dump, then importing that dump. This can
> import a lot more addresses, but is also much more complex. Is it worth
> pursuing? What do you reckon?
Oh I'm not suggesting that. It makes sense for the OpenAddresses project to
use a complete extract, but as you might have seen in the openaddresses
ticket there's a lot of problems trying to dump the data, so your approach
of doing it bit by bit should work much better for an OSM import.
> 4. It seems odd that they would provide an API but would prevent anything
> from using it.
> 5. Looks like they are doing the big data import. See 3.
Not quite, they did it using the approach you've described, broken it down
into pices and manually imported everything.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-au