Add a few attribute names

[kratzert]

Moving the discussion from #38 to here. Related to #15.

This is my proposed set of global names for a few of the metadata fields that we expect to get in most places.

Do they sound good for you? @simonmoulds @thiagovmdon?

[kratzert]

Continuing the discussion on global names here, linking to this post by @simonmoulds in #38

• Re dates: If they are not provided by the metadata crawl, we would only be able to add this info after we downloaded all the data. We would then also have to update it, if we implement Allow updating already downloaded data with newer time periods #6 at some point. I see how this information can be helpful. That being said, if the data is compiled to a single zarr file, it is trivial to extract the start and end date for each station.
• Re SubSource and Subsource id: At this moment, I see the purpose of this library only to fetch directly from the data provider and not to also crawl data from places like GRDC and so on. In that case, I am not sure if these two fields are needed. Same for Source-ID, isn't that the same as the gauge_id?
• The rest sounds good.

[simonmoulds]

Thanks @kratzert. I agree with you about start and end dates - we can leave those out. In fact they are only helpful if we can use them to constrain the API call to get the data in the first place.

On subsource/subsource_id - I agree with you about the purpose of this package to get data directly from the provider. The only use case that I'm aware of would be for the NRFA data where the EA and SEPA ID is given in the metadata in addition to the NRFA ID (e.g. allowing you to download the archive data from NRFA and more recent data from EA/SEPA). But as that is only one use case I'm happy to leave it out.

source_id is the same as gauge_id - my mistake.

[thiagovmdon]

• Re SubSource and Subsource id: At this moment, I see the purpose of this library only to fetch directly from the data provider and not to also crawl data from places like GRDC and so on. In that case, I am not sure if these two fields are needed. Same for Source-ID, isn't that the same as the gauge_id?

Yes, I agree. Maybe just the "source" is already enough. It will be very useful for countries like Germany, Ireland, Italy, etc.

[kratzert]

Thanks @kratzert. I agree with you about start and end dates - we can leave those out. In fact they are only helpful if we can use them to constrain the API call to get the data in the first place.

On subsource/subsource_id - I agree with you about the purpose of this package to get data directly from the provider. The only use case that I'm aware of would be for the NRFA data where the EA and SEPA ID is given in the metadata in addition to the NRFA ID (e.g. allowing you to download the archive data from NRFA and more recent data from EA/SEPA). But as that is only one use case I'm happy to leave it out.

source_id is the same as gauge_id - my mistake.

Just to be clear: I would not remove those columns from the dataframe that is returned from get_metadata. I am only debating if we need a global name for them that we define in constants.py or not. If this is only for the UK case, I think not having a constant name and instead providing these columns as is is also fine, which facilitates understanding the API documentation and the data we return.