pygmt.sphdistance: data should be an optional parameter if voronoi is used

[maxrjones]

Description of the problem

pygmt.sphdistance will give a GMTInvalidInput: No input data provided error if datais not used. However, the purpose of the voronoi parameter is to allow precomputed Voronoi polygons to be provided instead of raw data. So, the data parameter should be made optional if Voronoi is set.

Full code that generated the error

precompute using gmt's sphtriangulate:

gmt sphtriangulate @gshhs_c.txt -Qv -D > tt.pol

import pygmt
fig = pygmt.Figure()
grid = pygmt.sphdistance(voronoi="tt.pol", region="g", spacing=1, unit="k")

Full error message

     67     """
     68     if data is None and x is None and y is None:
---> 69         raise GMTInvalidInput("No input data provided.")
     70     if data is not None and (x is not None or y is not None or z is not None):
     71         raise GMTInvalidInput("Too much data. Use either data or x and y.")

GMTInvalidInput: No input data provided.

System information

Please paste the output of python -c "import pygmt; pygmt.show_versions()":

pygmt: v0.5.0
gmt: 6.3.0

[willschlitzer]

This issue comes from data_kind in utils.py. I'm don't know how Voronoi polygons would be used in place of data, but would the easiest solution be to replace data with the string passed to voronoi? Otherwise, I would assume we would need to add a sphdistance-specific if statement and pass voronoi to build_arg_string.

[maxrjones]

This issue comes from data_kind in utils.py. I'm don't know how Voronoi polygons would be used in place of data, but would the easiest solution be to replace data with the string passed to voronoi? Otherwise, I would assume we would need to add a sphdistance-specific if statement and pass voronoi to build_arg_string.

If tabular data is provided to sphdistance, the module will first compute the Voronoi polygons which are used to compute distances for each node in a grid. If you want to do this for multiple grids, it can get quite slow. One can skip the compute polygons step (the most time consuming step) by instead providing the polygons to -Q in GMT (voronoi in PyGMT). This is done by calling sphtriangulate before sphdistance to compute the polygons(e.g., example 2 versus example 3 in https://docs.generic-mapping-tools.org/dev/sphdistance.html#examples).

Since this feature is so closely tied to sphtriangulate, it might be worth drafting out the implementation of that module to make sure there are no unforeseen consequences of the bug fix for the voronoi parameter. I think your suggestion would work for passing file names, but eventually it would be nice to have sphtriangulate return an in-memory object which could be passed to sphdistance. I'm not sure whether it would work for that case.