I found the process was only using Vicmap data from last year, so I've updated that. The URL it's using should be serving new data every week but I'm not sure it was not happening previously. So we'll need to monitor this if the import is delayed further.
On Sat, 7 Oct 2023 at 20:48, Yuchen Pei <i...@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 took another look into this, the code wasn't completed. The osc file generated may include ways but doesn't include all the nodes for those ways so it can't be uploaded from JOSM (I tried and it failed). One solution would be to have the osc file generated to include them. Correct it attempts to split the changes to meet the changeset element limit, but this implementation was not completed, so while two files are generated they don't have the limit applied. It looks like JOSM may be able to do the splitting for us though, if we use JOSM to upload rather than my code directly. On Mon, 16 Oct 2023 at 22:30, Yuchen Pei <y...@gnu.org> wrote: > And there's always tried and true email based code review which we can > do say in this mailing list, which both of we are already using. The > person (say me) who wants to send a pull/merge request can create > patches using git format-patch[1]. I can then send the patch to this > mailing list, and then the person who reviews (say you) can comment > inline, and I can respond to the comments inline, just like normal > emails. After some back and forth once you are happy with the patches > you can apply them to your repo with git am[2]. > > [1] https://git-scm.com/docs/git-format-patch > [2] https://git-scm.com/docs/git-am > > I got a few commits so far in my fork[3], and if you are open to doing > it in this mailing list, I'll prepare some patches and send them here. > I'm not a fan, and besides this mailing list is for mappers so it's not the place for detailed code review. I'd rather if you can submit a Merge Request on GitLab (or Pull Request on GitHub). On Mon, 16 Oct 2023 at 20:53, Yuchen Pei <y...@gnu.org> wrote: > On Mon 2023-10-16 15:35:13 +1100, Andrew Harvey wrote: > > > On Mon, 16 Oct 2023 at 15:16, Yuchen Pei <y...@gnu.org> wrote: > > >> On Mon 2023-10-16 14:51:00 +1100, Andrew Harvey wrote: > > >> > On Sat, 7 Oct 2023 at 20:40, Yuchen Pei <i...@ypei.org> wrote: > > >> > [... 38 lines elided] > > >> > 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 > > >> What is URL? > > > > Ah yeah I put URL as a placeholder I was going to replace. At the moment > > you can only view that locally within the repository as I haven't hosted > > it. > > Got it, thanks. Somehow when I open www/mrPreview.html I only see a map, > but not the addresses in the changes in Stage 2. I took a look at the > content of the www/mrPreview.html, and I don't see references to any of > the geojson or osc files. > > > [... 8 lines elided] > > >> > 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. > > >> Why? > > > > For testing, I feel it should be a number that we can manually work with. > > After your testing either we need to then wait for the planet export to > > catch up with your changes, or potentially have a conflict to deal with > in > > JOSM (or maybe JOSM would handle it, I'm not sure). > > OK. > > >> > Once I've reviewed the above and am happy with it I'll do the upload > >> > with the import account as planned. > > >> Even though you asked whether I would like to help and I said yes, the > >> communications so far have give me the impression that you want to work > >> on it solo > > > > Not the case, I think it's great that you've taken interest in the > import, > > if we can work together to get it done that would be ideal. > > Cool thanks. What do you think people can do to help speed up the > project? It is still not clear to me. > > >> which is less of a problem if there's a clear timeframe to > >> complete it. After all it was started in 2021 and stalled, and this is a > >> community project to improve the VIC address coverage for everyone. To > >> get it done I will continue working on it as I have been in the past few > >> weeks. If Stage 2 is done I will push for progress in Stage 3, and so > >> on. > > > > It's a balance, I don't want to hold things up, at the same time we don't > > want to mess up such a large import by rushing. > > Understood - I agree that we gotta do it right. > > > [... 2 lines elided] > > Best, > Yuchen > > -- > Timezone: UTC+11 > PGP Key: 47F9 D050 1E11 8879 9040 4941 2126 7E93 EF86 DFD0 > <https://ypei.org/assets/ypei-pubkey.txt> >
_______________________________________________ Talk-au mailing list Talk-au@openstreetmap.org https://lists.openstreetmap.org/listinfo/talk-au
