geoffmcl commented 8 years ago

New Flightpaths

This addresses #22, a little...

This is a great demonstration of rendering a flight track in 3D... thank you Theo... it is beautiful...

I now have two more interesting flightpaths to add, VNLK and VHSK, and only ask what files you need added to do this...

At this point I have recorded the FGFS flights in csv, which has many, many values, but 3 of which can be easily extracted - namely lat, lon, alt - which can be presented in any form possible... What do you need? What is the best?

One of the many values included is the exact model orientation... roll, pitch, ... at present this seems calculate for track turns, descending, ascending... but these model values are included in the raw recorded csv file... not yet used...

In examining the last FGx FlightPath R13, it is near perfect... really thanks... it is like a real time video of a sim flight... that is the aim...

So I guess I seek the API to add other flights... some simple menu selection... to switch flightpath viewed...

Minor Feature Requests:

The model be at least 75% smaller... the wing of the model must not cut through moutains it flies near...
Auto-rotate defaults OFF. There is enough visual stimulus, without adding more...

But even without those requests, what should I upload to add these two new exciting, mountainous, FlightPaths?

geoffmcl commented 8 years ago

In reviewing the current flightpath more, would add 2 more Feature Requests...

Go back to (I think) the 512 resolution... avoid 2 google ad bands...
Do we really need a wireframe toggle... do not see the benefit to users...

But as stated, superb 3D rendition of a recorded flightpath... thanks... **How to add more?***

theo-armour commented 8 years ago

Hi Geoff

Greetings from San Luis Obispo

On Fri, Jun 17, 2016, 4:37 PM Geoff McLane notifications@github.com wrote:

In reviewing the current flightpath http://fgx.github.io/sandbox/flightpath/fgx-flightpath-r13.html more, would add 2 more Feature Requests...

Go back to (I think) the 512 resolution... avoid 2 google ad bands...

Do we really need a wireframe toggle... do not see the benefit to users...

But as stated, superb 3D rendition of a recorded flightpath... thanks... How to add more?*

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/fgx/fgx.github.io/issues/23#issuecomment-226905265, or mute the thread https://github.com/notifications/unsubscribe/AAhbKgutQZ-8rqu5jMHqddbUqcNIfA9Yks5qMy-jgaJpZM4I4zc7 .

theo-armour commented 8 years ago

@geoffmcl

Oops previous message sent before completed.

http://jaanga.github.io/terrain-viewer/un-flatland/r11/un-flatland-r11.html#start=0#camalt=500#camlat=34.673808317999594#camlon=-120.5859375#lat=35.2#lon=-120.6596#tarlat=35.173808317999594#tarlon=-120.5859375

I'm here with my three daughters.

Yay for the two new flight plans.

Flight Path Data

What FlightPath uses currently is this:

https://github.com/fgx/fgx.github.io/blob/master/sandbox/flightpath/LEIG-L1500-cooked-01.csv

But, if we eventually want to show everything that will be seen on the dials then we need to practice with all the data to be shown.

And, perhaps more important, we should be reading and writing to flight sim industry standard formats that devs can produce fairly easily using existing tools

Is there a standard flight sim ASCII format for flight path data that we should be concentrating on?

Mesh Resolution

I hear you that the jump from 512x512 to 1024x1024 vortices per mesh added little to the quality of the view.

Rather than just dropping back to 512x512, the next step will be to have the mesh cover a broader area. Thus there will be wider margin of visible terrain surrounding the flight path.

Google Band

The appearance of the bans is a work-in-progress. Without at least one band there will be more copyright issues.

Flight Path Data

Re: flight sim industry standard formats

You will have to remind me what those are, but sure...

From the initial FGFS cvs record of a flight, using the generic playback XML protocol, at 20 Htz, means every format is possible... I presently extract just 3 fields, lat, lon, alt, but it has some 74 other fields, that could be used...

Just tell me the format, if such a beast exists... and it can be done...

Mesh Resolution

Just saying that I saw no gain in this increased mesh resolution, but not a problem...

Other feature requests

reduce model size... the wing must not cut the close terrain...
model orientation - some weardness in the current. Is it not possible to use the csv facts?
wiremess toggle does not seem to add anyhting...
default auto-rotation is ok, but a lot to take in..

More in the coming week...

Sure, no problem... when you get the chance... thanks...

geoffmcl commented 8 years ago

Oops, sorry for the delay...

Have now pushed 3 new tracks - 2 are in the spectacular mountains around VNLK... should be great

The other is YGIL, to see how the flat plains look ;=))

Just the 'cooked' csv files - 6-25-2016-1-cooked.csv, VNLK-02-cooked.csv, YGIL-01-cooked.csv - hope that is enough...

theo-armour commented 8 years ago

@geoffmcl

Should have something up soon!

theo-armour commented 8 years ago

