On 18/06/18 20:30, Andrew Harvey wrote:
On 18 June 2018 at 19:21, Dion Moult <d...@thinkmoult.com
<mailto:d...@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
https://www.openstreetmap.org/way/593297556/history#map=19/-33.78072/151.06688&layers=N,
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.
Good Luck.
_______________________________________________
Talk-au mailing list
Talk-au@openstreetmap.org
https://lists.openstreetmap.org/listinfo/talk-au
