Sometimes Hgt.bilinear returns artefacts

[memarv]

I use SyncTileSet. It happens that getElevation() returns wrong data. Example:
Lat: 49.408558
Lon: 20.433394

This is console.log's output from Hgt.bilinear:

row = 490.2695999999992
col = 520.0727999999998
rowLow = 490
rowHi = 491
rowFrac = 0.2695999999991727
colLow = 520
colHi = 521
colFrac = 0.07279999999980191
v00 = 459
v10 = -32768
v11 = -32768
v01 = -32768
v1 = -1959.925599993418
v2 = -32768

In this case getElevation() returns -10265.78

Another example:
Lat: 49.408558
Lon: 20.432394

row = 490.2695999999992
col = 518.8727999999983
rowLow = 490
rowHi = 491
rowFrac = 0.2695999999991727
colLow = 518
colHi = 519
colFrac = 0.8727999999982785
v00 = 459
v10 = 475
v11 = -32768
v01 = 497
v1 = 472.96479999997246
v2 = -28536.691999942734

I've tried download .hgt files from http://www.viewfinderpanoramas.org/ and https://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Eurasia/
It does not matter. The same.

[rapomon]

According to the Nasa's documentation, voids are flagged with -32768.

Byte order is Motorola ("big-endian") standard with the most significant byte first. Since they are
signed integers elevations can range from -32767 to 32767 meters, encompassing the range of
elevation to be found on the Earth.
These data also contain occassional voids from a number of causes such as shadowing, phase
unwrapping anomalies, or other radar-specific causes. Voids are flagged with the value -32768.

Maybe you should consider 0 or a near value when the value is -32768.

[memarv]

Thank you. I think it's voids.
I've realized that http://viewfinderpanoramas.org/dem3/M34.zip has two versions of N49E019.hgt and N49E020.hgt but both seem to be corrupted. Do you know another .hgt files sources?

[rapomon]

I wrote a module based on node-hgt that uses the Nasa's data: https://dds.cr.usgs.gov/srtm/version2_1/SRTM3/Eurasia/

You can test it: https://github.com/rapomon/srtm-elevation

[perliedman]

Thanks for reporting, you are correct, the code should filter out no data values (-32768) and don't use them in the calculation.

I'm not actively using or working on this project, so contributions to fix this are welcome, otherwise I hope I will get around to do it myself sooner or later.