Server side functions and selections on same url constraint?

I ran into this scenario. Here is the setup (from pydap)

# EXTRACT single time snapshot of SST data
$ from import pydap.client import url
$ url = "http://test.opendap.org/opendap/hyrax/data/nc/sst.mnmean.nc.gz?lat[0:1:88],lon[0:1:179],time[0],sst[0][0:1:88][0:1:179]"
$ dataset = open_url(url) # DAP2 constraint
$ dataset['sst'].shape
>>> (1, 89, 180)

Now I want to further select a spatial region bounded by the range:
\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\;\; \left( 206 \leq Lon \leq 210\right) \times \left( 56 \leq Lat \leq 62\right)
To accomplish it I do:

$ newdataset = dataset.functions.geogrid('sst', 62,206,56,210)
$ newdataset.shape
>>> (1857, 4, 3)

The resulting time dimensions matches that of the original dataset, as if there was no initial Constraint Expression (as defined in URL above).

Q1. Will geogrid() by default disregard any other previous selection?

Q2. Can one combine a Constraint Expression that looks like this:

                 proj_1,proj_2&ServerSideFunction(args)

For example,

http://test.opendap.org/opendap/hyrax/data/nc/sst.mnmean.nc.gz?lat[0:1:88],lon[0:1:179],time[0],sst[0][0:1:88][0:1:179]&geogrid('sst', 62,206,56,210)"

It would be great if something like this worked: a SSF that is applied to the dataset resulting from the Constraint Expression.

I think Q2 can be easily addressed from the client side (e.g. pydap), but I would like to know if there is an elegant way to accomplish this from the server side.

Thanks!

Q1. Will geogrid() by default disregard any other previous selection?

In your case, and in most cases, yes. OPeNDAP is fundamentally a REST API, so when the server evaluates the request using geogrid(), it has no information about the previous request.

It is possible for servers to maintain context (aka ‘state’) across calls, and our servers do that for username & password authentication when that is required, but the servers don’t do that for data access.

1 Like

Yes, you can combine server side functions and ‘projection’ constraints. However, the result may not be what you are expecting. For a function like geogrid(), the return value of the function becomes the dataset and the projection constraints are applied to that. For DAP4 it is easier to see that two are really independent since they are passed in using different keys in the query string of the URL.

Thanks you jhrg! This answers my questions.

I think it is important for client APIs to be aware of what the default behavior of these server side functions are. Knowledge of these default behaviors will allow developers on the client side to

a) Raise an appropriate Error or Warning when a user attempts to subset the way I proposed originally, and

b) Develop a feature that allows the client API to understand and implement such a request, with a caveat that it will raise a Warning explaining that such request

  1. Will only work with a specific server (e.g. Hyrax for geogrid).

  2. Will in turn request two separate constraints sequentially, and so there will likely not be any performance gain from the user writing such requests sequentially.

For many functions – it’s a convention - that calling the function with no arguments returns a help string that points back to more detailed documentation. In addition, docs.opendap.org has a page about functions that we ship with Hyrax.

1 Like