Calculation of LAT/LON - can it be done?

[AlanMzk]

I am using SCASM to place objects from my own object library files.
I wrote some code - modified from formulas from MS Excel - that calculate a new LAT/LON from and original location and a displacement. When I run the compiler I get the error message:

Area( 5 $LATI $LONGI 6 )
-> illegal identifier "$"

I have never seen any documentation that you can't use User variables to do this but I guess that may be the issue. Has anyone tried to do this before and been successful?

 

[charlymorton]

I've never done exactly what you're describing, but if you want to calculate a distance between two known lat/long coordinates, you use the haversine formula, so calculating new lat/long coordinates a distance away from original coordinates, would require some sort of inversed haversine formula.

 

[arno]

Hi,

Did you use the UVar command to define your user variables? From the SCASM documention it seems they are valid only inside an Area block, so maybe you can't use them in the Area command itself.

Which FS version are you using? The earth model is slightly different between different versions, so that would influence how you have to calculate your new lat/long values.

 

[AlanMzk]

Hi Arno;

I used a MS Excel Spread sheet to develop the formulas and did some positioning by manually using the results to create a line of taxiway lights.
They line up well and so I am not worried about the world model ... I'm using FS2002 and 2004.

I did use the Uvar command - I think that is what the compiler didn't like since it was done outside of the Area block.

The reason I tried to do this was that when I tried to set a single reference point and then use a series of TransformCalls the line of objects moved.

Since neither the calculated Lat/Lon and the TransformCall methods didn't work I am using Excel to calculate the locations for each object and then copying and pasting into my code. That works fine.

I do have a follow-up question about visibility.

When I draw runway lights using the Dot command, they disappear at about 2 miles (about 3300 m)

I am using 0.0015785 - 1/16 in for a scale. I have tried changing all the visibility settings to no avail. Any suggestions?

Attached are some pictures:the light close up, the second from where they begin to fade and then the third close to the fade out point.

These are objects in a custom library to minimize the frame rate hit.

 

[arno]

Hi,

For fs2002 and fs2004 the formulas are indeed easier.

If you already have all the lat long positions, would it not be easier to convert them to xy positions from a single reference point? That should be more efficient I would say.

I don't think the visibility of the light point is related to the scale, it is somewhere inside the sim and I am not aware of ways to manipulate it.

 

[GaryGB]

Hello:

It would seem that there was no 'publicly-posted' follow up on this thread to determine if ACES did- or did not- fix the internal computational workings of FSX for 3D world model coordinate compatibility with a WGS84 "oblate spheroid" and not a "perfect sphere", or if indeed it was only the FSX SDK documentation which was wrong.

http://www.fsdeveloper.com/forum/showthread.php?t=6339&highlight=Haversine


The use of the Haversine Forumula with FSX calculations is still IMHO, in question, until the above question is tested / clearly answered.


[EDITED]

One might also wonder whether "Vincenty formula for distance between two Latitude/Longitude points" may merit consideration in FSX coordinate calculations:

http://www.movable-type.co.uk/scripts/latlong-vincenty.html

[END_EDIT]



Witness the known issues of problems involving object placement and rendered display at requested "on-ground" altitude AGL for points above 70 Degrees North on the globe in the FSX 3D 'world'.

http://www.simforums.com/forums/solved-blurries-up-north_topic44087.html

http://www.fsdeveloper.com/forum/showthread.php?t=76893



One might wonder if current assumed calculations for the FSX 3D 'world' result in a fitting of terrain layers and object placements etc. on the 'dotted line' of a FSX "theoretical pure sphere" globe ...rather than along the surface of a oblate spheroid (labeled as "Ellipse of Rotation" in this illustration):

Do FSX SDK 3D world calculations assume a theoretical sphere, rather than a oblate spheroid (or a "Geoid", upon which WGS84 is based) ?

http://en.wikipedia.org/wiki/World_Geodetic_System

http://en.wikipedia.org/wiki/Geodetic_datum

http://giseis.alaska.edu/input/west/proj/introgeophys/05_sea_surface_and_geoid/index.html


Arno:

If in fact ACES did not fix the internal computational workings of FSX for coordinates, might this have any 'bearing' on the calculated mis-alignments of attached Effect objects at a greater distance from a RefPoint ...as recently discussed ?

http://www.fsdeveloper.com/forum/showthread.php?t=424711


GaryGB

 

[arno]

Hi Gary,

I am quite sure that FSX uses the WGS84 elipsoid with the geoid and not just a sphere simplification.

When making ground polygons I noticed that the formula's used in FS2004 to calculate the distance from the reference point of a lat/lon position no longer work well. While in FS2004 these formulas resulted in perfect aligned polygons, also when these polygons had different reference points, in FSX there was always a gap between them.

After I implemented the WGS84 geocentric coordinates with the geoid height, my polygons are exactly aligned again. So I am quite sure that is the system they used.

It has also been confirmed to me by one of the ACES team members btw.

 

[GaryGB]

Hi,

For fs2002 and fs2004 the formulas are indeed easier.

If you already have all the lat long positions, would it not be easier to convert them to xy positions from a single reference point? That should be more efficient I would say.

I don't think the visibility of the light point is related to the scale, it is somewhere inside the sim and I am not aware of ways to manipulate it.

A "light Point" scenery object library which resulted from an interesting discussion at AVSIM forums might be of interest to the subjects addressed in this thread:

