Error when using `exact_extract` with any extra arguments to statistics
Closed this issue · 6 comments
When I run exact_extract
with any statistic having extra arguments (e.g. "mean(coverage_weight=area_spherical_m2"), I get an error. With a "plain" statistic (e.g. "mean") there is no problem. This is an example of such an error:
File "C:\Tools\mambaforge\envs\pysnippets\Lib\site-packages\exactextract\exact_extract.py", line 169, in prep_ops
ops += prepare_operations([stat], values, weights)
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
RuntimeError: Unexpected argument(s) to stat: mean
The problem must be related to my system/installation, as I can reproduce it by running an extract from the exactextract test suite, which runs fine on CI.
I'm working on windows with conda. To try to avoid possible side effects from dependencies, I created a new conda environment and just installed pip and the exactextract pip package:
# Name Version Build Channel
bzip2 1.0.8 hcfcfb64_5 conda-forge
ca-certificates 2024.2.2 h56e8100_0 conda-forge
exactextract 0.2.0.dev0 pypi_0 pypi
libexpat 2.6.2 h63175ca_0 conda-forge
libffi 3.4.2 h8ffe710_5 conda-forge
libsqlite 3.45.3 hcfcfb64_0 conda-forge
libzlib 1.2.13 hcfcfb64_5 conda-forge
openssl 3.3.0 hcfcfb64_0 conda-forge
pip 24.0 pyhd8ed1ab_0 conda-forge
python 3.12.3 h2628c8c_0_cpython conda-forge
setuptools 69.5.1 pyhd8ed1ab_0 conda-forge
tk 8.6.13 h5226925_1 conda-forge
tzdata 2024a h0c530f3_0 conda-forge
ucrt 10.0.22621.0 h57928b3_0 conda-forge
vc 14.3 hcf57466_18 conda-forge
vc14_runtime 14.38.33130 h82b7239_18 conda-forge
vs2015_runtime 14.38.33130 hcb4865c_18 conda-forge
wheel 0.43.0 pyhd8ed1ab_1 conda-forge
xz 5.2.6 h8d14728_0 conda-forge
An easy way to reproduce in my case is to run the following extract from one of the tests in the exactextract test suite:
import numpy as np
from exactextract import exact_extract
from exactextract.feature import JSONFeatureSource
from exactextract.raster import NumPyRasterSource
def make_rect(xmin, ymin, xmax, ymax, id=None, properties=None):
f = {
"type": "Feature",
"geometry": {
"type": "Polygon",
"coordinates": [
[[xmin, ymin], [xmax, ymin], [xmax, ymax], [xmin, ymax], [xmin, ymin]]
],
},
}
if id is not None:
f["id"] = id
if properties is not None:
f["properties"] = properties
return f
rast = NumPyRasterSource(np.arange(1, 10, dtype=np.int32).reshape(3, 3))
square = JSONFeatureSource(make_rect(0.5, 0.5, 2.5, 2.5))
result = exact_extract(
rast,
square,
[
"m1=mean",
"m2=mean(coverage_weight=area_spherical_m2)",
"c1=coverage",
"c2=coverage(coverage_weight=area_spherical_m2)",
"c3=coverage(coverage_weight=area_spherical_km2)",
"c4=coverage(coverage_weight=area_cartesian)",
],
strategy="feature-sequential",
)[0]["properties"]
The package on PyPI isn't up to date with GitHub. I'll push an updated snapshot to Test PyPI at https://test.pypi.org/project/exactextract/. The dependencies are fairly minimal if you want to build the library from source.
That version indeed works fine. Thanks!
Maybe better to push the version as well to regular/production pypi, e.g. as an alpha version, as the version available there now is ~broken?
I don't know about "broken", but it's nearly 2 months old so it doesn't have this feature.
I'm trying to figure out the right frequency to push development releases to regular PyPI. Any info on best practices would be welcome.
I don't know about "broken", but it's nearly 2 months old so it doesn't have this feature.
Ah, OK, sorry. I misinterpreted the error message as well as the timeline of the pip package vs. when the new feature was introduced. I should have looked better :-(...
I'm trying to figure out the right frequency to push development releases to regular PyPI. Any info on best practices would be welcome.
I wouldn't call it best practices, but based on the projects I'm involved in (not that many), development releases (or rather alpha releases, never encountered development releases) are quite rare and there is no specific frequency. They are only used if there is a need for some broader testing exposure than unit tests can offer. Or, if there is a specific wish/need for someone to get an earlier version (either for broader testing or just to have it earlier), but that's just as rare.
Sometimes there are beta releases or release candidates e.g. a few weeks before a feature release, but even those aren't very common.
I think exactextract is now just a bit in a special situation as there isn't a "stable" python release yet?
I think exactextract is now just a bit in a special situation as there isn't a "stable" python release yet?
Yes. Hopefully not much longer, I just need to convince myself that the current API is suitable.