Update ~ 2016-07-12 ~ VNLK Flightpath R3

theo-armour commented 8 years ago

@geoffmcl

Nearly there. Still includes some of my idiosyncrasies.

Could be working more properly in next release

VNLK FlightPath

Change log 2016-07-12 ~ R3

Move all objects to their lat/lon and sizes in decimal.degrees ( ie 0.00001 range )
- Replaces bringing everything to near the origin with sizes in the 1 to 100 range ( ie typical CAD/CAM thinking )
Detail the menu
Code cleanup
Displays three flightpaths

theo-armour commented 8 years ago

@geoffmcl

VNLK Flightpath R4

What I am learning

Need to identify center of the elevations in the file name
Need to be able to produce elevation files that are not just squares
Need ways of adjusting the zoom level of the map overlays
Need to work out vertical scaling

Done

Flight paths are now drawn in their correct positions
Landscapes are not

geoffmcl commented 8 years ago

Hi Theo,

PS: Your r4 arrived as I was studying r3 ;=)) But will leave my initial r3 comments, and add r4 observations...

Ok, it is interesting that you add 3 paths! Great idea...

var flightPathFile = 'VNLK-01-cooked.csv'; // red var flightPathFile2 = 'VNLK-02-cooked.csv'; // green var flightPathFile3 = '6-25-2016-1-cooked.csv'; // purple/violet

First to talk about the three paths, relatively to one another...

These three points, red-top.right.bottom, green-bottom.right.bottom, and violet-bottom.right.bottom, being the VNLK runway, should share approximately the same position - ie same lat,lon,alt... ie same x,y,z... and through v( p[ 0 ], scale * p[ 2 ], p[ 1 ] );, assume that is a Vector3( x, y, z ), then x=lon, y=alt, and z=lat...

While they presently do (almost) share the same lon and alt - good - but why does the lat get so messed up? It seems to me they are all loaded by the same fetch and paint process, so why doesn't lat just work?

So in simple terms the three paths were not correctly matched north-south - ie lat!

But as I was writing this note you have published an r4, where they are now correctly relatively positioned... great step forward...

And then to talk about the 3 paths relative to the terrain... As mentioned earlier, they are high above the terrain, while those three above points should touch the terrain at VNLK... and then the lat,lon do not seem to correspond at all...

So to try to demonstrate the true relative lat,lon positions of the tile and the 3 tracks here is my usual 2D...

elev-tile-12 3034 1719-01

Notice, all 3 paths/tracks, go outside the main elevation tile...

The red goes many times south of the tile...
It is hard to see, the green also dips below the bottom of the tile... and
the third track goes both a little below the tile, and well to the north of the tile...

And in this zoomed in image, you see see ALL tracks start at the SAME place, VNLK runway...

elev-tile-12 3034 1719-02

So I still see this big positioning problem???

But you seem to be getting there... will wait and see ;=))

theo-armour commented 8 years ago

@geoffmcl

4.1 is up. Nearly there

theo-armour commented 8 years ago

Now r5 is up

geoffmcl commented 8 years ago

Hi Theo,

Now r5 is up

This is great!

The beginning point of each track exactly align... as they should/must... wsg84 after all...

But again the landscape lat fails, by just a few miles...

As far as I can judge, the shown track is a few miles north of where it should be... or the terrain is a few miles south of where it should be...

That is the origin, VNLK, is nearby... there is even a Google label, Lukla, which is where we should be...

Seems a small lat calculation change... where is this?

Regards, Geoff.

theo-armour commented 8 years ago

@geoffmcl

Seems a small lat calculation change... where is this?

The $64 question

I strongly believe the flight paths are located correctly.

I mostly believe that the map tiles textures are locating themselves reasonably accurately.

I am not at all sure that the center of the mesh and the lat/lon in the file name are correct and properly related.

On Thu, Jul 14, 2016 at 9:55 AM Geoff McLane notifications@github.com wrote:

Hi Theo,

Now r5 is up

This is great!

The beginning point of each track exactly align... as they should/must... wsg84 after all...

But again the landscape lat fails, by just a few miles...

As far as I can judge, the shown track is a few miles north of where it should be... or the terrain is a few miles south of where it should be...

That is the origin, VNLK, is nearby... there is even a Google label, Lukla, which is where we should be...

Seems a small lat calculation change... where is this?

Regards, Geoff.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fgx/fgx.github.io/issues/28#issuecomment-232725460, or mute the thread https://github.com/notifications/unsubscribe/AAhbKm0S3_iZO6zEIk8-tS9CrKrjmnbkks5qVmn7gaJpZM4JK2ig .