http://forum.avsim.net/topic/296289-looking-for-some-light-balls/

GaryGB

 

[GaryGB]

Hi Gary,

I am quite sure that FSX uses the WGS84 elipsoid with the geoid and not just a sphere simplification.

When making ground polygons I noticed that the formula's used in FS2004 to calculate the distance from the reference point of a lat/lon position no longer work well. While in FS2004 these formulas resulted in perfect aligned polygons, also when these polygons had different reference points, in FSX there was always a gap between them.

After I implemented the WGS84 geocentric coordinates with the geoid height, my polygons are exactly aligned again. So I am quite sure that is the system they used.

It has also been confirmed to me by one of the ACES team members btw.

Thanks Arno, for that clarification and for all your work implementing initial and updated earth curvature corrections to placement of Ground Polygons in FSX.


* Would one infer then, from use of FSX BGLComp for export of FSX MDLs by MCX with accompanying XML placement BGLs, that placement coordinates of individual objects other than Ground Polygons ...is being compiled into BGLs (via BGLComp) with "proper" alignment to correct for the Earth curvature of the FSX 3D world model ?

* And if so, when "Batch Mode" processing for export of FSX MDLs from MCX with accompanying XML placement BGLs is used, would one infer that placement coordinates of groups of Batch Mode processed objects other than Ground Polygons ...is being compiled into BGLs (via BGLComp) with "proper" alignment to correct for the Earth curvature of the FSX 3D world model ?


* And if the answer to both of the above is Yes, is the resulting placement coordinates aligned properly to the FSX 3D world because of coordinates being 'pre-processed' by MCX before they are sent to BGLComp ?

* ...Or does direct use of BGLComp by a 3rd party means other than MCX also yield accurate XML placement in the FSX 3D world (assuming the placement data is pre-processed by a FS developer for a Geographic Lat-Lon projection / WGS84 Datum destination environment) ?


[EDITED]

Uh-oh, yet another question comes to mind after once again reviewing Adam Szofran's treatise on how the FS scenery terrain engine works:

http://www.microsoft.com/Products/Games/FSInsider/developers/Pages/GlobalTerrain.aspx

"The conversion from latitude, longitude, and altitude above sea-level to geocentric Cartesian coordinates is relatively straightforward using equation 4-14 from the WGS 84 specification:

Where:
a = 6378137.0 meters (Earth's equatorial radius)
b = 6356752.3142 meters (Earth's polar radius)
e = 8.1819190842622 x 10-2 (ellipsoid eccentricity)

The equations must be evaluated using 64-bit floating point to prevent a loss of precision. The seven significant digits of 32-bit floats aren't enough to represent a point with better than sub meter accuracy. Since the rendering pipeline (Direct3D in this case) uses 32-bit floats, the final coordinates used for rendering must be converted to 32-bit offsets from a 64-bit local origin no more than several thousand meters away."

* In your opinion, does this info not compel use of more decimal points of precision in scenery object placement source code when requesting specific locations as a destination for placed objects from ex: BGLComp ?

BTW: Whereas Google Earth (which uses a somewhat comparable "spherical" 3D world engine to that of FS for rendering draped photo-real terrain textures and placement of 3D objects) ...previously used 14 decimal places in KML code, now instances of 16, 18, and even 21 decimal place numbers can be seen in captured KML output.

* If one were to use such high precision coordinates in source code for FS scenery, would BGLComp and/or the FS rendering engine behave differently by enabling / displaying placed objects with greater accuracy, and in greater compliance with an intended 'oblate spheroid' 3D world model destination ?

[END_EDIT]



Knowing that you have an extensive familiarity with SCASM, may I ask one other question of your expertise:

* Would it be reasonable to assume that since AFAIK, there has not been any apparent updates to the SCASM internal code base since FS2004, SCASM compilations of Geographic coordinates into BGLs will not have implemented ANY earth curvature corrections to placement of either FS Effects, Scenery Library Objects, or Ground Polygons ...to accommodate use in FSX, and that a FS Developer must pre-process placement data to do such corrections outside of a SCASM compilation procedure ?


Sorry for so many questions arising in the context of this thread; thanks in advance for your additional clarification on these, IMHO, pertinent considerations.

GaryGB

 

[arno]

Hi,

Bglcomp only places a certain model at a specific position (lat/lon), that has nothing to do with the curve of the earth. The model is not adjusted for the curve as well. So if you make a long building you will see it floats at the ends.

So it is up to the developer to take this into account. For small buildings it does not matter. It only gets visible for long buildings or for buildings that are located far from the reference point of the mdl file.

Bglcomp and the created bgl file work in geodetic coordinates, it is only the xyz coordinate system of the mdl object that uses the geocentric coordinates.

Indeed double precision floats are needed for these calculations, but that is no surprise. But this references to the geocentric coordinates, not necessary to the geodetic ones as well. Although these should be doubles as well, 14 digits already gives you sub meter precision if I remember correctly.

 

[arno]

Hi,

Forgot to answer the scasm part. Also long as geodetic coordinates are used it does not matter. The latitude and longitude values are just stored. Then curved earth or doesn't matter, that's up to the rendering engine which has to locate the position on the curved earth.

The curve can play a role in the local xyz coordinates again, but that's up to the modeler, not up to the compiler.

For example for the ground polygons made with modelconverterx I use scasm and I calculate the xyz coordinates so that they follow the curved earth. And this is then stored in a fs2002 bgl.