<div dir="ltr"><div dir="ltr"><br></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sun, 1 Oct 2023 at 23:16, Yuchen Pei <<a href="mailto:id@ypei.org" target="_blank">id@ypei.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> The preparation and planning is well progressed in my view. There is<br>
> always going to be a long tail of corner cases and I was attempting to<br>
> handle more of these in the code and that never got finished. We<br>
> probably would be better to make a call to accept those corner cases<br>
> and go ahead with the import.<br>
<br>
Thanks for the context. Which of the 7 Stages mentioned in the README<br>
correspond to the corner cases?<br></blockquote><div><br></div><div>It's been a while since I worked on this, but I believe it was the matching of existing OSM addresses to Vicmap, and that matching affects most of the import stages.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">> Are you interested in working on it?<br>
<br>
Absolutely! Thankfully git is decentralised so I don't really need a<br>
gitlab account.</blockquote><div><br></div><div>It would be much easier if you can create one though as otherwise collaboration will be difficult. From what I can see you just need either a phone number OR credit card, so you should be able to create an account without a credit card.</div><div><br></div><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 2 Oct 2023 at 11:45, Yuchen Pei <<a href="mailto:id@ypei.org" target="_blank">id@ypei.org</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Maybe we can go stage by stage. Stage 1 - postal_code is the first stage<br>that has not been completed.<br><br>I built the dist/postalCodeURLs.txt file (see attached) yesterday and it<br>contains 2425 JOSM RemoteControl urls. Shall we go ahead and import<br>them (or a newly generated version)?<br></blockquote><div><br></div><div>I spent some time today reviewing the import again, and this one was ready, so I've done it at <a href="https://www.openstreetmap.org/changeset/142031616">https://www.openstreetmap.org/changeset/142031616</a></div><div><br></div><div>For context, we decided not to include addr:postcode on each address object imported, therefore to ensure we can still capture address postcodes, they are added to the admin_level=9 boundary relations. There were a bunch already mapped but this changeset completed those missing the tag. My prior analysis comparing these boundaries in OSM and the Vicmap address points with postcode found this is a reliable way to ensure we have postcode coverage, except for some edge cases mentioned in the import documentation.</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">BTW, I'd assume the whole pipeline for each stage should be generated at<br>approximately the same time, using the data downloaded at approximately<br>the same time. If that is the case, it would make sense to have a<br>Makefile rule for each stage, that remove all files in the pipeline for<br>that stage and redownload and recompute them. What do you think?<br></blockquote><div><br></div><div>It was built to run the whole process and generate all the outputs from all the import stages together, at this stage I wouldn't be refactoring it.</div><div> </div></div></div></div></div>