Comments (2)
I never addressed this properly, because I was extremely busy and unhappy with personal matters; and it's quite subtle.
The short answer is: Yes, of course, if we change the ordering of the y
dimension of the coordinate system, then it is necessary that we change the order of the columns in the matrix and, since grid_coordinates
/grid_cells
returns the basis of the columns it must change accordingly as well.
Do people expect this? I don't know. I thought it was obvious. Quite obviously, I'm wrong.
The code you are referring to is hideous because you are not following the convention that y
is ascending in the layoutmatrix. And yes, it seems like sparse
does not help you too much to compensate that.
What you could do, for example, is to switch to this convention early on, ie. use
availabilities = xr.DataArray(
np.array(availabilities),
coords=[
buses,
y[::-1], # GDAL uses a north to south latitude
x
],
dims=['bus', 'y', 'x']
).isel(y=slice(None, None, -1))
Or embrace it even earlier just after calling extractMatrix ie use
return gk.raster.extractMatrix(availability)[::-1] # GDAL uses a north to south latitude
Or just don't use sparse
and stick with the final matrix structure as csr by following my initial advise #20 (comment) .
I don't understand the possible solution, you mention. The index order is fixed now as ascending y and x, we do not need any sort operations for this. I do not think it is less good than the other possible convention. I can come up with pros and cons for each, if we want to compile a list.
There will always be different conventions, it is important to communicate them clearly, but ultimately it is up to the users to follow them!
And I would even go a bit further and say that any mechanisms that try to predict and compensate for user errors automatically will on the long run lead to further and then less obvious mistakes.
from atlite.
A few comments:
Do people expect this? I don't know. I thought it was obvious. Quite obviously, I'm wrong.
I doubt it. One would have to care about the index order in cutouts, know that it changes and know that the functions are internally designed that way (no doc string mentioning this).
What you could do, for example, is to switch to this convention early on, ie. use
...
Thanks for the advice. Since the changes affect more than just this piece it is insufficient.
I prefer to keep the meta data and data close together with sparse
, making the conversion step more obvious via reindex_like
suits my style more than multiple list reversals with [::-1]
.
There will always be different conventions, it is important to communicate them clearly, but ultimately it is up to the users to follow them!
Of course. But we never exposed or documented them.
And I would even go a bit further and say that any mechanisms that try to predict and compensate for user errors automatically will on the long run lead to further and then less obvious mistakes.
I fully agree!
from atlite.
Related Issues (20)
- pad_extent leads to rasterio error for global scape
- Licence description on PyPI incorrect HOT 1
- Error cannot convert float nan to int HOT 10
- Issue with build_cutout using alite HOT 5
- reanalysis-era5-single-levels HOT 3
- Atlite errors with ESRI:540060 reprojections and Fiji HOT 7
- Read from url for `excluder.add_raster` and `excluder.add_geometry` HOT 2
- PV conversion: New model based on Bloomfield et al. (2019)
- Wind Conversion: potential bug when power curve does not end with zero after cutout speed HOT 1
- Weather/climate data variable descriptions (for alternate model data use) HOT 2
- Problems with `convert_and_aggregate` for long timespans? HOT 12
- Data type error when building cutout with SARAH v3 HOT 4
- Merging cutouts / Integrate downloaded SARAH data into existing ERA-5 cutout HOT 1
- Setting the "capacity_factor_timeseries = True" the results seem not to change HOT 2
- Time misalignment between ERA5 and SARAH? HOT 6
- "Optimal" orientation does always lead to more output HOT 4
- Migrate to new CDS infrastructure
- CSP has capacity factors > 1 when passing shapes HOT 7
- `compute_shape_availability` triggers numpy failure: Python integer 255 out of bounds for int8 HOT 3
- Unable to generate SARAH cutouts
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from atlite.