X-Plane Scenery Gateway

[zengei]

Zengei, I hope you don't mind that I pepper you with questions.

No problem.

4. GeoViewer loads the file, but it shows me a low-res picture of the entire USA, not Ernst Field or its vicinity.

You've likely selected one of the 100-meter resolution image of the US. The USGS will show all images that contain your selected location, this includes surveys of the entire country. You want to be picking images that have a 1 meter or less resolution.

What reason do you have to believe the JP2s are misaligned?

[Geoff]

Thanks for the info on the 100-meter resolution. I'll stop downloading those!

The .jp2 for Ernst seems to indicate the runway is 1000 feet shorter than listed on all Skyvector etc., and the .jp2 would locate it about a half-mile north of where XPlane has it. More worrisome, the .jp2's location does not at all match the location I see using Bing photoscenery generated by G2XPlane. (With Cashen, I used G2XPL to double-check that the .jp2's placement of the runway wasn't crazy. The .jp2 precisely matched where G2XPL placed the runway.)

That said, for both 38CA and this airport, I didn't bother with OrthoMagix: I simply opened the .jp2 in Lizard's GeoViewer, exported to .TIF (NOT at full resolution), and that file was small enough that WED could read it directly. In other words, I didn't have a "mega" tile I had to chop up with OrthoMagix, as these are tiny little airports. That shouldn't matter, should it?

In case it does matter, I exported the same .jp2 (this time at full resolution) into OrthoMagix and told it to "Do Magix." Er, half an hour later, it's still working on it. It says it's converting the image to WGS 84. I think it wants about 1G of disk space, which I've got.

I appreciate all your help. The hardest part of this process, for me, is getting the orthophoto reference. If that's not right, nothing's right. Once I have that, building the scenery is fun and relatively easy. Anyway, I appreciate your patience; thanks.

[zengei]

Thanks for the info on the 100-meter resolution. I'll stop downloading those!

No problem, that got me too once.

The .jp2 for Ernst seems to indicate the runway is 1000 feet shorter than listed on all Skyvector etc., and the .jp2 would locate it about a half-mile north of where XPlane has it. More worrisome, the .jp2's location does not at all match the location I see using Bing photoscenery generated by G2XPlane. (With Cashen, I used G2XPL to double-check that the .jp2's placement of the runway wasn't crazy. The .jp2 precisely matched where G2XPL placed the runway.)

Okay, downloading the JP2 myself, I realize what the problem is. The problem is that this particular JP2 uses a coordinate system that neither GeoViewer nor WED can natively map to lat/long coordinates. You can notice this in GeoViewer by mousing over the image and looking at the status bar in the lower left of the screen. As you mouse over, GeoViewer will emit your current mouse location as coordinates relative to the WGS_1984_Web_Mercator_Auxiliary_Sphere, however it will not emit any Lat/Long coordinates, because it doesn't know how to map coordinates against WGS_1984_Web_Mercator_Auxiliary_Sphere to lat/long. GeoViewer will happily export the image though whilst preserving the existing coordinate system. When you then go to import it into WED, WED doesn't know how to use that coordinate system either so it just places the image wherever your current viewport happens to be, and at that scale. That's why you see the runway misaligned and at a different size, WED doesn't know how to precisely place the image and what scale it should be. Unfortunately, WED does not make it super obvious that it can't place the overlay image based on georeference, I'll probably submit a bug to at least issue a warning or status message.

The good news is that it's pretty straight forward to reproject the coordinate system within the image to one that GeoViewer/WED can utilize to calculate lat/long. The bad news is that it involves using the command line GDAL tools, which can be a bit tricky if you aren't used to working at the command line. This post on the Org actually does a good job of going over the basics.

But for full details...

