Discrepancy between ADE and Google Earth

[johnor999]

Hello,

I noticed that I couldn't make a runway fit properly against my background images.
It's as if the scale is wrong somehow. To test this, I placed two nodes at coordinates N63.798411, E020.268956 and N63.782811, E020.30142.
After that I measured the distance between those two nodes in ADE and then Google Earth. The distances were:
ADE: 2357 m
GE: 2363 m

It's the same on versions 1.75 and 1.77.

Is there any particular reason for this?
The currently installed build is 1.77.7282.

 

[GaryGB]

Hello:

Aside from having a project location North of 60 Degrees which would increase projectional distortion in WGS84 imagery, you would likely want a "less" distorted result by NOT re-projecting imagery to WGS84.

[EDITED]

Although Mercator-type GIS projected imagery tiles from tile servers as displayed in Google Earth are typically already in a "non-warped" Coordinate Reference System, imagery and other GIS Data output by Google Earth is re-formatted into a "warped" GIS projection referred to as WGS84 (aka EPSG:4326).


BTW: SBuilderX also re-projects imagery from a Mercator-type GIS format to a EPSG:4326 format required by SDK Resample.


This may cause imagery alignment issues as described above.


Alternatively, if you are already using EPSG:3857 imagery, perhaps the Geo-referencing coordinates used are incorrect ?

[END_EDIT]


Here is how to output such a background map as a 1-piece *.BMP of selected tiles from SBuilderX, which can be further processed as needed in a graphics application for ex: ADE with 'minimal'- if any- GIS projectional distortion.


To output a 1-piece *.BMP of selected tiles from the SBuilderX version 3.15 64-Bit work-space in a non-warped format for use in ADE or a 3D modeling application:

1.) SBuilderX Menu > Edit > Edit INI file... (SBuilderX.INI opens in NotePad)

a.) In NotePad > SBuilderX.INI > Under [Tiles] section, Edit:

ReprojectMercatorTiles=True

...and change it to read:

ReprojectMercatorTiles=False

b.) NotePad Menu > File > Save

c.) NotePad Menu > File > Exit

2.) SBuilderX Menu > File > Add Map > From Background

a.) Follow usual procedures to download / select tiles (do not compile to BGL)

3.) SBuilderX outputs non-warped format 1-piece *.BMP / *.TXT into:

[SBuilderX install path]\Tools\Work sub-folder


FYI: the *.TXT file also output with the same filename as the 1-piece non-warped format 1-piece *.BMP contains the Geo-referencing info used to add the background image to ADE.




NOTE: For use in ADE, that 1-piece *.BMP must first be processed in ex: GIMP to make either numerous smaller tile segments, or very low resolution 24-Bit JPGs, so they can be "Added" as "Images" in ADE using UTM Metadata for use as background imagery 'tiles' loaded 1-at-a-time while working on the corresponding local area of Umeå Airport (ICAO ESNU) in ADE.


CAVEAT: Restore normal SDK Resample compatible output of a 1-piece *.BMP of selected tiles from the SBuilderX work-space in a warped format for use in making ex: custom photo-real imagery land class terrain textures:

1.) SBuilderX Menu > Edit > Edit INI file... (SBuilderX.INI opens in NotePad)

a.) In NotePad > SBuilderX.INI > Under [Tiles] section, Edit:

ReprojectMercatorTiles=False

...and change it to read:

ReprojectMercatorTiles=True

b.) NotePad Menu > File > Save

c.) NotePad Menu > File > Exit


Hope this helps with your current or pending tasks.

GaryGB

 

[johnor999]

Hello:

Aside from having a project location North of 60 Degrees which would increase projectional distortion in WGS84 imagery, you would likely want a "less" distorted result by NOT re-projecting imagery to WGS84.


Although Mercator-type GIS projected imagery tiles from tile servers as displayed in Google Earth are typically already in a "non-warped" Coordinate Reference System.


Data output by Google Earth is re-formatted into a "warped" GIS projection referred to as WGS84 (aka EPSG:4326).


BTW: SBuilderX also re-projects imagery from a Mercator-type GIS format to a EPSG:4326 format required by SDK Resample.


This may cause imagery alignment issues as described above.


Alternatively, if EPSG:3857 imagery is already being used, perhaps Geo-referencing coordinates used are incorrect ?