geoffmcl commented 8 years ago

Hi Theo,

Well, for sure the center of the mesh can not be easily be globbed from parsing the file name...

What you get from this is the center of a tile, within the elevation mesh... you would need more calculations to get the real center of the mesh, if reven,... or as usual, I do not understand...

But this does not seem to account for the nearly consistent lat failure, by just a few miles, both here, and YGIL... same direction... seems simple...

Regards, Geoff.

theo-armour commented 8 years ago

the lat/lon in the file name should be the lat/lon of the center of the elevations

currently the elevations are in a square.

The square root of number of elevations gives the segments per side.

a mesh with the same number per side is created

and its center is moved to the location given in the file name

then the time images are gathered and laid over the mesh

I'm currently working over in elevation get - with new file naming idea.

also adding better editing features

Have you tried importing your flight paths into Elevation Get?

On Thu, Jul 14, 2016 at 10:16 AM Geoff McLane notifications@github.com wrote:

Hi Theo,

Well, for sure the center of the mesh can not be easily be globbed from parsing the file name...

What you get from this is the center of a tile, within the elevation mesh... you would need more calculations to get the real center of the mesh, if reven,... or as usual, I do not understand...

But this does not seem to account for the nearly consistent lat failure, by just a few miles, both here, and YGIL... same direction... seems simple...

Regards, Geoff.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fgx/fgx.github.io/issues/28#issuecomment-232731202, or mute the thread https://github.com/notifications/unsubscribe/AAhbKlLZdGFOChRw5rdvzRkNlyNA1YBTks5qVm7ugaJpZM4JK2ig .

geoffmcl commented 8 years ago

Hi Theo,

the lat/lon in file same as center of the elevations

That sounds good, but just have not found it so... but as expressed this does not seem to be the problem...

That the lat seems diplaced by just a few miles!!!

Have you tried importing your flight paths into Elevation Get?

Yes, just tried this, and it seems to work perfectly...

Used 6-25-2016-1-cooked.csv...

Well, of course there is the forever problem that google wsg-84 is different to other wsg-84, so as seen in this zoomed in image, the takeoff and landing are a tiny bit diplaced... the yellow tracks are up and to the left of the gray runway image... just a number of meters...

http://geoffair.org/tmp/VNLK-01.png

This seems a known, documented problem... that I think we have to wear...

So how does this import correctly place the track, and it does not in the YGIL/VNLK?

Wow, I do not know ;=))

Regards, Geoff.

theo-armour commented 8 years ago

I don't know

Me neither. But it's great fun putting all these pieces together.

A few years ago it would have taken weeks and weeks to get here - for peeps with real CS degrees.

Now ordinary humans can do it.

On Jul 14, 2016 11:56 AM, "Geoff McLane" notifications@github.com wrote:

Hi Theo,

the lat/lon in file same as center of the elevations

That sounds good, but just have not found it so... but as expressed this does not seem to be the problem...

That the lat seems diplaced by just a few miles!!!

Have you tried importing your flight paths into Elevation Get?

Yes, just tried this, and it seems to work perfectly...

Used 6-25-2016-1-cooked.csv...

Well, of course there is the forever problem that google wsg-84 is different to other wsg-84, so as seen in this zoomed in image, the takeoff and landing are a tiny bit diplaced... the yellow tracks are up and to the left of the gray runway image... just a number of meters...

http://geoffair.org/tmp/VNLK-01.png

This seems a known, documented problem... that I think we have to wear...

So how does this import correctly place the track, and it does not in the YGIL/VNLK?

Wow, I do not know ;=))

Regards, Geoff.

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/fgx/fgx.github.io/issues/28#issuecomment-232759031, or mute the thread https://github.com/notifications/unsubscribe/AAhbKr8XSrMr3B3Q00_4PJTGvy-eh3XYks5qVoZFgaJpZM4JK2ig .

theo-armour commented 8 years ago

@fgx/owners

Not perfect alignment but quite good.

Thanks to Geoff for the paths are in feet heads-up!

http://fgx.github.io/sandbox/flightpaths/vnlk/vnlk-flightpath-r7.html

pedromorgan commented 8 years ago

Neat..

Soon theo when i have time.. we work on this an use templating... so we can make life easier...

theo-armour commented 8 years ago

http://fgx.github.io/sandbox/flightpaths/vnlk/vnlk-flightpath-r8.html

fgx / fgx.github.io