1. Download a GDAL tools binary distribution from http://www.gdal.org/ If you follow the appropriate links for Windows you'll eventually get to this page, download gdal-111-1600-x64-core.msi. Install it as normal.
2. You should now have a C:\Program Files\GDAL directory with a bunch of executables in it. For the sake of convenience we should add this directory to our PATH environment variable, so we don't have to reference the executables with their full path. This Java documentation does a handy job of explaining how to edit your path on Windows. Make sure when editing your path you just append C:\Program Files\GDAL to what's already there, you don't want to overwrite the entire thing.
3. While you're editing environment variables, add an entirely new one and name it GDAL_DATA and set its value to C:\Program Files\GDAL\gdal-data. This is used by the GDAL tools to reference some supporting data.
4. Now open a command prompt, either classic cmd.exe or PowerShell. Type gdalinfo and press enter. You should get some output like:

   Code: Select all

   Usage: gdalinfo [--help-general] [-mm] [-stats] [-hist] [-nogcp] [-nomd]
                   [-norat] [-noct] [-nofl] [-checksum] [-proj4]
                   [-listmdd] [-mdd domain|`all`]*
                   [-sd subdataset] datasetname
   
   FAILURE: No datasource specified.

   If gdalinfo does not execute, make sure your PATH is setup correctly.
5. Now change directory to the directory which contains the JP2 from USGS by running cd "<directory-path>", replacing <directory-path> as appropriate.
6. Now execute gdalinfo <jp2-file>, this should spit out some information with the fact that the projection is WGS_1984_Web_Mercator_Auxiliary_Sphere
7. Now you can reproject the image (and convert it to GeoTIFF simultaneously) by executing: gdalwarp -s_srs EPSG:3857 -t_srs EPSG:4326 -of gtiff <jp2-file> <output-tiff-file>. This command takes the source coordinate system "EPSG:3857" and reprojects it into a coordinate system WED can use "EPSG:4326", while simultaneously converting the JP2 into a TIFF.
8. You should then use OrthoMagiX to import the converted GeoTIFF and tile it for use in WED.

As a note, I've found that GDAL is much slower than GeoViewer when it comes to converting JP2s to TIFFs. So if you want you can use GeoViewer to do the JP2 -> TIFF conversion, then use GDAL to reproject that TIFF to the correct coordinate system.

EDIT: After all that, you get this in WED: http://i.imgur.com/Qrvt0Cd.png So the runway is misaligned, but not terribly.

SIDE NOTE: You might be asking what's the point of having different coordinate systems, why isn't lat/long just used? The problem is lat/long isn't really well defined. The Earth isn't a perfect sphere, so if you want to use a coordinate system based on a perfect sphere you need to arbitrarily choose one to represent the Earth, different people and organizations can choose different spheres for a variety of reasons and thus you get multiple coordinate systems. This YouTube video does a handy job of explaining it.

That said, for both 38CA and this airport, I didn't bother with OrthoMagix: I simply opened the .jp2 in Lizard's GeoViewer, exported to .TIF (NOT at full resolution), and that file was small enough that WED could read it directly. In other words, I didn't have a "mega" tile I had to chop up with OrthoMagix, as these are tiny little airports. That shouldn't matter, should it?

If you don't export with full resolution, you're limited to a max image size of 6600x6600, which means if the actual resolution is higher than that you're losing detail. So if you download a nice big 0.15m resolution image from USGS, you may end up with an image with a resolution of several meters instead, which can be very detrimental when working out the fine details of the airport.

In case it does matter, I exported the same .jp2 (this time at full resolution) into OrthoMagix and told it to "Do Magix." Er, half an hour later, it's still working on it. It says it's converting the image to WGS 84. I think it wants about 1G of disk space, which I've got.

Using this method OrthoMagiX didn't do any conversion for me and tiled the reprojected TIFF in about 15 seconds.

[Geoff]

What an amazing post, zengei! Thanks so much!

The photo you generated is exactly what I see using G2XPlane, and exactly what I expect: X-Plane has placed the runway slightly to the east of where it should be. That won't be a big deal to fix, as you say.

What's more, I managed to generate the exact same ortho-image on my own, replicating your results, without using the GDAL workaround you describe. I followed these steps.

(1) First, I re-did my USGS search, and I noticed that if I widened my selection area, USGS gave me a choice of two .jp2 files. One was m_3311625_ne_11_1_20140530_20140721.jp2; the other is m_3311626_nw_11_1_20140606_20140721.jp2.

(2) Parenthetically, when I load those into Lizard's GeoViewer now, I *do* see both Mercator AND Lat/Longitude coordinates when I mouseover the images for both .jp2s. (I'm using version 9.0.0.4211, 64-bit.)

(3a) Previously, when hitting CTL-O to open a layer and import one of those two jp2s, I was choosing the top (default) projection: WebMercator Native WGS1984. Then, when I exported, I was getting the misalignment we discussed earlier.

(3b) This time, I chose the second projection: simple WGS84.

