Elevation data for FGx Flight Paths

[theo-armour]

Update 2016-07-12

New Link

Get Elevations

@geoffmcl

This message is in reply to your FGx Google Groups message

This is if nothing else because GitHub issues allows you to paste in screen grabs - and it uses Markdown, which I am getting to like.

---

Compare and contrast:

Screen capture using PNG USGS 1 Second Viewer 3D unFlatland R1 - centered on vicinity of San Francisco Bay Bridge on ramp

Screen capture using data obtained by Google Maps API Elevations for Tiles - with San Francisco Telegraph hill at top right

The two images above compare 3D plots created from USGS 1 second data and from current Google Maps API data.

The data for the former took hours to source, download, manipulate, commit and upload. The data for the latter was comparatively easy to acquire.

The results speak for themselves.

---

More in response to you email is the following. And is what I think can go in the read me:

Terrain elevation data is a complex topic with a voluminous pedigree. The FGx mission is to help access be faster, cheaper smarter

See also: Digital elevation model.

The bullet points include:

• Supply elevation data for the entire globe
  • Including bathymetric (ocean) data
  • At the most accurate resolution currently available
  • Including data with accuracy of 60cm or less when available
  • Including data being averaged appropriately for every zoom level
  • Not picking random points and hoping the points are close to the average
  • Not using image-processing algorithms that may or may not generate correct interpolations
• Make the elevation data accessible via a web browser connected to the internet
  • No downloading and saving. It just works
  • No translations necessary
  • No programs to install and run in order to complete the process
• Your choice of data
  • Select any latitude and longitude
  • Select zoom level and number of tiles
  • Select number of samples per side
  • Take as much or as little data as needed
• Eschew data updating and maintenance, file uploads, gargantuan data repos
  • No need to access multiple weird server setups to obtain data files
  • No need to check if data sources has been updated, moved or discontinued
  • No need to modify data, deal with big/little-endian issues, shift byte size or whatever
• Data is available from source and goes straight to user
  • No need for 'middleware' data stores
  • No need for shared data repositories
  • No hassling with git add, commit and push for data files
  • No dealing with GitHub usage rate limits, repo size limits and file limits
• Coding skills needed are beginner level
  • All algorithms very basic JavaScript
  • Relevant code is a few hundred lines
  • May be assimilated by a new user in less than and hour
  • Fork or download the HTML file and it just runs
  • No jQuery, Node or any other dependencies apart from Google Maps API

I would be pleased to hear what bits are unclear or too much of a jump here.

---

So the DEM data we have already - as you point out - is cool. But the 1 second data is only available for a tiny portion of the globe and is above sea level only.The 3 second data is available for the globe but sucks for rendering areas smaller than a 100x100 or so kilometers.

We need more, newer and better.

---

Google Maps API Elevations for Tiles

Click on 'Get Elevations'

---

Explaining what's happening is as important as making what's happening. Thank you for pushing for the rationale behind the actions.

Theo

[theo-armour]

@geoffmcl

From your email:

Is the implied first image obviously inferior to the second true?

Does, really, The results speak for themselves.? I do not exactly know yet... but can listen why...

While, I do prefer the softer cyan mix, with purple for elevations, shown in 2... than the heavy reds in 1... but what has this got to do with the underlying DEM data information?

OK, let's try again. First, please note that this exercise is not at all about coloring. Both meshes use a variety of 'normal' material - a generic surface or texture for 3D meshes that keeps things simple because no lights are required.

What the demos are about is resolution or accuracy or fineness of detail. The two images show Alcatraz island in San Francisco Bay.

Screen capture using PNG USGS 1 Second Viewer 3D unFlatland R1

Note that the model shows only sea level and above and that the rendering is fairly indistinct. It is unlikely that zooming in will show more detail.

Screen capture using data obtained by Google Maps API Elevations for Tiles

See also Alcatraz R1

Note that full bathymetric data is available and visible. Note that the model shows more detail. It is likely that zooming in and increasing the sampling rate will display more detail.

Do these two views help you understand the differences between what is available on static USGS data and what seems to be available now in 'cloudy' places? We should also look into MapQuest, OSM and other sources

---

http://fgx.github.io/sandbox/flightpath/fgx-flightpath-r13.html Will repeat, model too large for scene

Future rev will have slider that enables you to update the scale. Also may some kind of auto-scale depending on whether you are chasing or in world view. Also select your type of aircraft from the FGx aircraft library. [Yup, your b52 can fly like a c172]

... orientation wobbly

Currently reading roll, pitch and yaw from the CSV file

---

Got hung up today on getting map tiles and geometry to register on top of one another correctly plus the usual JavaScript asynchronicity issues (which I find fascinating)

But the next gen if FGx Flight path is on its way!

[theo-armour]

New Link

Get Elevations

[theo-armour]

@geoffmcl

Will be working on fixing this script - given the issues I have learned from work on YGIL and VNLK flight paths...

[geoffmcl]

Hi Theo,

