Open jwalatham opened 4 years ago
I second this. We overlay tar1090 data on top of a video feed (see https://www.youtube.com/watch?v=VhGmAigHKFg).
Just today, we had a pilot inquire about why it would read -300' as planes were touching down. We also use this system to help with neighbor noise complaints. Someone may "complain" that there was an airplane over their house at 500ft (and have the "proof" to back it up!), but in reality, the plane may be at 1000' [pattern altitude] -- try explaining that to an irate airport neighbor!).
I think the fix may be simple: Read an adjustment number from a text file on the webserver (how that number gets there is a job for whomever is setting up tar1090)
@rcarsey1 you are using these data for what ? You should contact ATS. They have to have radar records stored so they can replay real data correlated from multiple official sources. This is just hobby and could not be used for legal usage. There is rule that airplane should fly at least 1000ft above houses. BUT Excluding takeoffs and landings. There could be Noise abatement procedures, but they are monitored by ATS and who do not follow usually get fine to pay. If you have data and you have QNH you can still recalculate manually. How you want to update QNH in system ? Automatically ? Manually ? From where you get official QNH? I mean certified data not just random from internet. Will you update it every 30mins or even more often when there will be SPECI or updated METAR? How you want to decide which QNH to use relating to airdrome? So lot of problems and i do not see any benefit. Still these data can not be used for legal usage.
Another is that. Transponder should always send "pressure altitude" which is recalculated using 1013,25 hPa
It is very easy to recalculate.: For simple we can say that 1hPa change is ±30 ft. then if you know QNH then you can simply do (1013 - QNH) * 30 = is change of altitude. Then:
Most pilots (surprisingly) and the general public don't realize that Mode-C and ADS-B use pressure altitude.. nor do many pilots remember how to convert to indicated/MSL. Since I'm using tar1090 to create on-screen overlays for airport video feeds, I often get asked why the altitude on the targets is "wrong" on target labels. They don't understand how an aircraft can be at -100'.
What I proposed can be simple. 1. Either a parameter on the URL like &altimeter_setting=xxxxx -- and if present, tar1090 would simply do the math for all the targets when displayed on the map (Overlay/Labels). 2. A setting in the config file which would allow me to configure a URL where tar1090 can periodically pull text data containing the altimeter setting.
A more complicated solution would be to allow multiple altimeter settings, along with their coordinates, and tar1090 can extrapolate the correct altimeter setting based on the target's position in relation to the known coordinates/setting pairs.
In the US, we can grab official weather information by API (example):
https://www.aviationweather.gov/adds/dataserver_current/httpparam?dataSource=metars&requestType=retrieve&format=xml&fields=altim_in_hg&stationString=KBLM&hoursBeforeNow=1
Ah .. now I see the use-case and start to make sense in my head. I did not know there is possibility to create these overlays. Maybe there will be better to add some WebHook handlers -> add custom field (text, number ...) with user defined location and dimensions ,...register handler for this field, ...TAR1090 send data (array of aircraft data) every xxx seconds (user defined). you will do your math/magic with data and return back to show on map in specified field.
so then you can do what you want with what you want and show where you want.
API is interesting. It supports also non US airports. Just values are in US units
EDIT: In code there is function which i tried to debug.. very briefly.
PlaneObject.prototype.updateData = function(now, last, data, init) {
If we introduce new url param like u suggested altimeter_setting=xxxxx
we can update updateData
function to do the math and show altitudes depending on your pressure setting. It will not be very robust but could do the job. There could be also another url param like METAirdrome=xxxx
. In case this param is set you can also execute additional function which can download QNH automatically from published API and again do the math automatically. To revert back to STD just remove params.
Then why not have auto-QNH, by taking the QNH from the airport nearest to the center of the map?
Because you can use QNH only under Transition Level (TL) during descend or under Transition Altitude (TA) during climb. Transition altitude is constant over time, but every airport can have different TA. On other hand TL is not constant and is determined depending on QNH and usually transmitted as part in ATIS broadcast.
So then you have to implement something more robust because you can not use QNH for ACFT in FL 220 because it have to use standard pressure setting and not QNH.
So there should be setting/flag to enable disable function. Also param in url is easier to implement than to also do math with geopoints. getting nearest airport supporting metar an then do the math. And no not every icao airport publish METAR or TAF
I myself am more intersted in lower flying airplanes, not in the ones using flight levels. If auto-QNH were an option, I would use it all the time. But is the transition level or transistion altitude not available from the same METAR where you can also get the QNH from? Then you could even automate the display value to change between FL and altitude automaticall where appropriate. Edit with Self-answer: No it's not in the METAR. It is indeed in the ATIS messages, at least in the Netherlands.
Transition altitude is defined by Air traffic services. Transition level is calculated by difference between QNH and Standard Pressure 1013,25hPA the way that between have to be at least 1000ft so it is different for QNH higher then STD and different when QNH is lower than STD (simple calc is using ±27ft per hPa). It Is calculated when QNH is measured and updated but on other hand TA is always the same and does not matter on QNH. TA can be different for FIR or even for airports. In METAR there is QNH, but never TA or TL. METAR is just actual weather report. TA and TL is more local procedures related.
TA is usually in Instrument charts (or AIP) and TL is in ATIS or transmitted by ATC (where ATIS is not available). I think the easiest way is to use new column in settings where user can write ICAO code of airport for METAR downloads. Extract QNH from it and recalculate all altitudes. There also have to be some timer to download new METAR every 30 mins.. There could be also SPECI messages or amended METARs
It would be useful to be able to add a pressure value (QNH) and Transition Altitude so that aircraft altitudes show correctly, rather than based on 1013.2 all the time. Virtual Radar Server used to have this option in the settings menu, and it was very useful to correct aircraft showing at negative altitudes or "underground".