search

fgx / fgx.github.io

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

Update ~ 2016-04-24 ~ FGx FlightPath R7 #12

Closed theo-armour closed 8 years ago

theo-armour commented 8 years ago

image

@fgx/owners

FGx FlightPath R7

Features

geoffmcl commented 8 years ago

@theo-armour this looks absolutely fabulous, except, as you point out the green flight path, the circuit, or cross-country path, does not even touch the runway, and seems slightly misplaced...

But that aside, you can see the runway, and clearly the valley to climb up after the takeoff and the left turn, up and over the lip, and the valley to come down for the landing... beautiful 3D stuff...

As stated, the 3D terrain rendering is fantastic... all the taller hills to avoid are there in plain view...

What can I do to help next?

theo-armour commented 8 years ago

@geoffmcl

Thank you for the kind words

What can I do to help next?

First, thank you for offering to help.

Here's what's really needed:

https://github.com/fgx/fgx.github.io/blob/master/sandbox/request-google-elevation-service/request-google-elevation-service-r3.html#L200-213

Currently gathers and then saves elevation data to text. But would be much more efficient to save to binary.

https://github.com/fgx/fgx.github.io/blob/master/sandbox/flightpath/fgx-flightpath-r7.html#L204-216

Ditto, better if could read binary.

It can be done. I've done it myself, but I really have to wrap my head around the process - whereas I believe you were binary at birth. ;-)

See https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/Sending_and_Receiving_Binary_Data

With smaller data files then we can move up to 1024 x 1024 3D meshes - much better detail than the current 512 x 512 mesh.

BTW, I will be explaining in detail how these files work together as and when the dust settles.

BTW2, here's what I created for your godchild Cynthia yesterday:

http://jaanga.github.io/demo/cba/snow-mountain-trek-april-2016/snow-mountain-trek-april-2016-r1.html

geoffmcl commented 8 years ago

@theo-armour well, I am not sure I understand...

Re: Elevation Lists

Looking using a binary list of elevation, versus your ascii list, does not gain you as much as I think you think, and depends on the data...

I wrote a quick test-bin C/C++ app to read the ASCII, and output first floats and later doubles...

For example your current elevations-512x512-r3.txt, contains 262144 elevations, with range in byte lengths, including the comma, of 2 to 6 bytes, so the file has a size of 1,572,863 bytes...

Converting that ascii to a float, and writing a binary file of floats, where each entry is thus exactly 4 bytes, the size of a float, the binary file would still be 1,048,576 bytes...

So yes, on this sample that is a reduction by 30%... Of course that would be more if the elevations were all bigger values... that is all with a length greater than 3...

BUT, the javascript reference you pointed me to appears to only have an 8 byte Uint8Array... that is I could not immediately find say a Uint4Array...

And if we write the elevations as doubles, that is each is 8 bytes, then, in this case the actual binary file size would be about 25% larger, at exactly 2,097,152 bytes, for a 512x512 array...

Of course, if you are talking about the transmission time over internet, then both the ascii and the binary files can be reduced to around 450 KB... a quite massive reduction... but then there is the time cost of expanding that... but I do not think you meant this...

But maybe I misunderstand something here... What do you exactly mean by a binary file?

Re: Track/Circuit Locations

Now because these always come in pairs, and to get reasonable positional accuracy we need about 5-6 decimal places for each, so these are big ASCII numbers, thus the Google scheme of converting them to like base64 ascii does make sense...

It does lose some accuracy in that they encode only up to a maximum of 5 decimal points... thus is lossy...

As their example shows, a list of just 3 point, here each expanded to 5 decimal places, can be quite good reduction...

Points: 38.51111,-120.21111,40.71111,-120.95111,43.25211,-126.45311
Encode:  _p~iF~ps|U_ulLnnqC_mqNvxq`@

So even in this simple sample we can see a length reduction of around 30-50%, which makes this worthwhile...

But this is encoded, not binary...

I took another slug at this today, and while my algorithm works fine for 90% of the lat, lon values, I can not yet get it working 100%... but will keep hacking at it...

Re: Cythia

Yay, that looks like a great trek up a snowy mountain ;=))

I assume the points were collected by a GPS tracker... wish I could have been there in my helicopter to do some filming...

theo-armour commented 8 years ago

@geoffmcl

But maybe I misunderstand something here... What do you exactly mean by a binary file?

Golly, who knows what actually lurks in my tiny brain?

Of course, if you are talking about the transmission time over internet, then both the ascii and the binary files can be reduced to around 450 KB... a quite massive reduction... but then there is the time cost of expanding that... but I do not think you meant this...

Yes, this is exactly what is needed - to be able to load larger data files with the smallest wait for the user.

And no matter how it's done is mostly OK - binary, encoded, zipped - all are good.

BTW, unzipping in your browser is really fast - so zip files are fine too.

More later

in the mean time have a look at

FlightPath R8

Camera just beginning to work