Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Failure to compute cell boundary in geographic coordinates #6

Open
aaime opened this issue Sep 2, 2020 · 4 comments
Open

Failure to compute cell boundary in geographic coordinates #6

aaime opened this issue Sep 2, 2020 · 4 comments
Assignees
Labels
bug Something isn't working

Comments

@aaime
Copy link

aaime commented Sep 2, 2020

The following simple test script fails with an error:

from rhealpixdggs import dggs, ellipsoids
from rhealpixdggs.ellipsoids import Ellipsoid
from rhealpixdggs.dggs import RHEALPixDGGS, Cell

WGS84_TB16 = Ellipsoid(a=6378137.0, b=6356752.314140356, e=0.0578063088401, f=0.003352810681182, lon_0=-131.25)
dggs = RHEALPixDGGS(ellipsoid=WGS84_TB16, north_square=0, south_square=0, N_side=3)
cell = dggs.cell(('Q', 6, 6, 6, 6, 6))
print(*cell.vertices(False))

resulting in:

Error: input coordinates (-1.570796, 0.791862) are out of bounds
Traceback (most recent call last):
  File "/tmp/test.py", line 8, in <module>
    print(*cell.vertices(False))
  File "/home/aaime/.local/lib/python3.6/site-packages/rhealpixdggs/dggs.py", line 2245, in vertices
    result = [self.rdggs.rhealpix(*p, inverse=True) for p in result]
  File "/home/aaime/.local/lib/python3.6/site-packages/rhealpixdggs/dggs.py", line 2245, in <listcomp>
    result = [self.rdggs.rhealpix(*p, inverse=True) for p in result]
  File "/home/aaime/.local/lib/python3.6/site-packages/rhealpixdggs/dggs.py", line 453, in rhealpix
    return f(u, v, inverse=inverse)
  File "/home/aaime/.local/lib/python3.6/site-packages/rhealpixdggs/projection_wrapper.py", line 121, in __call__
    lam, phi = f(u, v, radians=radians, inverse=True)
  File "/home/aaime/.local/lib/python3.6/site-packages/rhealpixdggs/pj_rhealpix.py", line 509, in f
    x, y, e=e, north_square=north_square, south_square=south_square
TypeError: iteration over a 0-d array

Hope I have the right version of rHEALPix, installed it using:

sudo pip3 install --upgrade rhealpixdggs

and then run the test script using python3.

@aaime
Copy link
Author

aaime commented Sep 2, 2020

The same issue happens with other cells, e.g., "R88888"

@rggibb
Copy link
Collaborator

rggibb commented Sep 3, 2020

I'll chase this, it seems to work at higher resolutions and then bails when the fifth level is reached. This may be related to something that Matt mentioned that his team fixed in the GA's version, so I'll check what they did in their repo.

@geofizzydrink
Copy link

Yes. This is the same issue identified in AusPIX. It appears to be due to a projection issue at the boundary between the equatorial and polar cells (where the equal area projection switches). I've tested this at multiple resolutions (down to level 15) and the error occurs only in the northern most vertices (for the south polar cell) and the southern most vertices (for the north polar cell).

The work around for this bug that was implemented by GA is as follows:

  1. wrap the "cell.vertices" function in a "try/except" statement to catch the error.
  2. if the exception is triggered
    a) for the South Polar Cell:
    a.1) get the immediate north neighbour cell and get its southernmost vertices.
    a.2) replace the coordinates of the northernmost vertices of the cell that triggered the error with the vertex coordinates obtained from a.1).
    b) for the North Polar Cell:
    b.1) get the immediate south neighbour cell and get its northernmost vertices.
    b.2) replace the coordinates of the southernmost vertices of the cell that triggered the error with the vertex coordinates obtained from b.1).

NB: This is not a proper fix for the issue - merely a work around.

A proper fix will require an examination of the polar projection algorithm used by rHealPIX and determine why it is getting an "out of bounds" error when converting from planar (cube face) coordinates to global (lon/lat) coordinates. It could be a boundary computation issue, which might be solved by extending the projection boundary slightly. But the work hasn't been done yet.

Cheers,
Matt.

@rggibb rggibb self-assigned this Sep 8, 2020
rggibb added a commit that referenced this issue Sep 8, 2020
Occasionally a computed cell vertex would be up to 1e15 outside the cell. This was allowed for by expanding the rhealpix/healpix boundary vertices by (eps = 1e15) in the in_rhealpix_image test. But the test for applying combine_triangles in rhealpix didnt accomodate a +-eps dither in coordinate values. combine_triangles() cannot know the origin of the coordinate it is testing, but cell.vertices() & cell.boundary() already know the region of the cell that owns the coordinates. So adding cell.region() as an optional argument to the rheal[ix transformation functions, allows vertices() & boundaries() to force the combine_triangles() behaviour to follow the cell, not the individual coordinates. This has been tested for cells with all 0s, 1s, 2s, 6s, 7s, or 8s on faces OPQR. ie equatorial cells with a northern or southern border on the edge of the equatorial region.
rggibb added a commit that referenced this issue Sep 8, 2020
@aaime
Copy link
Author

aaime commented Sep 17, 2020

I can confirm those two cells compute properly now. But only after the source code is updated as described in #10

@rggibb rggibb mentioned this issue Nov 24, 2023
@alpha-beta-soup alpha-beta-soup added the bug Something isn't working label Dec 18, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

4 participants