search

fgx / fgx.github.io

The FGx public web presence on GitHub
http://fgx.github.io
Other
2 stars 3 forks source link

2016-07-17 ~ VHSK FlightPath R1 #30

Closed theo-armour closed 8 years ago

theo-armour commented 8 years ago

image

@fgx/owners

VHSK FlightPath

Change Log 2016-07-17 ~ R1

theo-armour commented 8 years ago

image

@fgx/owners

VHSK FlightPath R1.1

Ignore position discrepancies for the moment. WIP.

Change Log 2016-07-18 ~ R1.1

geoffmcl commented 8 years ago

Hi Theo,

Yippee! The track is back ;=)) thanks...

Ignore position discrepancies for the moment. WIP.

Yes, understand, but visually, the lon (x) looks near to perfect...

The lat (z) suffers like several previous, but is perhaps only less than a kilometer, a few hundred meters wrong... hard to exactly measure... but there is a north-south deviation between the map image, and the track...

The alt (y) is real _wrong_ between these two, map and track ;=((!

The flight was always at less than Kai Kung Shan (374 m) and Kai Kung Leng (572 m), the small hill the top of the track skirts to the south around...

The maximum flight elevation was just around 500 feet, 152.4 m! That is always LESS than most of the hills in the terrain...

And this same massive elevation deviation is also apparent in KGCN, where there is no terrain higher than the flight... the flight should touch the runway for takeoff and landing...

But I am sure you will get this right...

Regards, Geoff.

theo-armour commented 8 years ago

VHSK FlightPath R1.2

2016-07-19

Flight path lat & lon now seems to register properly with ground lest lat & lon

geoffmcl commented 8 years ago

Hi Theo,

I have not yet looked at exactly what you changed, but it does seem both the lon(x) and lat(z) seem to agree between the map/elevations and the given track... YIPEE...

But there maybe remains the stupid difference between wsg84 in google, and what FG uses...

That is there remains a discrepancy between the start point of the track... that is the track should start at the threshold of runway 11... for VHSK... near 22.439689,114.071767, moved forward by FG, to the actual bar marked thresh-hold...

The first point in the cooked track file is -

lon,lat,alt,hdg,ias,roll,pitch,slip
114.0889859484,22.4335105538,67,291,0,0.111967,1.698016,0.000000

The stupid thing is, when I feed 22.439689,114.071767 into Google Earth, I get a point, on runway 11, as expected, before the threshold, but that is right for a FG point... and that is the same when I feed that into google maps online... all agreed on this runway start point...

But why does there seem a difference in google terrain? As mentioned earlier, there does seem some discrepancy between the google APIS!!! Which is not for us to solve...

And similarly, the kgcn display... seems some problem with the link in this regard...

But the altitude (y) still seems way, way off! ;=)) WHY?

I am not sure of the load sequence, but it seems you schedule the elevation load, to pass to the scene block, before the track is loaded... all async...

As sort of suggested earlier, the track load seems the important first step... It unconditionally sets the desired limits of the scene... yes, the map will hopefully be larger than the tracked scene, never smaller, ...

And when loading the near perfect example flightpath one thing I note is the track is drawn before anything else in the scene... all other scene/map improvements are loaded later... take more time...

Now, from the track, take its center, as the most important point, we could use our slippy map knowledge to know what maps to load at any given zoom, to cover this area... but we do not use that...

So far this has nothing to do with an elevation array!!!

We could draw this known, fixed wsg84 track on a 2D map display, and that should work... Well, if the maps are placed at 0 AMSL, then the track should fit perfectly... lat,lon,alt... simple...

Now, we want to add elevation to the map terrain. Good idea...

To do this we are using a separate service get elevations... I have already mentioned some teething problems with this great manual Google API download service... and understand you will get to this in due time...

But preferred a naming convention based on the center of the tile of interest, say VHSK, in this instance, rather than the mappy tile upper top left notation... but ok, what ever...

Liked other improvements, like non-square elevations...

And then copying the required elevation file to where we are doing this track load, and the name of the elevation file has some new meta clues, recently changed... to position it... independent of the track...

So what is the big problem with these ELEVATION? They are exact, easy to get, for the correct area... some Google API usage restrictions, but perfect...

The track file, the cooked csv, has AMSL elevations in feet IIRC...

Yet, I think the elevations are in meters in the Google API...

Where are we converting the track feet elevations to meters... x 0.3048??? Maybe I missed it...

Is this as simple as dividing the track elevation by 3??? Maybe already done, but I missed it...

Otherwise, can see no reason why the AMSL elevations of the two objects in the scene do not agree 100%...

