dem-net/DEM.Net

[0.3.0] Elevations returned in `GetIntervisibilityReport` seem to be incorrect.

Closed this issue · 5 comments

rurounijones commented

Describe the bug
The elevation values of GeoPoints and Obstacles calculated in GetIntervisibilityReport seem to be incorrect due to being incredibly high (24km tall mountains) and different from elevationapi.com results. There are also a lot of suspicious negative numbers

To Reproduce
See code @ https://gitlab.com/overlord-bot/srs-bot/-/blob/los/OverlordBot.Core/Util/LineOfSightChecker.cs
The report, including the source and target is visible @ https://gist.github.com/rurounijones/ec9160fb48a5cf86c2a5b6d8b48eb6b9

Expected behavior
Given that the source and target points are 30,000ft above mean sea level they should be visible to each other with no terrain in the way. However there are 850 obstacles (See the bottom of the gist) and a lot of the elevation values in the GeoPoints look wrong as well.

Taking one of the GeoPoints from the report:Lat/Lon 44.9170527107368/37.56388888888889 at 624.8850708007812 meters. Distance from Origin 16.142537758223373 shows an altitude of 600 meters but the same lat/lon on https://api.elevationapi.com/api/Elevation?lat=44.9170527107368&lon=37.56388888888889&dataSet=SRTM_GL1 returns 80 meters (which is accurate I believe).

It is entirely possible I have made a stupid mistake somewhere or have misunderstood something but I have double-checked everything and cannot see it.

xfischer commented

Thanks for the detailed report. I will have a look right now.

xfischer commented

Hi. I have no issues with 0.3.0.
One thing might have occured : SRTM files have been changed recently from HGT to GeoTIFF files.
You should deleted them completely to be sure the good version is downloaded again.

Here's my test run :
image

rurounijones commented

One thing might have occured : SRTM files have been changed recently from HGT to GeoTIFF files.

I am getting .tif files (Same as before) but I don't know if that is enough to verify the underlying format.

Just to make sure we are getting the same files could we compare the MD5s of one example file? N45E045.tif which has an MD5 hash of 03c1a6d2dccd48b77c138086f2fbc82c for me

And the associated manifest JSON file: N45E045.json

{
  "Version": "2.2",
  "Filename": "SRTM_GL1/SRTM_GL1_srtm/N45E045.tif",
  "Height": 3601,
  "Width": 3601,
  "PixelScaleX": 0.0002777777777777778,
  "PixelScaleY": 0.0002777777777777778,
  "DataStartLat": 45.0,
  "DataStartLon": 45.0,
  "DataEndLat": 46.0,
  "DataEndLon": 46.0,
  "BitsPerSample": 16,
  "WorldUnits": null,
  "SampleFormat": "INT",
  "NoDataValue": "-32768",
  "ScanlineSize": 7202,
  "PhysicalStartLon": 44.99986111111111,
  "PhysicalStartLat": 44.99986111111111,
  "PhysicalEndLon": 46.000277777777775,
  "PhysicalEndLat": 46.000277777777775,
  "pixelSizeX": 0.0002777777777777778,
  "pixelSizeY": -0.0002777777777777778,
  "FileFormat": {
    "Name": "Nasa SRTM HGT",
    "FileExtension": ".hgt",
    "Type": 0,
    "Registration": 0
  },
  "MinimumAltitude": 0.0,
  "MaximumAltitude": 0.0,
  "NoDataValueFloat": -32768.0
}

Is this what you are expecting?

rurounijones commented

I have redownloaded all the files and while I can see no differences between them down to the MD5 level, it now appears to be working so I am stumped as to why the numbers were so off before but all good now.

xfischer commented

I'm glad it works now.
I didn't investigate too much on this. I think the problem was presence of HGT and Tiff files in the same directory.