migrate from dggridr to h3 hexagons

[7yl4r]

Several of us have had issues getting dggridr to work properly. The DESCRIPTION file currently has this set up to build it from C source code. We could try taking a different approach.

From Pieter:

I also had some issues with dggridr on a new machine, and I ended up using st_make_grid() with an equal area projection (EPSG:3410)

We could also try using the H3 grid.

[7yl4r]

Revisiting this. Here are ways forward I see:

1. work with the dggridr maintainer to make the CRAN version work for us
2. replace dggridr usage here with
   1. h3 grid
   2. st_make_grid

2.2 is probably easiest. 1 would be a good service for the community in general. 2.1 is the most forward-looking.

[7yl4r]

I have been working with a tool to display h3 grid data. It is a simple html+js+mapboxgl project that allows uploading of a .json file that contains pre-computed values for h3 hex grid indexes.

• https://github.com/7yl4r/h3-grid-viewer

If we can compute the indicies for each h3 grid then we can export a .json file compatible with this tool.

[7yl4r]

The H3 viewer code is ready. @bbest : is converting the current code to calculate over h3 indices instead of dggriddr hexes easy?

[bbest]

Hey @7yl4r,

Your grid viewer looks pretty cool! The issue I was having with the H3 was with hexagons that cross the dateline (ie with vertices a little greater than 0 and a little less than 180 longitude).

It's interesting how your viewer seems to alternate between the two:

• zoomed out: only dateline hexagons
  

• zoomed in outside dateline: non-dateline hexagons
  

I made a little fix here for the H3 polygons with this little function fix_dateline(), but that's a different approach from using the existing H3 hexagons via JavaScript.

For another approach building the hexagons, something like:

• make_hex_res()
• fix_dateline()

[7yl4r]

Yeah, there is some javascript in the app that does something related to the dateline issue but obviously it isn't perfect.

For obisindicators we don't need to display the hexagons though, I just want to calculate es50 for each h3 hex.

[7yl4r]

Working to use H3 on the H3 branch.

[bbest]

Next step: split anti-meridonal hexagons into two with same h3 ID and still simple POLYGON not MULTIPOLYGON, as is done by sf::st_wrap_dateline().

See also:

• Possible bug in reprojection of vector data (Natural Earth coastline to Robinson projection) · Issue #1372 · r-spatial/sf

[MathewBiddle]

Please please please remove the dependency on dggridr. The installation process is a nightmare with that package.

[7yl4r]

I feel like there is some projection setting that will handle this hexagon wrapping issue that we are having on the h3 branch. Some discussion on this issue seems relevant. I am going to try playing with some of these sf features tomorrow.

[7yl4r]

It works!!!

I don't want to close this quite yet though because the builds are failing to build from the DESCRIPTION.

• local::.: Can't install dependency h3
• h3: Can't find package called h3.

The remote is pointing to the correct repo though... so I don't know what the problem is.

Is installation and function of v0.1.0+ working on anyone's machine?

[7yl4r]

I was able to do a fresh install without seeing the "can't install dependency h3" issue.

I did run into some other complications as documented in 819f845, but none related to the installation issue in the github action.

[MathewBiddle]

I'll give this a try sometime soon 🤞

[bbest]

I wonder if the issue here has to do with the mismatch between the repo name h3-r and the package name h3:

obisindicators/DESCRIPTION

Lines 34 to 45 in 06e5d2f

	Imports:
	dplyr,
	ggplot2,
	gsl,
	h3,
	rnaturalearth,
	rnaturalearthdata,
	sf,
	viridis
	Remotes:
	crazycapivara/h3-r
	Config/testthat/edition: 3

[7yl4r]

I wonder if the issue here has to do with the mismatch between the repo name h3-r and the package name h3:

obisindicators/DESCRIPTION

Lines 34 to 45 in 06e5d2f

	Imports:
	dplyr,
	ggplot2,
	gsl,
	h3,
	rnaturalearth,
	rnaturalearthdata,
	sf,
	viridis
	Remotes:
	crazycapivara/h3-r
	Config/testthat/edition: 3

That's the best theory so far. We may need to report this to the github action.

I tried another syntax for the DESCRIPTION file and now there is a different error:

 Error: Error: <callr_remote_error: Cannot install packages:
  * deps::.: Can't install dependency github::crazycapivara/h3-r
  * pkgdown: dependencies must be TRUE, FALSE, NA or a list of dependency types>

[MathewBiddle]

h3 grid calculations take forever. I wonder if h3o is a package to explore to speed up the process?

https://josiahparry.com/projects/pkgs/h3o.html

I don't think it would change a lot of the obisindicators package...