Here is how to output such a background map as a 1-piece *.BMP of selected tiles from SBuilderX, which can be further processed as needed in a graphics application for ex: ADE with 'minimal'- if any- GIS projectional distortion.


To output a 1-piece *.BMP of selected tiles from the SBuilderX version 3.15 64-Bit work-space in a non-warped format for use in ADE or a 3D modeling application:

1.) SBuilderX Menu > Edit > Edit INI file... (SBuilderX.INI opens in NotePad)

a.) In NotePad > SBuilderX.INI > Under [Tiles] section, Edit:

ReprojectMercatorTiles=True

...and change it to read:

ReprojectMercatorTiles=False

b.) NotePad Menu > File > Save

c.) NotePad Menu > File > Exit

2.) SBuilderX Menu > File > Add Map > From Background

a.) Follow usual procedures to download / select tiles (do not compile to BGL)

3.) SBuilderX outputs non-warped format 1-piece *.BMP / *.TXT into:

[SBuilderX install path]\Tools\Work sub-folder


FYI: the *.TXT file also output with the same filename as the 1-piece non-warped format 1-piece *.BMP contains the Geo-referencing info used to add the background image to ADE.




NOTE: For use in ADE, that 1-piece *.BMP must first be processed in ex: GIMP to make either numerous smaller tile segments, or very low resolution 24-Bit JPGs, so they can be "Added" as "Images" in ADE using UTM Metadata for use as background imagery 'tiles' loaded 1-at-a-time while working on the corresponding local area of Umeå Airport (ICAO ESNU) in ADE.


CAVEAT: Restore normal SDK Resample compatible output of a 1-piece *.BMP of selected tiles from the SBuilderX work-space in a warped format for use in making ex: custom photo-real imagery land class terrain textures:

1.) SBuilderX Menu > Edit > Edit INI file... (SBuilderX.INI opens in NotePad)

a.) In NotePad > SBuilderX.INI > Under [Tiles] section, Edit:

ReprojectMercatorTiles=False

...and change it to read:

ReprojectMercatorTiles=True

b.) NotePad Menu > File > Save

c.) NotePad Menu > File > Exit


Hope this helps with your current or pending tasks.

GaryGB

Hm... okay. If we ignore the background images completely for now, what you are saying is that if I take a set of coordinates from Google Earth, these coordinates would be wrong in ADE at high latitudes?

 

[GaryGB]

https://www.fsdeveloper.com/forum/t...tween-ade-and-google-earth.446527/post-834267


Hm... okay. If we ignore the background images completely for now, what you are saying is that if I take a set of coordinates from Google Earth, these coordinates would be wrong in ADE at high latitudes?

What I'm saying is do not use "warped" WGS84 / EPSG:4326 projection for background images; use EPSG:3857 projection instead.

Generally speaking, the farther North imagery WGS84 is mapped onto an oblate spheroid, the more it is susceptible to distortion.

To achieve the 'least' distortion, imagery should be mapped as EPSG:3857, and Geo-referencing coordinates should be derived from data internally output along with that same imagery file in that GIS projection format (and not via manual trial-and-error or "rubber-sheeting" coordinate 'guess-timating' methods).

Failure to use EPSG:3857 GIS projection may cause incorrect size / shape / location of ADE scenery at run time in FS.


Unless Google Earth historical imagery is required, one can use Google imagery downloaded via SBuilderX "Google_api3_Satellite"; in some cases tileservers other than Google may have better quality imagery for certain locations.

The *.TXT file also output with the same filename as the 1-piece non-warped format 1-piece *.BMP contains the Geo-referencing info used to add the background image to ADE; this info is specific to the GIS projection of that image.


Hope this clarifies your options a bit more (...in addition to the edits I also made in my post above).

GaryGB

 

[johnor999]

What I'm saying is do not use "warped" WGS84 / EPSG:4326 projection for background images; use EPSG:3857 projection instead.

Generally speaking, the farther North imagery is mapped onto an oblate spheroid, the more it is susceptible to distortion.

To achieve the 'least' distortion, imagery should be mapped as EPSG:3857, and Geo-referencing coordinates should be derived from data internally output along with that same imagery file in that GIS projection format (and not via manual trial-and-error or "rubber-sheeting" coordinate 'guess-timating' methods).


Unless Google Earth historical imagery is required, one can use Google imagery downloaded via SBuilderX "Google_api3_Satellite"