Elevation files: So far, two examples...

1. elevations_27.6730_86.7171_z12_t5_250x250_vnlk-both-paths.txt
2. elevations_-31.7108_148.6392_z15_t11_200x200_ygil-01.txt'

Just a question about your elevation file naming conventions, and what they mean... some seem obvious -

1. A _latlon reference - Where is this exactly, in relation to the set of elevations? Center, TL,...
2. A zoom - z12 - Assumed zoom factor
3. Then t5 - What is this?
4. 250x250 - Elevation array size

Now, using the lat, lon, zoom, we can get the mappy tile directory... that is /z/x/y.png... functions lon2tile and lat2tile... gives us the slippy x and y...

Assuming all that is correct, now we have the exact boundaries of the elevations... can get an UL lat,lon, and a LR lat,lon... can get center, etc... and this can be used to size and position this square of elevations... at least as far as the x,z (lon,lat) positioning...

Now, after processing this set of elevation, we can get the min and max elevations... and thus should be able to set y... the alt...

And yes, so far both have been square... since this matches a slippy tile that is also more or less square... Why would we need elevations in other than squares...

Yes, if the scene covered by the path, the track, covers several slippy tiles, assumed touching, at least one point shared, or one side shared, then we also need an elevation squares to cover these other slippy tiles...

Yes, they could all be stored in a single elevation file, say like 250x750, that is a vertical strip, like needed for VNLK paths for instance... But that would take some extra work to extract a square of elevations to be applied to each slippy tile...

Or have I got something real wrong here??? I feel I am not understanding something...

[theo-armour]

@geoffmcl

See the read me on file names

https://jaanga.github.io/cookbook-threejs/examples/google-api/github-api-menu-of-readme-files-r1.html#elevations-get/readme.md

Or in any script, click the 'i in a circle' to go to the read me. I try hard - and fail- to keep these up to date

---

Still coding - more talk later

[geoffmcl]

Hi Theo,

Understanding the File Name convention...

https://jaanga.github.io/cookbook-threejs/examples/google-api/elevations-get/elevations-get-r2.html

https://jaanga.github.io/cookbook-threejs/examples/google-api/github-api-menu-of-readme-files-r1.html#elevations-get/readme.md

Yes, that says, a few words, repeated here -

Using file names to convey essential meta data. Is this a good thing?

Example elevations_-31.7300_148.6392_z12_t4_500x500_.txt

This gives: latitude, longitude, zoom, tiles and samples. Tile numbers
could be given instead. This would save some calculating and might avoid an
error or two. But nobody knows tile number and lat/lon is familiar to all

1. Is this a good thing?

Well, without some meta data to describe the file, the elevations are absolutely meaningless... without knowing what part of the earth it described, elevation wise, then the file is just rubbish...

At least the saved name should give some clues ;=))

1. tiles t4

Ok, I had missed that completely! My bad! I learn...

And as I study, test - https://jaanga.github.io/cookbook-threejs/examples/google-api/elevations-get/elevations-get-r2.html more I find a strange, Theo algorithm...

If I use Tiles: 1 I get what I expect, one(1) mappy tile... no problem...

If I use Tiles: 2 I get a 2x2, ie 4 mappy tiles, with my lat,lon in the 4th tile... ok, can learn, this is the way of life... my point of interest is in the bottom right tile... the 4th tile, counting top left to right, and down eahc line, ... not obvious...

If I use Tiles: 3 I get a 3x3, ie 9 mappy tiles, with my lat,lon in the 5th tile... that is quite reasonable.. it is the center... maybe the readme.md should explain more...

If I use Tiles: 4 I get a 4x4, ie 16 mappy tiles, with my lat,lon in the 12th tile... Well, again I can learn that, but why the map left/up inclination... a Theo algorithm ;=))

If I use Tiles: 5 I get a 5x5, ie 25 mappy tiles, with my lat,lon in the 14th tile... Well, that is resonable, in that, that is the center tile...

etc... It is only the even numbers, with the Theo go left-up algorithm, that troubled me for a time... but once accepted, agreed, written in stone, then, yes, this is a great meta file name convention, that is good, required, and necessary...

So I learn the _tnn_ part of the name, alerts you to the respective elevation array expected...

I will so adjust my 2D display of the elevations to obey these rules...

As you can understand, without this, I was previously treating the elevation file as covering a single mappy tile... ignored the tnn... stupid me...

Regards, Geoff.

[theo-armour]

@geoffmcl

A's you surmise, the elevations part is easy. We can get all the elevations we need in the area of one tile. Just zoom in and out as you like.

The issue with the file names has to do with giving a good indication as to what image tiles can be used. The elevation data may be just one zoom level 12 tile, but we want a 16x16 grid of zoom level 15 images overlayed over the mesh. The current filename system is there to guide that process.

A better alternative might be just to provide upper left and lower right lat/lons in the file name. Then the user/script could decide at runtime what zoom level and tiling to use.

I will be looking into this alternative.