Open tylerjereddy opened 4 years ago
Furthermore, grid_center_point()
is never called, so the algorithm clearly still needs a lot of work, since grid center points are central to the steps.
I should probably feel free to draft a predetermine_grid()
function that starts to build up the proper workflow, using the above functions alongside some of the other utility functions I've written.
I'll likely want the function to produce a data structure indicating which grid cell center points are inside/outside the spherical polygon input.
That said, I think the current library code has mostly focused on producing the grid levels, which DOES require dispatching the spherical polygon edges into cells at an early stage.
I should break this issue down in to more tractable sub-issues.
Careful examination of the current implementation suggests at least two obvious issues:
determine_first_traversal_point()
function is never called, so all the work that currently happens with arc intersection assessment is not properly "anchored"/seeded with a first center point of known position inside/outside of the spherical polygon. At the moment, I just kind of check all grid cells for arc intersection, but the arc intersection doesn't actually guarantee that the spherical polygon is contained inside the grid cell.inclusion_property()
function is never called, so of course it is a bit premature to be plotting which grid cells contain the spherical polygon and which don't.