Regards, Geoff.

theo-armour commented 8 years ago

@geoffmcl 5:27 pst

Just updating to YGIL R3 and to VNLK R6

KGCN and VHSK updated earlier. You mach need to clear cache to see. Or update release numbers in address bar by hand.

Lat and lon seem to be good.

Still have not worked on elevation matching.

THANK YOU for pointing that the flight path altitudes are in feet! Will save me much head scratching.

But preferred a naming convention based on the center of the tile of interest

Me too.

Here's the issue:

You need to identify upper left and bottom right corners of the elevations area quite accurately. Accurately enough so that correct tiles are always called. But at every corner there are four tiles. A teensy error and - bingo - the wrong tile is called for.

Also using lat/lon means allowing say twenty spaces or more to be accurate. Using tiles numbers makes for shorter file names.

If you can think of a better file naming system, I'm all ears. Must infallibly supply time numbers for UL and LR corners. Without tile numbers then we have no way of selecting and placing bitmap overlays in with correct registration.

theo-armour commented 8 years ago

image

@fgx/owners

Lots of detail in Hong Kong. Path looks good.

http://fgx.github.io/sandbox/flightpaths/vhsk/vhsk-flightpath-r2.html

theo-armour commented 8 years ago

http://fgx.github.io/sandbox/flightpaths/vhsk/vhsk-flightpath-r3.html

pedromorgan commented 8 years ago

Can u please DUMP the silly little plane, cos its daft and stupid.. BTW the plane id seriously incorrect attitude, and flew loops with node down.. perfectly..

And if instead its BLIP a "triangle" with a heading and "attitude" then this would be fantastic.. Look a bit more like a 3D radar screen instead...

But theo u stick to making pages and pages and pages.. when all u need it a "library" in js and the template.. and then the data and scenarious loaded...

I can help with this, but that means u MUST use git and we make js/templates etc.. literally a one page website... with ajax feed.s..

pedromorgan commented 8 years ago

LIMITS... I never want to be able to go "under the suface"... ever.. I'm a pilot not a rock submarine... So please limit that, cos its confusing and daft.. and Not Required...

pedromorgan commented 8 years ago

theo-3d-getting-there

pedromorgan commented 8 years ago

https://www.google.co.uk/search?q=radar+triangle&espv=2&biw=1280&bih=894&source=lnms&tbm=isch&sa=X&ved=0ahUKEwjx5NOc34XOAhUlIMAKHUS7CCEQ_AUIBigB#tbm=isch&q=ATC+radar+triangle&imgrc=_

Also checkout @theo-armour Top recommend http://casperflights.com/unified/?location=egkk and thats in flash... and if we can get more int that, then were on mega time...

pedromorgan commented 8 years ago

The "flight trail", need to be in yellow.. or light green, but noticable.. against background

The bounding frame in red, needs to be in "white or light grey" to identify the "box for you"

pedromorgan commented 8 years ago

Exremely useful would the the cones for the ILS notably..

lateral

GS

DME

pedromorgan commented 8 years ago

theo-4d-getting-there2

Here's casper.. BUt @theo-armour we already been here..

pedromorgan commented 8 years ago

So there's is already a database to create alignments, and radar etc..

It's here but need to get online again.. Its in postgres whcih is geospatial.. et all.. https://github.com/freeflightsim/fg-navdb

So maybe we can all of us work together to bring this back up.. to do that..

1) we need post.gis = postresdb+extentions... = circa 2016 its Baked in ;-)))

2) Make it a WWW service eg on a server with postgis = openshift = free tear ;-

3) create an interface with ajax for "mashups" like theo does.. or anyone else..

4) its already there.. we need to start working together.. and xdomain nagging to make a cool, cool system..

pedromorgan commented 8 years ago

IMPORTANT:

Remove animation on slide in and out etc.. We dont want to eat precious frame rate, and a a pilot.. Its not gonna fabe in and out anyway.. So get real of a flightdeck and ATC control room.

pedromorgan commented 8 years ago

We need buttons and real stuff on the "side and control panel" so think like a pilot..

1) dont role it out yourself, use bootstrap and alike cos prolbems sorted there in xplatform

theo-armour commented 8 years ago

@pedromorgan

Lots of great thoughts and links. Thank you!

I will work these into a wish list.

Note that we already have ILS cones for thousands of airports at 3 second terrain accuracy here:

http://jaanga.github.io/fgx-plane-spotter/r4/fgx-plane-spotter-r4.html

The goal now is to get down to get to 1-second terrain accuracy - and even better where available