-
Notifications
You must be signed in to change notification settings - Fork 1
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
WIP: masking outliers + conflicting distributions + incidence angles + high uncertainty classification + majority filter #6
Conversation
Check out this pull request on See visual diffs & provide feedback on Jupyter Notebooks. Powered by ReviewNB |
View / edit / reply to this conversation on ReviewNB SwamyDev commented on 2023-12-20T06:48:52Z I was shortly confused by the "multi-band datacube" term thinking "where is VH or L-Band here?", but then I realised multi-band in the openEO sense. However, I'd still better write "The merged preprocessed datacube..." since these aren't really bands, even if openEO pretends. |
View / edit / reply to this conversation on ReviewNB SwamyDev commented on 2023-12-20T06:48:53Z You could consider putting this nice function into a python module. |
I can't see these comments now, as I blocked this app. Somehow it keeps showing up in this repo. Can you comment on the |
Lol, works great then this app ^^, yeah I'll do a normal review then |
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.
Well done, works really nicely also the results are very well presented!
notebooks/1_yeoda_dc.qmd
Outdated
def view_flood_map(df): | ||
# selecting a subsection of the data and reprojecting | ||
flood_map = df[0, 13070:14000, 12900:14200] | ||
flood_map = flood_map.rio.reproject(f"EPSG:4326", nodata=np.nan) | ||
# add open streetmap | ||
request = cimgt.OSM() | ||
# initialize figure | ||
fig = plt.figure(figsize=(13,9)) | ||
axis = plt.axes(projection=ccrs.PlateCarree(), frameon=True) | ||
axis.add_image(request, 15) | ||
# add the data | ||
flood_map = flood_map.plot( | ||
ax=axis, | ||
transform=ccrs.PlateCarree(), | ||
levels=[0, 1, 2], | ||
colors=["#00000000", "#ff0000"], | ||
add_colorbar=False | ||
) | ||
# legend and title | ||
cbar = fig.colorbar(flood_map, ax=axis, location="bottom", shrink=0.6) | ||
cbar.ax.get_xaxis().set_ticks([]) | ||
for j, lab in enumerate(['non-flood','flood']): | ||
cbar.ax.text((2 * j + 1) / 2.0, 0.5, lab, ha='center', va='center') | ||
cbar.ax.get_xaxis().labelpad = 10 | ||
tk = fig.gca() | ||
tk = tk.set_title("Flood map") |
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.
You could consider putting this nice function into a python module.
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.
I took the lazy approach for now whereby I do not show this code chunk in the final webpage: https://martinschobben.github.io/openeo-flood-mapper-local/. But I'll consider this.
I will now then also consider implementing |
Adding |
@MartinSchobben I did implement mask already, there's an open PR here Open-EO/openeo-processes-dask#165 It would be nice if you could review it! We need anyway someone at EODC to review and approve it, since the repo is still officially maintained by them. |
@MartinSchobben the verboseness of the logs when you call .execute() depends on your logging level. If you set it to INFO, you won't see any logging message at all. (I just run the notebook and didn't get any log message). |
@clausmichele Ah great! Even better. I'll have a look then. |
@clausmichele, but to clarify we are not EODC. We are TUWien. |
I know! |
I am now getting closer to what the openeo workflow should look like with |
A bit of overhead is understandable, since the mask process needs to take care about multiple possibilities, depending on the input datacube. However, it would be interesting to understand what's the step taking the most time! I will also try and check. |
Hmm, interesting. I was using multiplication at first. But, as the idea of this repo was to showcase transforming an existing pipeline (Copernicus GFM) into openEO syntax, I found it useful to stick to the given processes. I'll also have a look what causes this increased processing time. |
But a simple multiplication is also represented as a basic openEO process, so there's nothing wrong with it. But as I was saying, it could fail if the input datacubes are not matching. Anyway, I'm doing some tests and the time consuming part seems to be calling the |
The main issue is handling no data values and the replacement value, that's why we rely on
|
A further question @clausmichele, regarding the above comment. I would actually expect the cube for
I think I answered it myself, openeo local processing loads data chunked as far as I can tell. |
Well, the |
I reverted to masking by multiplication instead of using the process |
@clausmichele FYI, I put this here: Open-EO/openeo-processes-dask#215. We have trouble understanding the definition of |
There is no mask method in the local instance, so for now I just use multiplication to do the same thing.