search

eldang / elevation_lookups

Takes an input file of paths described as series of points, outputs a file of data about the elevation changes along those paths.
Apache License 2.0
3 stars 2 forks source link

-inf in output #13

Closed dabreegster closed 3 years ago

dabreegster commented 3 years ago

Running with LIDAR over a large area of Seattle, the following input line: crazy_input.txt yielded output: -inf 5.136 1.0371804643694073e+38 0.287

I can warn and skip this on my end. I'm not sure what makes sense to do from the tool. The input has so many points; there might be something really strange going on. I'll more usefully dump the road ID to figure out where this actually is.

dabreegster commented 3 years ago

Ah, just by plugging in some of the points, it's the 520 bridge. Speak of the devil. :)

dabreegster commented 3 years ago 
/elevation/files.py:39: RuntimeWarning: overflow encountered in multiply
  self.f.write(str(round(data.end, SAVE_PRECISION)))

Maybe related? Maybe the overflow has already happened, but it only gets warned about when trying to round? Total guess

eldang commented 3 years ago

Hrm, interesting! Looking at the LIDAR file in QGIS, it has elevations of 5.1-5.3m for Lake Washington close to shore, but -1.0371805e+38 for the middle of the lake. That's probably supposed to be NODATA and getting misread, maybe as float_min, but I'm sure it's causing the overflow. They probably just didn't bother flying across the lake.

There's something similar for the sea, except that the lowest elevations there are about 0.4m, and the elevations returned for near the shore vary E-W. It looks like they overflew Alki & Golden Gardens at a lower tide than the portions of the shore which are further E....

Looking at those start and end points visually, I think the start is in the nodata area, while the end's close enough to shore to get tagged with lake level.

I'll look at this properly tomorrow. I think it's going to need some special handling, either to flag NODATA values in the config, or to just work around negative elevations. Do you have a preference between:

The one thing I don't want to do is mix data sources within one line. That risks giving really wacky total climb and descent values.

eldang commented 3 years ago

https://github.com/eldang/elevation_lookups/pull/15 is a slight improvement on my middle suggestion above. Using SRTM as a generic fallback would need some non-trivial restructuring of the code, so I think for now we should see if this is an adequate solution.

eldang commented 3 years ago

Having merged that PR, I think we should keep this issue open for now in case it's not a complete solution.

eldang commented 3 years ago

I'm closing this for now, aware that it may need reopening after further testing.