New flight paths are cool.

More, more, more. Pretty please! ;-)

Flight path data. How bout adding a UTC time stamp to each line? Then we could replay at the sane speed as the original flight?

geoffmcl commented 8 years ago

Wow, a full restart - http://fgx.github.io/sandbox/flightpath2/

Can not wait to see the 3D terrain added back ;=))

Hmmm, concerning the model speed... Well, the original fgfs generic protocol is recorded at a fixed Hz... I think each of mine were at 20 Hz - that is 20 lines per second - but will have to check what Jasin used, and check what I do when generating the cooked version...

Ok, my fg-play-02.pl 'cooked' generator script only removes records that have no altitude, ie = -9999, but it also has an option to ignore records below a user given IAS kt, but in essence it keeps all records... ie maintains the same Hz...

But I agree this is not a good way to do it... each nn records is one second... but works...

Now I find there are at least two fgfs time nodes that could be added -

node - /sim/time/elapsed-sec - a double - ie 1567.123456
node - /sim/time/gmt - a string - 2016-06-29T06:26:37

So do we need the more accurate double, relative time, or is gmt time string enough accuracy... ie which would be better here?

theo-armour commented 8 years ago

@geoffmcl

Thinking out loud:

Elapsed time - with just, say, tenths of seconds - could make for shorter files

GMT time means we could display the sun at its correct azimuth and altitude, weather conditions and other attributes. And even multiple aircraft

So let's go for GMT...

Wow, a full restart - http://fgx.github.io/sandbox/flightpath2/

When scripts are just a few hundred lines - and mostly cut and paste - it just seems to be more fun and more productive. And, somehow, each time the new scripts seem to do more, get shorter and go faster. This modern way of doing things is freaky. ;-)

geoffmcl commented 8 years ago

@theo-armour well I had continued to check this... also thinking out loud...

I can understand the idea of sun, and other things that could be implied from a gmt string, but it is a tad more complicated than that...

When I start the sim usually I add an option --timeofday=noon... this is because the airport I have chosen, say VNLK, in Nepal, could be in darkness at the time I run the sim...

Checking the gmt value now, at 17:30 GMT/UTC, the gmt string shown in the sim is 06:20? Maybe that is correct UTC for noon there... and is thus ok... Nepal is +5:45 so that seems about right... so yes, I think we could use that gmt string...

On the other hand, just appending say an integer seconds is easy for my cooked generator... as you say this keeps the file size smaller... That is I just bump the seconds counter each 20 records... so, in the short term this is easy to do...

It means I could regenerate each cooked right now from the raw and this time a seconds integer is added to the small set there... I know the Hz... or assume 20 Hz for each...

The other problem with the gmt solution is that I have to write, and use a different protocol.xml file for the csv generation... of course that would be already in the 'cooked' form, plus a time, so it cuts out one step... but that will take more time to write, test, and more importantly, regen by re-flying the trip, etc... lots of steps...

So how about a simple relative seconds integer appended to the cooked...

But also in your javascript you could do the same thing to get some sense of time from the 'cooked' csv already there... just divide record number by 20 equals secs elapsed...

Will continue to explore...

theo-armour commented 8 years ago

@geoffmcl

So how about a simple relative seconds integer appended to the cooked...

OK

And we can add a menu prompt that allows you to set a departure date and time of your choice for any flight path - with default being noon. How about a bit of night flying in the Himalayas?

just divide record number by 20 equals secs elapsed...

Good thought!

So why don't I try this first? If there are issues, then we can add the elapsed seconds...

The other issue is scaling the width and height of the map tiles to match accurately the flight path data.

I will prepare a small demo that illustrates the issue.

Sunny things:

https://ladybug-analysis-tools.github.io/ladybug-web/analemma-3d

geoffmcl commented 8 years ago

Yes, when I read this scaling issue earlier, I did not understand the problem...

I note you have added a great 3D bounding box of the flight... this for sure gives you the min and max lat,lon... that should translate into a set of map tiles...

Now I assume the map tiles come in fixed x,y,w,h blocks... via the particular api in use at that time, so is it just the question of the maths to take the track min,max, and applies that to the sorted of fixed map coordinates... could maybe help in that, if that is the problem... but maybe something else...

Maybe your demo will make it clear ;=))

theo-armour commented 8 years ago

@geoffmcl

so is it just the question of the maths to take the track min,max, and applies that to the sorted of fixed map coordinates.

Yes, just the math...

The 256 pixels width and height for each map tile represent different amounts of lat and lon distances - the whole projection thing.

The width and height of the tiles need to be scaled in order to match the linear lat/lon numbers given by the flight path.

We have lat to tile, tile to lat etc. Now we need a tileX to scaleX. Math should not be too tricky. I just have not done it yet. And your help would speed things up here

Demo will help show this in more detail.

