Hi Andrew:
Google Earth / Google Maps, like most imagery tile servers, display maps in "
Spherical Web Mercator - EPSG code 3857" which is "close" to UTM, but slightly
different than UTM, and therefore is not warped / rotated by being displayed in a WGS84 datum format.
http://alastaira.wordpress.com/2011/01/23/the-google-maps-bing-maps-spherical-mercator-projection/
The imagery download for use as a "background map" in SBuilderX is thus displayed in the same original projection
until processed for use with FSX SDK Resample to create custom photo-real land class tiles.
FYI: Refer to a Geo-TIFF's GIS information / Pixel Rows / Columns / Geo-referencing parameters and Projection in Global Mapper via:
Global Mapper Menu > Tools > Control Center > [
select GeoTIFF aerial imagery layer of interest]
> Metadata button
It is probably better to perform edits on aerial imagery in UTM projection, especially in areas farther North from the equator, as the WGS84 Datum is "warped" more in such locales.
However, ultimately,
every source file must be "re-projected" to:
Geographic (Lon-Lat) Projection / WGS84 Datum / Arc Degrees Planar Units
...prior to being submitted to FSX SDK Resample.
CAVEAT: IMHO, before editing a GeoTIFF in a graphics app, it is best to:
1.) Back up the original GeoTIFF image file
2.) Backup the original GeoTIFF Geo-referencing info (aka "Geo-tags") and/or *.TFW "world" file
3.) Do
not change the pixel dimensions (aka "Row / Column counts") from that of the original GeoTIFF, as the Geo-referencing and projection of the imagery in that GeoTIFF is inter-related with the original pixel dimensions.
After editing a Geo-TIFF in a graphics app:
1.) Restore the original GeoTIFF Geo-referencing info and/or *.TFW "world" file
2.) "Re-project" the Geo-TIFF(s) to:
Geographic (Lon-Lat) Projection /
WGS84 Datum /
Arc Degrees Planar Units
...prior to being submitted to FSX SDK Resample.
BTW: If you are slicing and/or merging segments of aerial imagery in GeoTIFF format via a graphics app (thereby changing the pixel dimensions aka "Row / Column counts" from that of the original GeoTIFF), those resulting saved images must be manually Geo-referenced / Geo-rectified when opened in Global Mapper.
NOTE: This extra step may reduce the geographic placement accuracy when output via FSX SDK Resample.
IMHO, it may be best to instead, slice and/or merge segments of aerial imagery in Global Mapper while keeping the pixel dimensions of source GeoTIFFs
unchanged during any editing.
To Backup and Restore the original GeoTIFF Geo-referencing info (aka "Geo-tags") and/or *.TFW "world" file info:
* Use a GIS Geo-tag / world file utility, such as the one in FWTools, as discussed in this WIKI:
http://www.fsdeveloper.com/wiki/index.php?title=GeoTIFF_file_creation_with_FwTools
...and in this thread:
http://www.fsdeveloper.com/forum/showthread.php?t=354228&highlight=FWTools
IIRC, Lance has previously also linked to a 3rd party freeware GIS utility which can perform some helpful functions when working with GeoTIFFs, but I can't recall where to find that thread.
As Lance, Holger, and others have pointed out in other threads, a significant benefit of still creating *.INF files with explicit dimensional parameter values is that such dimensional parameter value info can otherwise be stored visibly in the *.INF file for
future reference in creating derived (
but sized identically to the original !) raster and/or vector content such as terrain masks etc. which need to be re-rectified after graphical processing.
This might be a
preferred workflow ...rather than using a simplified *.INF file which defers to FSX SDK Resample's reading the internal Geo-Tags of the Geo-TIFF file during input processing of source files to identify what extents to use, but not documenting the processing parameters actually used anywhere that they can be later reviewed.
PS: Andrew, could you explain a bit more what you were referring to, when you mentioned "
render.exe" ?
Hope this might help clarify a few things.
GaryGB
