David Huard

`xclim` was initially designed to compute "climate indicators", e.g. cooling_degree_days, maximum_annual_precipitation, etc. Since then, we've added bias correction algorithms and some ensemble analysis functionalities, but there has been no effort...

Well, that's a lot more complicated than I anticipated. The custom user indices computation is deeply buried in icclim and there seems to be a lot of data preparation before...

The arguments against this would be: - PWM relies on lmoments3, which is not actively maintained. For this reason, xclim considers it an optional dependency. - Adding this option slightly...

No, the specs mention it is optional.

Is there value in using the SDK automatically generated by https://app.swaggerhub.com/apis/geoprocessing/WPS/1.0-draft.5 ? Export > Client SDK > Python A lot of the boilerplate stuff seems to be handled already, but...

@fmigneault Could you create static response files similar to https://github.com/geopython/OWSLib/pull/748 ? Even better would be a function to automatically fetch static response files from the server, so that when the...

I like the fact that the base classes have a one-to-one correspondence with the schema. I agree that while the schema is still a moving target, it may be tricky...

Agree this is useful, but I thought we would do that in birdy, and keep OWSLib as the low-level client.

While investigating this, I realized that the `Process.json` returns dict, while `WPSRequest.json` returns a string. the former has a `from_json` method, while in the second, `json` is a property with...

Another more serious issue is that `Process._run_process`, the method actually running the process handler, triggers `Process.launch_next_process`, which runs `Service.prepare_process_for_execution`. So individual processes need a reference to the overall service, which...