(4) I then cropped a subset of the image (using the "Select Area" tool on the top toolbar, just left of the zoombar). I saved this sub-selection, giving it a name, and then chose "export bookmark."

(5) I then exported this sub-selection to GeoTIFF (this time preserving Full resolution and checking "write world file," which I assume is the crucial coordinate info).

(6) The resulting GeoTIFF was small enough that WED read it directly! No need for OrthoMagix at all. It imported immediately into WED, aligned at exactly the right spot, just as displayed in the .png in your post. (Essentially, X-Plane has placed the runway a few feet too far east, which is not a big deal.)

So is it possible that another workaround is to choose the simple WGS84 projection in GeoViewer rather than the default WebMercator projection? Also, for small airports, isn't it possible to bypass OrthoMagix altogether, simply by cropping the map in GeoViewer and exporting only the cropped portion?

All that said, I'm very glad to know about your GDAL workaround, because I'm not entirely sure what I did "right", or whether I just got lucky. In any case, I now have an excellent photo reference in WED.

As for full resolution: I'm not sure it makes a huge difference? You can only zoom in so far on these images, even in GeoViewer or the USGS website. With the full-res orthoimage I just imported into WED, things get equally grainy once I zoom in about 500 feet above the surface and closer.

Anyway, now I'm ready to build this little airport. One practical issue will be how to build taxiways. The orthoimage doesn't entirely make clear where the airport stops and where surrounding roads start. Google Maps indicates road names to the west of the field, but not to the east, which suggests to me that the curvy roads to the east of the strip might all be considered part of my airport. (Too bad I've never been to Ernst Field to know!) Things are complicated by the terrain, which rises sharply just east of the field. This airport is essentially built on the side of a hill. Anyway, those are fun questions that I'll answer partly by seeing how the terrain looks inside X-Plane, both with G2XPlane's photoscenery and with X-Plane's default scenery enabled. But if you have any advice, I'd certainly welcome it.

Thanks again for your excellent post! I'm going to cut-and-paste it and put it in my "WED info" folder.

[zengei]

If it works it works!

Also, if a cropped full resolution works, that's perfectly fine.

[Geoff]

And now I've submitted Ernst Field (86CL) to the Gateway. My submissions for KGCN (Grand Canyon) and 38CA (Cashen) have been "accepted" but not yet "approved" -- meaning they've been acknowledged but not yet assessed.

My next project: Baker Airport (0O2), in Death Valley, about 60 miles southwest of Las Vegas. It should be fun and straightforward, except for the segmented circle. Er, I guess I'll draw the circle with the taxiline tool or something? I know I can do white lines, but I'm not sure about red. I wonder if a thin facade object might work -- a series of red and white ones in a circle. Anyway, I recall zengei describing his wizardry with stuff like this, so I'll read back through the thread when I'm more awake.

What does Baker have in common with the others I've submitted? 38CA, 86CL and 0O2 are my three FBOs in Flight Sim Economy.

After Baker, I'll get back to work on 1G4, Grand Canyon West. I started work on it, then got distracted by FBO-acquisition. I've already made a fair bit of progress, so I'm hoping to have that done shortly as well.

[zengei]

Good work!

As for segmented circles, depending on the size, the usual options are:

1. Use roadway markings to approximate the circle.
2. Carefully craft each part with a "snow" taxiway.

Option 1 is faster, but Option 2 looks better, especially from the sky.

And there are no red markings that I'm aware of. In cases where something just isn't possible to do with the current tools/objects WED and X-Plane give us, I usually make a note in a text file so that I know what needs to be updated if/when WED/X-Plane supports it.

[Geoff]

Thanks for the advice. Maybe I'll try the "snow" taxiway. Could one approximate the red with a "dirt" taxiway or such?

[stevekirks]

This post by zengei (Dwayne Bent) above in this thread is why I love this community so much. Absolutely well written and compelling enough for me to stop skimming and start reading. Thanks Dwayne for taking the time to write everything out.

Steve

[zengei]

This post by zengei (Dwayne Bent) above in this thread is why I love this community so much. Absolutely well written and compelling enough for me to stop skimming and start reading. Thanks Dwayne for taking the time to write everything out.

Thank you, and no problem.

This weekend I'll try to finish one or both of KAJO and KVCV, before KSP 1.0 is released and I hear its siren song again.