Fix bug with different band dtype from load_tile_map by casting to uint8

[weiji14]

Description of proposed changes

The band list [0, 1, 2] was being converted to int32 on Windows + NumPy 1.24, but is int64 on other platforms. Casting the band coordinate explicitly to uint8 for consistency.

Patches bug in #2125 as reported in #2125 (comment)

Reminders

• Run make format and make check to make sure the code follows the style guide.
• Add tests for new features or tests that would have caught the bug that you're fixing.
• Add new public functions/methods/classes to doc/api/index.rst.
• Write detailed docstrings for all functions/methods.
• If wrapping a new module, open a 'Wrap new GMT module' issue and submit reasonably-sized PRs.
• If adding new functionality, add an example to docstrings or tutorials.
• Use underscores (not hyphens) in names of Python files and directories.

Slash Commands

You can write slash commands (/command) in the first line of a comment to perform
specific operations. Supported slash commands are:

• /format: automatically format and lint the code
• /test-gmt-dev: run full tests on the latest GMT development version

[weiji14]

From #2125 (comment), I remembered why I didn't print out the full y and x coordinates here. It's because that would make the docstring too long (>79 characters), so I added ... which is supported by https://docs.python.org/3/library/doctest.html#doctest.ELLIPSIS.

-      * y        (y) float64 1.663e+05 1.663e+05 1.663e+05 ... 1.272e+05 ...
-      * x        (x) float64 1.153e+07 1.153e+07 1.153e+07 ... 1.158e+07 ...
+      * y        (y) float64 1.663e+05 1.663e+05 1.663e+05 ... 1.272e+05 1.272e+05
+      * x        (x) float64 1.153e+07 1.153e+07 1.153e+07 ... 1.158e+07 1.158e+07

[seisman]

Perhaps you need to add the # doctest: +ELLIPSIS directive after line 103.

[weiji14]

Perhaps you need to add the # doctest: +ELLIPSIS directive after line 103.

I thought so too, but using ... by itself seems to work? Like, the tests still all pass. I think it was just the int32/int64 diff that was the problem, but pytest still reports the full diff.

Anyways, I've changed the bounding box region in ea9e7dc and the y/x coordinates fit under 79 characters now, so doesn't really matter.

[weiji14]

All the tests pass now, but I just noticed at https://github.com/GenericMappingTools/pygmt/actions/runs/4327743401/jobs/7556724608#step:11:875 that the doctest is taking 6.76 seconds (the 2nd slowest test). Should we update the region and/or set a zoom level to return a smaller tile instead?

[seisman]

All the tests pass now, but I just noticed at https://github.com/GenericMappingTools/pygmt/actions/runs/4327743401/jobs/7556724608#step:11:875 that the doctest is taking 6.76 seconds (the 2nd slowest test). Should we update the region and/or set a zoom level to return a smaller tile instead?

Yes, we need a smaller tile.

[weiji14]

All the tests pass now, but I just noticed at https://github.com/GenericMappingTools/pygmt/actions/runs/4327743401/jobs/7556724608#step:11:875 that the doctest is taking 6.76 seconds (the 2nd slowest test). Should we update the region and/or set a zoom level to return a smaller tile instead?

Yes, we need a smaller tile.

Ok, I've modified the bounding box region and set things to zoom level 1 in ea9e7dc, which should return only 2 tiles of size 256x256. The doctest now takes 0.60 seconds according to https://github.com/GenericMappingTools/pygmt/actions/runs/4330035373/jobs/7560981253#step:11:1116