Outdated script utils/update_from_upstream.sh

[sesam]

I'm checking what's needed to sync up to latest DGGRID. The git submodule is currently checked at c17e9f14581b2e3635e89d618fba6cf3530b20d8 so probably 8.1, but the script seems to not match. Does anyone have an updated shell script or is this a "PRs welcome" situation? :)

[am2222]

Hi @sesam thanks for the message!

So I tried to build version 8 of the dggrid but was not able to wrap it up! If you have been able to build it I am happy to review your pr and merge it here.
Also a side note that I have been using DggridR's version and since they don't have a plan to upgrade to version 8.1b we might end up using the source directly!

Thanks!

[sesam]

Oh, now I'm both more and less confused 😅. I found the git commit that is in submodules/DGGR that point to the 8.1 version of sahrk/DGGR and it looks like the script I talk about is copied from r-barnes/dggridR so if the r-barnes repo uses the 8.1 code then it's their script that is outdated -- or on the other hand maybe the submodules/DGGR git commit hash is not pointing to the version actually used.

So now first; what version of sahrk/DGGR is used by webDggrid?

Asking as I'm looking to understand some trouble I have when running e.g.

// list nCells values for n=0 and up...
new Array(35).fill(0).map((_,n) => [n,webdggrid.nCells(n)])
// (too high n causes a crash - browser environment vs node 20 has trouble with different n)
[
  [ 0, 12 ],
  [ 1, 42 ],
  [ 2, 162 ],
  [ 3, 642 ],
  [ 4, 2562 ],
  [ 5, 0 ],
  [ 6, 17179869192 ],
  [ 7, 25937601902 ],
  [ 8, 25937601902 ], // same as 7?
  [ 9, 0 ],
  [ 10, 0 ],
  [ 11, 0 ],
  [ 12, 17179869192 ], // same as 6?
  [ 13, 12 ],
  [ 14, 12 ],
  [ 15, 7163384661135025000 ], // browser: 0
  [ 16, 0 ],
  [ 17, 0 ],
  [ 18, 0 ],
  [ 19, 12 ],
  [ 20, 0 ],
  [ 21, 0 ],
  [ 22, 0 ],
  [ 23, 0 ],
  [ 24, 0 ],
  [ 25, 0 ],
  [ 26, 0 ],
  [ 27, 653831461424580 ], // browser: 4470442479865284
  [ 28, 16784 ],
  [ 29, 0 ],
  [ 30, 0 ],
  [ 31, 0 ],
  [ 32, 0 ],
  [ 33, 0 ],
  [ 34, 0 ]
]

What I'm really looking for is a chance to go from wgs84 to approximate 2m accuracy hexagon cell ids.

[am2222]

Hi @sesam
Sorry for confusing! So the submodule is something I tried to add to use version 8.1b and I was not able to finish it. So you can ignore it.

I use dggridR's version and the source is in the src-cpp folder. However, the version I am using is from 2023 and I have seen that they have updated their code to address some bugs recently. These bug fixes are not in the current source code.

About the issue you mentioned, I think it is an issue on mac m1 cpus. Are you using a mac?

I think the proper way to approach this is to build 8.1b with emcc. If we can build the latest version with it we can quickly change our source from dggridR to the main repository.

[sesam]

Ok! Yes, I ran on a M1 mac on node v20 (binary for Mach-O 64-bit executable arm6) as well as in Chrome, and both seem to not process nCells correctly, but I'm also unsure how nCells is expected to work. Probably a good candidate for unit tests!
I've started some experiments with the sahrk/dggrID executable to see what the correct nCell numbers should be.

[am2222]

Hi @sesam
Thanks! So on mac M1 models there is a bug with numbers which is fixed in dggrid 8.1b and also in dggridR but it is not fixed in this wasm version