The *.TXT file also output with the same filename as the 1-piece non-warped format 1-piece *.BMP contains the Geo-referencing info used to add the background image to ADE; this info is specific to the GIS projection of that image.


Hope this clarifies your options a bit more (...in addition to the edits I also made in my post above).

GaryGB

I really appreciate the in-depth detail of your replies regarding the imagery.

Are the following statements correct?
The distance between N63.798411, E020.268956 and N63.782811, E020.30142 should not be the same in both Google Earth and ADE because they don't use the same projection.
Coordinates from Google Earth must be transformed before being used in ADE.
(Note that I'm not talking about imagery now, just the coordinates above)

 

[GaryGB]

Discrepancy between ADE and Google Earth

Hello, I noticed that I couldn't make a runway fit properly against my background images. It's as if the scale is wrong somehow. To test this, I placed two nodes at coordinates N63.798411, E020.268956 and N63.782811, E020.30142. After that I measured the distance between those two nodes in ADE...

www.fsdeveloper.com

Are the following statements correct?

The distance between N63.798411, E020.268956 and N63.782811, E020.30142 should not be the same in both Google Earth and ADE because they don't use the same projection.

Coordinates from Google Earth must be transformed before being used in ADE.

(Note that I'm not talking about imagery now, just the coordinates above)

Hi Johan:

My reply would require more info from you, as to how the Geographic coordinates cited above were derived:

* Manually via the Google Earth cursor

...or:

* From Google Earth "Path" vertex end-point positions in a *.KML / *.KMZ file


Are the Geographic coordinates cited above, intended for use with a *.JPG exported by Google Earth via:

Google Earth Menu > File > Save > Save As...

...or are they instead intended for use with a screenshot of the Google Earth workspace ?


GaryGB

 

[johnor999]

My reply would require more info from you, as to how the Geographic coordinates cited above were derived:

* Manually via the Google Earth cursor

...or:

* From Google Earth "Path" vertex end-point positions in a *.KML / *.KMZ file


Are the Geographic coordinates cited above, intended for use with a *.JPG exported by Google Earth via:

Google Earth Menu > File > Save > Save As...

...or are they instead intended for use with a screenshot of the Google Earth workspace ?


GaryGB

Manually via Google Earth by placing a placemark, then opening the placemark to get the latitude and longitude. For now the pair of coordinates only represent two locations. They have nothing to do with imagery of any kind.

 

[GaryGB]

OK, then the Path length between vertex end-point positions as measured by ADE 'should' match that as displayed in Google Earth.

However, Google Earth does not have an option to disable re-projection from EPSG:3857 to EPSG:4326 during file export like SBuilderX.

Also ADE does not have the option to re-project from EPSG:4326 to EPSG:3857.

I'll test this in Global Mapper GIS application also to verify length in EPSG:4326 versus EPSG:4326, and will advise ASAP.

GaryGB

 

[GaryGB]

Hi Johan:

After manually creating the Geographic coordinates cited above as "Placemark" Path vertex end-point positions in Google Earth, then saving them as *.KMZ files, I imported both of those files into Global Mapper.

*.KMZ "Placemark" Path vertex end-point positions saved by Google Earth as *.KMZ files are internally and automatically projected to EPSG:4326, and will require re-projection to EPSG:3857 ...before utilized by ADE, to ensure accurate size / shape / location / heading of ADE-generated scenery at run time in FS.

EPSG:4326

EPSG:3857

Hope this helps clarify the above GIS projection scenario a bit more.

GaryGB

 

[scruffyduck]

I have stayed away from this but I guess I should explain how ADE does these calculations. I would also say that ADE has never claimed to be completely accurate with respect to the real world - whatever version of that you choose to use. I would say that 6 meters in 2357 is probably within the accuracy of ADE - that is 0.25% error. I know that some folks do strive for better accuracy that I might feel matters.

ADE has several calculation models which it can use. These include this library: http://www.gavaghan.org/blog/free-source-code/geodesy-library-vincentys-formula/ It is set to use ApproxSpherical We spent a lot of time in the early days to find a coordinate math system that was reasonably accurate over the distances seen at an airport. Generally the current method has been in use for many years and seems to work since this is the first post related to it that I can recall. Spacial relationships in ADE are calculated based on the airport reference point.

 

[GaryGB]

Thanks for that explanation of ADE functionality, Jon.


As Airport Design Editor (aka "ADE") is intended to output FS scenery content via 1 or more of several SDK compilers, I believe this might be an opportune time to clarify that internal GIS re-projection processing is NOT performed by ADE on source code that will be submitted to those SDK compilers.


AFAIK, both ADE and output-targeted FS SDK compilers do not perform any internal processing of source code submitted with Geographic coordinates to verify whether the source data is in WGS84 datum.

Also, ADE and output-targeted FS SDK compilers do not perform any GIS re-projection on submitted source data.


Thus, end-users must ensure their source data has the correct GIS Projection and Datum for a particular SDK compiler before creating scenery in ADE.

Improper GIS projection may cause incorrect size / shape / location / heading of scenery at run time in FS.


Terrain objects to be compiled by FS SDK compilers SHP2VEC and Resample require source data in EPSG:4326 (this is also referred to as Geographic projection / WGS84 datum).


2D or 3D scenery objects (including G-Polys) and associated 'placement' data to be compiled by FS SDK BGLComp require source data in EPSG:3857


GaryGB

 

[GHD]

Absolute latitude/longitude is independent of any projections.

 

[GaryGB]

https://www.fsdeveloper.com/forum/t...tween-ade-and-google-earth.446527/post-834360

Absolute latitude/longitude is independent of any projections.

Here's some additional info for those who may otherwise infer an incorrect conclusion by reading George's post:


http://www.adamszofran.com/ConferenceTalks/GDC2006/pdf

Global Terrain Technology for Flight Simulation

Adam Szofran

"Flight Simulator uses the ellipsoidal Earth model defined by the World Geodetic System 1984, or WGS 84"



https://www.fws.gov/r7/nwr/Realty/d...apper-Help.html?Degreesandgrounddistance.html

"How Far is a Degree?

You're familiar with latitude, longitude, degrees, minutes, and seconds. But do you know the ground distance of one degree of arc? How about one minute of arc - how long is that? One second of arc? When dealing with latitude and longitude coordinates, it is often helpful to have a general idea of the ground distance covered by various arc lengths.

You learned in the previous topic that the Earth is not a perfect sphere, but is in fact an ellipsoid. To determine the ground distance of various arc lengths for an ellipse, we have to calculate the perimeter of an ellipse."



https://www.fws.gov/r7/nwr/Realty/d...lp.html?Datumsprojectionsandcoordinatesy.html

"A Geodesy Primer

"So the ellipsoids are different. Why does this matter ?

All geographic coordinates (latitude and longitude) are derived from an ellipsoid. And since the ellipsoids have different numerical values, a latitude and longitude value for a particular datum will not have the same value in a different datum. Consider the following example:

Datum	NAD27	NAD83	WGS84
Longitude	134° 21' 49.21"	134° 21' 55.59"	134° 21' 55.66"
Latitude	58° 22' 3.30"	58° 22' 2.13"	58° 22' 2.15"

All three coordinates above identify the same physical point on the Earth's surface, but the seconds value varies. This is due to the different ellipsoids associated with the datums. The reason why this matters is because if you don't know what datum your data is in, you or someone else will have to guess which datum the data are in, and this greatly increases the probability of positional errors when you import your data into the Land Mapper or GIS."





"The $64,000 Question - Why do I need to know all this stuff ?

The simple answer: if you don't know what datum and projection your data are referenced to, there's a very high probability that your data will not align correctly with other features when viewed in the Land Mapper or GIS. If you, as the owner of your data, don't know what datum it is referenced to, others who try to use it will have to guess, with likely incorrect results."



"Latitude + Longitude + Datum = A Complete Coordinate, aka LLD = Problem Free !

Casual use of latitude and longitude positions generally doesn't involve referencing the datum to which the lat/long is tied. However, when dealing with GIS a higher level of precision is required, thus lat/long values must always include the associated datum.

When noting lat/long coordinates or giving lat/long coordinates to someone, you must always report the datum which is used by the coordinates. Without the datum information, the user will have to guess which datum your lat/long coordinates are in, and this often leads to misalignment of features. Following are several examples of the correct way to note lat/long coordinates:

•45.50, -150.25, NAD27

•45.50 N, 150.25 W, NAD83

•45° 30' 00" N, 150° 15' 00" W, WGS84

Note that for each example, the datum has been specified. A lat/long coordinate should never leave your desk without a datum specified. Remember: LLD = Problem Free!"

GaryGB