HeyWhatsThat horizon discrepancy

[Update: this issue has now been fixed, see my followup post]

I’ve been playing with importing horizon data into PiAware from HeyWhatsThat and I’ve noticed a discrepancy in the scale of the horizon when displayed in Skyview. The effect is more noticeable at higher (and presumably lower) latitudes and less so towards the equator. Has anyone else noticed this? I have contacted HWT but thought I’d make people here aware too and see if there’s any feedback.

Here’s an example.

I went to HeyWhatsThat and created a new panorama with an index of 0.25. I centered it on part of Poland’s northern coast at an elevation of 5 metres above the ground.

The panorama is completed with ID MAVVN9WW [Edit: I have also tried this with elevation set to 0 metres in panorama NQTF4WQB, after ensuring old data was not cached the result was identical to the original]. I have it display a horizon for an altitude of 12192 metres. You can see that shown in blue.

I import the JSON data with the same parameters and move it into the relevant subdirectory.

I view the horizon in Skyview.

Notice that, while it is the correct shape and item, it has a different scaling on each map. On HWT it just passes Copenhagen; on Skyview it goes right past it. On HWT it intersects Warsaw; on Skyview it goes past it. On HWT it doesn’t reach Riga, Latvia’s capital; on Skyview it goes past it. The horizon is around 50 statute miles further out in all directions on Skyview than it is on HWT.

I’m trying to get to the bottom of whether this is:

  • A bug in the way the horizon is shown on the HWT map
  • A bug in the way the horizon is shown on the Skyview map
  • A bug in the generation of the JSON data
  • Something else

I’ll update if HWT responds.


1 Like

Heywhatsthat I take for granted as been correct and a reference.

I think it has something to do with geo-coordinates transformation.
the other day i tried to create an ATZ 3nm circle in a geojson file,
with set center and radius. the result was a ‘flattened egg’.
not sure, but i think if not GSIS done, the json has limitations both on arc and circle
so people create polygons of straight lines spaced closely to resemble a circle.

now, I know we try to get ATC-like composite radar precision for 20$, but cant be done,
otherwise their systems (hardware and software) wouldn’t cost millions :grin:

FYI I use AKISSACK’S scripts on dump1090-mutability and dump1090-fa.
[8. Maximum range plot · alkissack/Dump1090-OpenLayers3-html Wiki · GitHub]


1 Like

My suspicion is you’re right – I think HWT is correctly determining and rendering the horizon onto its projection and is producing JSON data which reflects just the resulting shape. The shape is only correct when placed at that point onto the mapping used by HWT. Skyview is then dumbly rendering that shape onto a different map and this exposes any mapping differences or transformation/assumptions made. That would be my guess.

[Edit: wrong, see below]

Followup post – this issue has now been fixed.

The problem was caused by the “Up in the Air” feature on the HWT site not using the refraction value, effectively using a value of 0 when displaying the terrain rings. The rest of the site, and the API used to generate the JSON data, was using the refraction value. This meant that the rings displayed on HWT were the wrong size, and the rings displayed in Skyview from the JSON data were correct.

Thanks to Michael from HeyWhatsThat for diagnosing and fixing the problem. In order to ensure that the correct terrain rings for 1090MHz are displayed on the HWT site when using the “Up in the Air” feature you must use the URL

and enter 0.25 into the Refraction box in the Optional parameters section


If you don’t use the full URL you won’t see a box for Refraction and in that case the default value of 0.14 will be used which will result in rings of the wrong size for our use.

The API continues to work as it did before. Obtain the panorama ID and specify a refraction of 0.25 and the altitudes in metres in the API call, eg:

wget -O upintheair.json "http://www.heywhatsthat.com/api/upintheair.json?id=XXXXXXXX&refraction=0.25&alts=6096,12192"

and move this file into


With the HWT site now correctly using the specified refraction value in its terrain ring calculations both maps now show exactly the same result.