APT coordinates and object coordinates

[Stainless]

Hi Guys,

I have been writing a tool to convert airports from the APT format to 3D so they can be further detailed.

It went well at first, I figured out the APT format and how beziers were handled and got to the stage where all the runways, pavements, linear features etc. look correct.

So then I realised that people have already been detailing airports and I need to load in the objects they have already placed. Otherwise you might add detail that ends up inside a hanger or something.

This is where my problems started. The objects are all in the wrong place. This really is making me scratch my head. Since all you have in the STG file is the latitude, longitude and rotation, it shouldn't be possible for them to be in the wrong place.

All my datum points are handled by the same code, so if I had a bug in that code, they may be in the wrong place but so should everything else.

I'll show you what I mean.

This is my version of Shoreham



When I overlay the official pilots map it's pretty damn close apart from the objects.



In 3D you can see how far it is out.



Has anyone come across this problem before?
I am a bit lost.

Thanks guys.

[Stainless]

In case anyone is interested, the code for the location is here

Code: Select all

        /// <summary>
        /// Returns a new Vector2D which is the distance from the reference point in metres
        /// IE. Makes the data point local to the reference point
        /// </summary>
        /// <param name="clat">Reference point latitude</param>
        /// <param name="clon">Reference point longitude</param>
        /// <param name="slat">Data point latitude</param>
        /// <param name="slon">Data point longitude</param>
        /// <returns></returns>
        public static Vector2D ConvertToLocalised(double clat, double clon, double slat, double slon)
        {
            double m_per_deg_lat, m_per_deg_lon, deltaLat, deltaLon;

            m_per_deg_lat = 111132.954 - 559.822 * Math.Cos(MathHelper.ToRadians((float)(2.0 * clat)) + 1.175 * Math.Cos(MathHelper.ToRadians((float)(4.0 * clat))));
            m_per_deg_lon = (3.14159265359 / 180) * 6367449 * Math.Cos(MathHelper.ToRadians((float)clat));

            deltaLat = clat - slat;
            deltaLon = slon - clon;

            return new Vector2D(deltaLon * m_per_deg_lon, deltaLat * m_per_deg_lat);
        }


[wkitty42]

please check your image links... the second one also seems to have a stray "]" character at the end...

[Alant]

This may be relevant. http://wiki.flightgear.org/Howto:Place_3D_objects_with_WED

It includes a python script https://github.com/mherweg/d-laser-fgtools/blob/master/wed2stg.py which at lines 95-97 rotates objects from WED co-ordinates to those used in the .stg file.

Alan

[Stainless]

Thanks Alant,

I knew about the strange coordinate system for the rotation (0 is north, but anti-clockwise rather than clockwise) but that doesn't explain why the objects are in the wrong position.

I have fixed the scaling issue, it was a simple metres / feet cock up, but the position issue is just annoying me.

It looks like the objects are in a rotated coordinate set for some reason....

[Stainless]

I think I may be close to a solution.

While reading about the BGT file format, I realised we have three coordinate systems in use. Geodetic, Geocentric, and Cartesian.

As a test I converted the object locations from Geodetic (as stated in the docs) to Geocentric. And the objects were now about 4000 M out of position.

The interesting thing is that when I wrote a BGT parser and converted the cartesian coordinates in the BGT file to geodetic coordinates, they were also about 4000 M out of position.

So close to figuring it out.

[wkitty42]

could it be the different WGS measurements coming into play? one of my satellite tracking tools uses the WGS72 data which lists the following...

Code: Select all

const
  ae       = 1;
  tothrd   = 2/3;
  xkmper   = 6378.135;        {Earth equatorial radius - kilometers (WGS '72)}
  f        = 1/298.26;        {Earth flattening (WGS '72)}
  ge       = 398600.8;        {Earth gravitational constant (WGS '72)}
  J2       = 1.0826158E-3;    {J2 harmonic (WGS '72)}
  J3       = -2.53881E-6;     {J3 harmonic (WGS '72)}
  J4       = -1.65597E-6;     {J4 harmonic (WGS '72)}
  ck2      = J2/2;
  ck4      = -3*J4/8;
  xj3      = J3;
  qo       = ae + 120/xkmper;
  s        = ae + 78/xkmper;


compare that with WGS84 which lists these values...

Code: Select all

  xkmper   = 6378.137;          {Earth equatorial radius - kilometers (WGS '84)}
  f        = 1/298.257223563;   {Earth flattening (WGS '84)}


so xkmper increased by 0.002 km and the flattening value decreased by 0.002776437...

what i'm looking at is that one decimal place changing value could result in a misplaced object in a manner you're speaking of seeing... especially if FG is using one of these and you're using the other... i haven't tried to do any sample math to find out how far off the placement would be but this would appear, on the surface, to possibly be what you are seeing... if not, maybe it can point you in the right direction...

[Stainless]

Thanks wkitty42,

That's interesting data. will have a think about it.

It's frustrating that I am so close to something really useful, but just cannot get the last 1% to work.

[Stainless]

This image is really interesting.



The white areas are the base BTG files just untextured.

You can see that they don't join up.

You can also see the BTG file for the airport is a different orientation to the one I generate from the apt.dat file, and a different size.

But you can see that the runway objects are close to my version of the airport and not to the BTG version of the airport.......

Confused.com is me.

[wkitty42]

assuming a sphere:
using WGS72 = 511,207,572.796 km2 surface area
using WGS84 = 511,207,893.396 km2 surface area

that's not much difference... not enough to move things off by 4km as you reported... i don't know... maybe that idea isn't the thing...

what about your precision? how many decimal places are you working with? i'm guessing your math libraries are high precision, too? i know i see a lot of stuff with eight decimal places... that's all i have for now


[edit]

OH! you might want to check out this topic, too... https://forum.flightgear.org/viewtopic.php?f=5&t=33991... it is along similar lines of the problem with scenery being shifted...

[Stainless]

I am using doubles all the way until I have to render.

As an experiment I am going to change my display code to work with cartesian coordinates, and change the BTG renderer to use them as well. If they then match up I will gradually change everything else to work in cartesian coordinates and only make the change to localised coordinates when I export the result to ac, obj, etc.

[Stainless]

Starting to look a bit more sensible. I have swapped to using an ECEF based camera system (still needs work, but everything is starting to look more sensible).