Skip to content
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

Iso surface #54

Merged
merged 20 commits into from
Mar 11, 2021
Merged

Iso surface #54

merged 20 commits into from
Mar 11, 2021

Conversation

domfournier
Copy link
Contributor

@domfournier domfournier commented Mar 10, 2021

Create a new application for the creation of isosurfaces around data values.

  • Add/update to docs.
  • Small fix for changes to osgeo.
    iso_surface_app

@domfournier domfournier requested a review from sebhmg March 10, 2021 19:10
Copy link
Contributor

@sebhmg sebhmg left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nice feature !
please see various suggestions / questions

(not reviewing the ipynb files)

geoapps/processing/calculator.py Show resolved Hide resolved
@@ -135,9 +139,6 @@ def trigger_click(self):
y,
)

if self.code_out.value == "EPSG:4326":
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question: is the flip of x and y some kind of work-around for a bug in the 3rd party?

Maybe add a comment line 131 to explain it?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

it looks like they finally made the good call of exporting as long-lat. Before going from cartesian (xyz) would return (lat-lon) which basically permutes the axies. I just found that building the docs today. Looks like the reverted from a previous version: OSGeo/gdal#1546

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

formerly there were two swaps: line 131 and here. Should not the swap at line 131 be removed as well then?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@domfournier, do you confirm the swap it line 131 must stay? I am somewhat confused

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's a fair point. Right now it makes it "work", but I will have to drill down a bit more.

geoapps/processing/create.py Outdated Show resolved Hide resolved
geoapps/utils/utils.py Outdated Show resolved Hide resolved

Parameters
----------
xyz_in: numpy.ndarray shape(*, 3)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

question (non-blocking): why not using typing in the signature?

geoapps/utils/utils.py Outdated Show resolved Hide resolved
geoapps/utils/utils.py Show resolved Hide resolved
geoapps/utils/utils.py Show resolved Hide resolved
geoapps/utils/utils.py Outdated Show resolved Hide resolved
else:
vertices = np.vstack(vertices).T
except RuntimeError:
vertices, faces = [], []
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

suggestion: should log the detail of the exception?
we do not really expect one, do we?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

if vertices is empty yes

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

in that case, it might be clearer to test for empty vertices instead of letting the exception happen

domfournier and others added 5 commits March 10, 2021 16:20
@codecov-io
Copy link

Codecov Report

Merging #54 (68df43e) into main (30b6374) will decrease coverage by 1.88%.
The diff coverage is 77.77%.

Impacted file tree graph

@@            Coverage Diff             @@
##             main      #54      +/-   ##
==========================================
- Coverage   20.81%   18.92%   -1.89%     
==========================================
  Files         146      146              
  Lines       24148    24250     +102     
  Branches     4102     4118      +16     
==========================================
- Hits         5026     4590     -436     
- Misses      18792    19384     +592     
+ Partials      330      276      -54     
Impacted Files Coverage Δ
geoapps/processing/calculator.py 67.08% <ø> (-1.27%) ⬇️
geoapps/selection.py 85.26% <ø> (-3.69%) ⬇️
geoapps/utils/__init__.py 100.00% <ø> (ø)
geoapps/utils/geophysical_systems.py 100.00% <ø> (ø)
geoapps/processing/coordinate_transformation.py 73.04% <50.00%> (-0.71%) ⬇️
geoapps/processing/data_interpolation.py 52.67% <50.00%> (-13.12%) ⬇️
geoapps/utils/utils.py 37.50% <77.33%> (+0.91%) ⬆️
geoapps/processing/create.py 63.96% <80.70%> (+3.16%) ⬆️
geoapps/__init__.py 100.00% <100.00%> (ø)
geoapps/plotting/selection.py 90.09% <100.00%> (+0.65%) ⬆️
... and 6 more

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 30b6374...68df43e. Read the comment docs.

@domfournier domfournier merged commit f8108b8 into main Mar 11, 2021
@domfournier domfournier deleted the iso_surface branch March 11, 2021 02:15
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants