-
Notifications
You must be signed in to change notification settings - Fork 224
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add an internal function to load GMT remote datasets #2200
Conversation
…ets_earth_relief.py
…d_earth_dataset.py
I'm thinking if we should define a class (or a namedtuple) which stores all metadata of a remote dataset. For example, the object for the earth_relief dataset should be like this: from collections import namedtuple
Dataset = namedtuple(
"Dataset",
[
"name",
"prefix",
"long_name",
"units",
"tiled_resolutions",
"non_tiled_resolutions",
"pixel_only_resolutions",
"gridline_only_resolutions",
"vertical_datum",
"horizontal_datum",
],
)
datasets = {
"earth_relief": Dataset(
name="elevation",
prefix="earth_relief",
long_name="elevation relative to the geoid",
units="meters",
vertical_datum="EMG96",
horizontal_datum="WGS84",
tiled_resolutions=[
"05m",
"04m",
"03m",
"02m",
"01m",
"30s",
"15s",
"03s",
"01s",
],
non_tiled_resolutions=["01d", "30m", "20m", "15m", "10m", "06m"],
pixel_only_resolutions=["15s"],
gridline_only_resolutions=["03s", "01s"],
)
}
print(datasets["earth_relief"]) |
Not opposed to creating a named tuple or a dictionary for this. Creating a class for this seems unnecessarily complicated in my opinion, but I'm open to discussion! Do all of the gridded datasets have the same attribute fields (e.g. long name, units, vertical datum, horizontal datum)? |
I'm not sure about it. Perhaps these fields can be set to None if they make no sense to a dataset. |
I like the idea of using NamedTuple for storing the metadata. The access patterns for metadata could be simplified if the resolution information was linked to the registration and tiling info, for example:
This would allow logic like this:
to be simplified to something like
|
I like it! |
@maxrjones and @seisman Would it be alright to split these changes between two PRs? My thought is the first PR is the creation of |
I feel it's better to have all things done in a single PR, because if we use namedtuple, the current |
Co-authored-by: Dongdong Tian <[email protected]>
Here are some issues that I found when I review the new codes. I think these issues can be addressed in separate PRs after this PR is merged. For the
For the
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks great!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice work! Just noticed one small typo carried over from previous functions, otherwise all good from me.
Co-authored-by: Dongdong Tian <[email protected]> Co-authored-by: Wei Ji <[email protected]>
FYI, I remove the "feature" label and added the "maintenance" label, because this PR adds an internal function that users don't care about. |
…ools#2200) Co-authored-by: Dongdong Tian <[email protected]> Co-authored-by: Wei Ji <[email protected]>
As mentioned in this comment, this adds an internal function that can be used to load a grid file from a remote dataset.
Reminders
make format
andmake check
to make sure the code follows the style guide.doc/api/index.rst
.Slash Commands
You can write slash commands (
/command
) in the first line of a comment to performspecific operations. Supported slash commands are:
/format
: automatically format and lint the code/test-gmt-dev
: run full tests on the latest GMT development version