R88676887

[ChocopieKewpie]

Trying to draw a geometry for resolution 8 rhealpix for the entirety of New Zealand, getting issues with this particular cell ID.

R88676887

It tries to return coordinates that are nowhere near New Zealand.
Error: input coordinates (-1.570796, 3.778075) are out of bounds

File ~\AppData\Local\miniconda3\envs\h3panda_exp\Lib\site-packages\rhealpixdggs\dggs.py:2245 in vertices
    result = [self.rdggs.rhealpix(*p, inverse=True) for p in result]

  File ~\AppData\Local\miniconda3\envs\h3panda_exp\Lib\site-packages\rhealpixdggs\dggs.py:2245 in <listcomp>
    result = [self.rdggs.rhealpix(*p, inverse=True) for p in result]

  File ~\AppData\Local\miniconda3\envs\h3panda_exp\Lib\site-packages\rhealpixdggs\dggs.py:453 in rhealpix
    return f(u, v, inverse=inverse)

  File ~\AppData\Local\miniconda3\envs\h3panda_exp\Lib\site-packages\rhealpixdggs\projection_wrapper.py:121 in __call__
    lam, phi = f(u, v, radians=radians, inverse=True)

  File ~\AppData\Local\miniconda3\envs\h3panda_exp\Lib\site-packages\rhealpixdggs\pj_rhealpix.py:507 in f
    lam, phi = array(

TypeError: iteration over a 0-d array

[ChocopieKewpie]

@ndemaio

[rggibb]

Unfortunately this is a recurrence of Issue #6 which wwe thought was resolved by this commit. The commentary for the commit describes the issue and the approach used to resolve it. But also note that the accceptance testing was premised by: 'I can confirm those two cells compute properly now. But only after the source code is updated as described in #10'. So it might be wiorth double checking that the version of code yopu are using has both of those changes.

[ChocopieKewpie]

Hi Robert,

I've been testing out @ndemaio 's attempt to bring the library to python 3.11.
(https://github.com/manaakiwhenua/rhealpixdggs-py/tree/demaion/raster2dggs)

The problem seems to be back, perhaps the solution to #6 is somehow missed?

Attempting to compute cell boundaries for "R88888", which is supposed to be solved by the commit (fd4e75a), throws an error. Makes me think that we are missing something in our attempt to bring the code to 3.11.

Will see what went wrong.

[rggibb]

Ok .. the problem arises (ie prior to the #6 solution) because at the point in the code where the projection code is called to determine the lat/long it tests the unprojected coord to test whether to use the the Colignon or the Equal Area Lambert cylindrical projection. For any coord on the boundary between the two projections, rounding errors can result in the wrong projection being chosen, so the solution, was to add the CellID to the calling parameters, so that the projection test can be based on the CellID instead of coords. The specific code changes are tracked in tne commit I mention in my previous comment, and it should be fairly quickly evident if the code you were using has got that change in it or not. Hasppy to have a chat if necessary