liamtoney / infresnel Goto Github PK

This relationship predicts insertion loss using the Fresnel number. Should add some discussion of the limitations of this relationship. Add the Maekawa (1968) reference to the references list, too.

Once this is done, the README should be updated to point to the notebook file(s) and Binder link.

Could start with a simple, general test of calculate_paths().

Not a Number (NaN; e.g., np.nan) values can make their way into input DEMs for infresnel in a few ways. There are no SRTM data at high latitudes (beyond 60° N and 56° S), so the automatic DEM downloader may return NaN values (check this!). Also, a user-supplied DEM may have NaN values either because it contains holes (yikes) or because it has a non-rectangular geometry in the UTM projection (more likely; see the Yasur DEM for example). I see three cases to address:

1. The DEM is all NaN values. This might occur if dem_file=None and we are totally beyond the SRTM latitude range. We should error out here.
2. The DEM has no NaN values. This is generally the case for SRTM data totally within the latitude range, since we are clipping from a much larger DEM. It can also be the case for well-trimmed user-supplied DEMs.
3. The DEM is partially composed of NaN values. This can be the case for SRTM data on the "boundary" of the latitude range, or for user-supplied DEMs with holes or non-rectangular geometries as mentioned above. We should warn the user here, since NaN values in the DEM pose problems. We can print the percentage of the DEM that is NaN as a useful warning...

For case (3) above, even without holes in the DEM we still have the challenge of fitting the RectBivariateSpline, which cannot have any NaN values in the input z. Currently we just replace NaN with 0 everywhere to get around this. However, this is not the best idea since it produces large discontinuities ("cliffs") in elevation where the spline fitting becomes extremely unstable. This can cause the evaluated elevation profiles to have artifacts — which bleeds into the path length computations.

Even though we can skip computing paths for receivers located in NaN regions, receivers just on the edge of the valid (non-NaN) portion of the DEM can still experience edge effects. There are two approaches we can take to avoid this behavior, both which only apply for case (3):

• Instead of filling with 0, we can fill with a more intelligent value such as the median of the DEM data. This will still result in discontinuities but may be sufficient to suppress edge effects in most cases. This is fast.
• We can perform a nearest-neighbor extrapolation, via e.g. scipy.interpolate.griddata(). This basically matches the area around the valid portion with similar values. This is obviously not valid far from the valid region, but it should be very effective in stabilizing the spline fitting process. This is slow. It might make sense to downsample the evaluation points xi for speed, then upsample them to the DEM resolution before adding as the "background" to the DEM to fill the NaN values. This is significantly more work and adds complexity to the code.

Tentative action items, based on the above...

• Add a check for NaN values in the DEM, to determine which of the 3 cases we have.
• If case (3), print the percentage of NaN values as a warning, then apply the first of the two approaches outlined above prior to fitting the spline.

We can see if this is successful to suppress artifacts; if not then the second of the two approaches above may need to be implemented.

I get an incorrect UTM geodetic(?) CRS for a scenario in Italy. It seems to come from

where

utm_crs = _estimate_utm_crs(15.2122, 38.7946, datum_name='WGS 84')

which should return a CRS of 33 but instead returns one of 37.

Basically, we should implement a "safety buffer" around the valid-elevation-data borders of such DEMs. I.e., we don't want to compute paths for points near that border. This is mainly relevant for calculate_paths_grid().

Not a hugely critical issue since it's usually pretty obvious when this happens. Applying e.g. vmax=np.nanpercentile(path_length_differences, 99) when creating an image plot works pretty well to suppress these artificially high outliers.

Perhaps just editing the tolerance in this part of the code is enough? E.g. increasing to 2 * mean_resolution or something... easy to try this out

The main computational expense involved in the code is the DEM interpolation step. There may be ways to expedite this that don't take too much effort to implement.

Docstrings are already formatted for this.

Using Joblib, likely... ostensibly simple to do this.

Sometimes (usually when running infresnel to produce grids) a ZeroDivisionError occurs. The error is raised during this line:

Evidently, sometimes the quantity d[-1] - d[0] is 0. This can occur when the profile spacing (which is currently automatically determined from the DEM spacing) is larger than the requested grid spacing.