[talk-au] Mapping houses and addresses in Sydney
61sundowner at gmail.com
Mon Jun 18 10:56:37 UTC 2018
On 18/06/18 20:30, Andrew Harvey wrote:
> On 18 June 2018 at 19:21, Dion Moult <dion at thinkmoult.com
> <mailto: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.
source:import=LPI API via ?? something like that?
> 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.
I have had separate buildings for A and B - share a common wall. In some
instances I have 11 then 11A .. but no B.
> 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 addr:unit=2 addr:housenumber=18.
> 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 OSM addresses.
Depends .. I have come across addresses that were out of sequence.
Contacted the still active mapper (moved to Germany) and had not
response .. after some months I have simple deleted them.
So it is worth checking that the new data is is not 'better' than the
present OSM data.
> 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.
It might be good to do one section and let people have a look at it?
I do think you'll find it repetitive. Maybe take a break and map
something else for a while.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Talk-au