theo-armour commented 8 years ago

@geoffmcl

The demo - which I thought would be quick to do is now a work in progress. ;-(

See:

Path and Tile Mash-Up R1

The source code has some relevant comments regarding scaling the tile and path.

It just brings up a single tile - to keep things as simple as possible for the moment. Later it will go back to multiple tiles.

geoffmcl commented 8 years ago

@theo-armour ok, had to go back a few years to slippy map path generation...

So I wrote a perl script, cookedcsv.pl, to read the CSV, in this case VNLK-02-cooked.csv, and do the similar calculation using the services I created in 2014 exploration of this, in slippydirs.pl...

It confirms you have correctly identified the tile, /12/3034/1719.png, but it is loaded incorrectly, relative the 3D track bounds... I will try to load a 2D representation, adding the VNLK runway -

vnlk-02-1

As you can see the southern track boundary should be just below the bottom of the tile... see the gray and yellow lines a below the bottom of the tile, signaling in this case we need another tile to cover that...

And you have positioned the track so that it corresponds to the right edge of the tile, but you can see in my 2D rendition, the right and left bounds of the track - the gray - are within the bounds of the tile - the blue...

And you have scaled the tile to be less in height, than in my calculations, which also could be wrong!, but the tile is at least 1/3 more in NS distance than the track...

How so I get all these number? Well hopefully the perl will explain it all ;=))

    my ($x,$y) = getTileNumber($lat,$lon,$z);
    my $dir = "/$z/$x/$y.png";
    prt("PNG: $url_base$dir\n");
    $xg .= "# PNG: $url_base$dir\n";
   # get the four corners
    my ($tl_lon, $tl_lat) = getLonLat($x+0,$y+0,$z);
    my ($bl_lon, $bl_lat) = getLonLat($x+0,$y+1,$z);
    my ($tr_lon, $tr_lat) = getLonLat($x+1,$y+0,$z);
    my ($br_lon, $br_lat) = getLonLat($x+1,$y+1,$z);
   # add the 4 corners
    $xg .= "color blue\n";
    $xg .= "$bl_lon $bl_lat\n";
    $xg .= "$tl_lon $tl_lat\n";
    $xg .= "$tr_lon $tr_lat\n";
    $xg .= "$br_lon $br_lat\n";
    $xg .= "$bl_lon $bl_lat\n";

The getTileNumber and getLonLat are -

sub getTileNumber($$$) {
    my ($lat,$lon,$zoom) = @_;
    my $z2 = 2 ** $zoom;
    my $xtile = int( ($lon+180)/360 * $z2 ) ;
    my $ytile = int( (1 - log(tan(deg2rad($lat)) + sec(deg2rad($lat)))/pi)/2 * $z2 ) ;
    return ($xtile, $ytile);
}

sub getLonLat {
    my ($xtile, $ytile, $zoom) = @_;
    my $n = 2 ** $zoom;
    my $lon_deg = $xtile / $n * 360.0 - 180.0;
    my $lat_deg = rad2deg(atan(sinh(pi * (1 - 2 * $ytile / $n))));
    return ($lon_deg, $lat_deg);
}

So, once I get the slippy x,y for a particular lat lon zoom, I just get the 4 corners of the tile, bottom left, bl, tl, tr, br, by adding 1 to the x and y, respectively, and I have my blue outline...

Now I already see most of this math in your javascript, with lon2tile/lat2tile, and this looks fine... and then your tile2lat/tile2lon, where you likewise add 1 to get your ULlat/lon and LRlat/lon and have to yet exactly compare those to my values below -

# PNG: http://a.tile.openstreetmap.org/12/3034/1719.png
color blue
86.66015625 27.6835280837878
86.66015625 27.7613298745052
86.748046875 27.7613298745052
86.748046875 27.6835280837878
86.66015625 27.6835280837878
NEXT

So either yours are the same, or close to the same, as mine, then it is how it is then positioned in the scene...

Or they are quite different, and one, or both, our maths sucks ;=))

Still, exploring but may be out for a while...

geoffmcl commented 8 years ago

Ok, it seems out maths agree - the red line is from your UL to LR, and it seems to fully agree with my blue box...

vnlk-02-2

So this seems something about how they are relatively sized and positioned in the scene...

theo-armour commented 8 years ago

@geoffmcl

Or they are quite different, and one, or both, our maths sucks ;=))

Will add links to my sources later today. We stand on the shoulders of giants.

So this seems something about how they are relatively sized and positioned in the scene...

Bingo!

The current position issue is of my own making. I will be correcting this issue soon.

Up for grabs is the scaling.

Perhaps the top question is this:

Which is the more appropriate way to scale:

Scale the map to the flight path or scale the flight path to the map?

geoffmcl commented 8 years ago

@theo-armour well I, for sure. do not know the full answer...

