Figure.meca: Fix beachball offsetting with dict/pandas inputs

[seisman]

Description of proposed changes

Address #2016.

Due to how the GMT API works, the "plot_longitude", "plot_latitude", "event_name" columns must be in string type before passing to the GMT API.

The original code doesn't convert the columns to string type when these parameters are stored in dict/pandas inputs.

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.

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]

Due to how the GMT API works, the "plot_longitude", "plot_latitude", "event_name" columns must be in string type before passing to the GMT API.

Which line is it in https://github.com/GenericMappingTools/gmt/blob/6.4.0/src/seis/pscoupe.c?

[seisman]

Due to how the GMT API works, the "plot_longitude", "plot_latitude", "event_name" columns must be in string type before passing to the GMT API.

Which line is it in GenericMappingTools/gmt@6.4.0/src/seis/pscoupe.c?

https://github.com/GenericMappingTools/gmt/blob/43bccb384663d97ee84f8110e4c50858483ec80f/src/seis/psmeca.c#L836

psmeca and pscoupe read "newX", "newY" and "title" from S->text[row], which is the trailing text after numeric columns.

[weiji14]

Hmm, I was re-reading #1129 again and was gonna say, it's a little surprising that a 2D numpy array passed in with plot_longitude and plot_latitude columns (stored in float) works (since the test_meca_spec_2d_array unit test is passing fine). I guess the GMT C code is smart enough with handling data from virtualfile_from_matrix vs virtualfile_from_vectors.

Nothing to do here, just a random comment.

[seisman]

it's a little surprising that a 2D numpy array passed in with plot_longitude and plot_latitude columns (stored in float) works (since the test_meca_spec_2d_array unit test is passing fine).

That's a good point. I think it shouldn't work. The test_meca_spec_2d_array test passes because both plot_longitude and plot_latitude are 0 (which means no offsetting due to backward compatibility issues).

I'll find some time and see if offsetting using a 2D numpy array works, and if not, will try to find a fix.

[weiji14]

Ah yes, so we should probably update the test to use a non-zero offset. I actually wanted to parse all the user inputs into a pandas.DataFrame (which can hold different dtypes like int, str, float) in #1613 (comment) which meant everything goes through virtualfile_from_vectors, but that was superseded by #1784 that maintained two separate paths going via virtualfile_from_vectors for dict/pd.DataFrame or virtualfile_from_matrix for 2D np.ndarray inputs. Just as an idea 🙂

If this ends up getting too complicated, we can merge in this PR first to fix offsets for dict/pandas inputs, and have a separate one to handle offsets for 2D numpy array inputs.

[seisman]

If this ends up getting too complicated, we can merge in this PR first to fix offsets for dict/pandas inputs, and have a separate one to handle offsets for 2D numpy array inputs.

I prefer to work on it in a separate PR.

[weiji14]

Ok to merge, but don't close #2016 yet since offsets aren't working properly for 2d numpy array inputs.