[talk-au] How to efficiently improve AU address coverage?

[Andrew Harvey]

On Sat, 7 Oct 2023 at 20:40, Yuchen Pei <id at ypei.org> wrote:

> On Tue 2023-10-03 19:51:13 +1100, Warin wrote:
>
> > [... 14 lines elided]
>
> >         OK, what is needed to be done for "Stage 2 - Set unit from
> >         housenumber"?
>
> >     Further testing of the upload script. The changes themselves are
> >     pretty safe. It's using a custom uploader and if something isn't
> >     right it could make a mess. Sure the changeset could be reverted
> >     in the worst case scenario but you end up with more history so
> >     best to avoid this. I'll see if I can find some time to progress
> >     this further.
>
> > Umm 'custom uploader' .. a file compatible with JOSM should be easy
> > enough to create. Then selecting a small area to upload and test would
> > be a simple manual operation, as would uploading the entire change
> > set.
>
> I notice two scripts in the repo with the ability to upload:
>
> ./bin/mr2osc.mjs - converts a MapRoulette geojson to ocs files, and
> upload unless --dryrun is specified
>
> ./bin/upload.sh - upload osmChange files using a python script. I have
> not looked much into this one yet, as it showcases Stage 3.
>
> mr2osc.mjs is used in Stage 2 (replacing street_number=x/y with
> unit_number=x && street_number=y). For example, the Makefile rule
> dist/unitFromNumber.osc is generated using this script. I have generated
> the osc file[1]. However, this file contains 38k nodes, whereas the
> input MR file[2] only has 12k features. So my question is - does anyonw
> know what is the easiest way to see all the changes in this file staged
> on a map, as a sanity check? OTOH I'd assume the file format is some
> standard osm change format.
>

Yes, this is mentioned in the README

> You can visualise the tag changes with bin/mrCoopDiff.js and
www/mrPreview.html at URL

I did this and validated that the changes look as intended.


>
> To Andrew: what specifically are you worried about with the upload
> script, and how can we help with the testing and uploading?
>

I was worried that if the object had changed since the OSC was generated
those changes might have been lost, as well as general error handling in my
custom uploader in case there were rejections. Though reviewing again,
letting JOSM upload the OSC would work.

On Sat, 7 Oct 2023 at 20:48, Yuchen Pei <id at ypei.org> wrote:

> On a second thought, why don't we just generate the osc file with
>
> make dist/unitFromnumber.osc
>
> and apply the osc file manually? Of course that's assuming the file is
> correct. For example, to understand the discrepancy in the number of
> nodes I mentioned above. I also noticed some minor issues with the
> script, like when the number of changes exceeds 10k, it attempts to
> split them multiple files, but they are identical rather than sequential
> parts.


I'll take a look at that.



On Mon, 16 Oct 2023 at 13:23, Yuchen Pei <ycp at gnu.org> wrote:

> My understanding of this Stage is to fix all the discrepancies between
> streetnumber=X/Y in osm and streetnumber=Y;unit=X in the vicmap dataset,
> before Stage 3 - uploading new addresses from the latter.
>

Correct.


>
> I can do the test upload of a small area (say ~100 addresses) and report
> back.
>

Please if you insist, can you just do < 10, no need to do 100.

Once I've reviewed the above and am happy with it I'll do the upload with
the import account as planned.



On Mon, 16 Oct 2023 at 14:10, Graeme Fitzpatrick <graemefitz1 at gmail.com>
wrote:

> Do we need the country, city & post code fields?
>

This is mentioned at
https://gitlab.com/alantgeo/vicmap2osm#inclusion-of-addrsuburb-addrpostcode-and-addrstate
with the conclusion that "After lengthy engagement with the local
community, we opt to omit addr:suburb, addr:postcode, addr:state tags in
the current import." However existing tags won't and shouldn't be touched
as part of this import.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstreetmap.org/pipermail/talk-au/attachments/20231016/16de80af/attachment.htm>