But we are trying to display, in 3D, a single FightPath... a track we know, after loading, the full limits...

The map, or maps, background, become a little irrelevant, but very important... added reality to the scene... added information, ... so somehow, it seems the bounding box of the FlightPath is the only relevant object... that is what we are trying to display...

So yes, we can zoom in, or out, and rotate the scene, but by default, the current 'FlightPath' box should default to center stage...

So in a way, that flights bounding box, plus perhaps a 10-20% smudge factor, should be where we start the view...and that smudge factor is also important... always begin with slightly more...

But I can understand, maybe we should focus on the map, or maps, that this particular FlightPlan traverses... but given that the set of slippy maps, pngs, needed to cover this specific FligthPlan, will always be larger, especially if we include all tiles covered at this zoom, then it means we are showing more than the specific track...

Like I say, really do not know the answer, but somehow I would concentrate the default view to the FlightPaths bounding object, plus some smudge factor... if that makes sense...

theo-armour commented 8 years ago

@geoffmcl

I'm currently working on obtaining the elevation data using the Google Maps APIS for any area in a simple way.

Once that's done, then we can see the whole thing in 3D and then decide how much judge is needed...

geoffmcl commented 8 years ago

Just added another flighpath... I had excluded it before because I overrun on the landing, and hit the wall... but later I realized the VNLK-02 I did add is also an interrupted flight... so this is a better one...

I just wrote, in perl, an expand bbox by say 20% function, and like that idea.

It will be very usual that the main point of departure and arrival - the airport - will most likely be at some edge of the track bbox, so this expands that track bbox to ensure that important point, VNLK in this case, is a little in from every edge...

Not sure I understand why you need the elevation data... and we have excellent SRTM file sets for that... The Google maps API I played with was the TERRAIN, which seems a 3D mesh, with satellite imagery painted on... Or you want to build your own terrain mesh from the raw elevation data, and lay whatever map you fetched over that... quite lost...

But I am sure there is lots of method in your madness, so will wait and see ;=))

I did try to get into the js, how, and where, the 3 objects - track, box, tile - are are placed, scaled???, but got lost somewhere... seem missing some important idea, or something...

Anyway, look forward to the next ;=))

geoffmcl commented 8 years ago

PS: Did I mention I put some of Jasin's tracks on my google maps... using the kml I also generate...

https://www.google.com/maps/d/u/0/

Like VNLK-J-02

You can really see how magnificent the terrain is...

theo-armour commented 8 years ago

@geoffmcl

I will be adding a generic KLM reader to Flightpath - at some time in the future. See

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

Very slow. Could do better now

\

Your Google Maps link actually sent my to my Google maps. It's a general link - and not specific to any of your maps - but the VNLK link worked.

Even more fun on the way: http://fgx.github.io/sandbox/get-elevations-update-plane/vnlk-r1.html

geoffmcl commented 8 years ago

@theo-armour sometimes I think we are on the same page, but there are maybe big deviations... no problem...

I suppose my simple aim here is :-

Well to display a recorded FlightPath, in 3D, with what we can learn from that flight...

In real detail, being able to review at what height I rotated on landing, to be able to be do better next time... to see at what speed I rotated on takeoff... my min/max flying speed/alt/agl... hud display... etc, etc...

A review and learning experience... not a tour of the region... in 3D, real time... fantastic...

Presently we are using an interface between the generic protocol output of a real sim FGFS flight, with a little perl massage, producing some cooked csv file, that allows you to re-display that flight in 3D... all that can be discussed, modified, improved, extended... just tell me what you need...

Yes, a fgfs generic protocol recorded CSV flight can also be massaged as a KML file, but that display is not what I seek... anyway, we have google earth and maps for that... thanks...

Sorry, I do not play enough with Google to even correctly report the correct URL, so you, and others, can view my maps... that is not my aim, or interest... a stupid distraction even...

And sorry, I hope you never add a generic KLM reader to Flightpath! That is not desired...

And perhpas some kml slowness is more to the massive verbosity of KML format, to describe a simple track... than to how well you can load, decode, and display it...

So yes - VNLK-R1 - loads the elevations for the area of interest, and displays a great 3D mesh... beautiful... and...

But where is my FlightPath? with model, orientated per the csv, speed from the csv... etc...

As suggested earlier, the flight track should center of the default 3D scene displayed...

So yes, VNLK-R1 looks great... seems to correctly show the TERRAIN... that is good... bravo... yippee...

But as stated where is the FlightPath?

It is back to what I suggested earlier - the bbox of the flight must set the default scene - not the other way round...

fgx / fgx.github.io

Adding a new FlightPath #23

New Flightpaths

Flight Path Data

Mesh Resolution

Google Band

Flight Path Data

Mesh Resolution

Other feature requests

Path and Tile Mash-Up R1