Hi Steve,

> UTM33N is indeed a coordinate system, probably the system of choice for
> use in Italy, most of the country being in the 33rd 6-degree wide strip
> of the planet, and in the northern hemisphere:

I agree.

> WGS84 is also a coordinate system - the "native" system used by GPS and
> (unless I'm mistaken) the system used by FlightGear.

Sorry, but I thought WGS84 is a Datum, one of the possible geometric
ellipsoid to choose from for describing the earth surface. It's not a
coordinate system by it's own. Right? This decision changes the way the
normal in a point is defined as well as the point considered to be the
center of the earth, so the latitude value depends on this choice too.
What am I missing?

> The difference is that UTM33N (or any of the other UTMs) are intended
> merely as map projections and only work over a small strip of the
> world's surface. WGS84 works over the whole planet.

That's what FGSD needs when importing data from external maps, it asks for a
coordinate system (relative to something) and a datum which to refer to.

> You can convert between projections obviously. One of the "complete"
> ways of doing it is called the Molodensky transform:
> http://www.colorado.edu/geography/gcraft/notes/datum/datum_f.html

I've found GeoTrans (Geographic Translator) which I think is good enough for
such conversions.

> ( In practice, for small areas, you can assume that just applying an X
> and Y correction factor and a small rotation about that point will do
> it. )

I have no problem with rotation in this case. It's only a translation error
(or you consider the small translation on the surface of the earth as a
rotation around the center point of the earth?  :-)

Ok. I made my homeworks, I try being more precise and practical now.
I describe what I do and how the error arises.

- First step: source data
I visit www.atlanteitaliano.it (a Government web site); there I find a
complete map system of Italy. It's a ECW driven interactive site. I can pick
a point and have the coordinates back. www.atlanteitaliano.it says (for the
region where LICP lays) Datum is WGS84 and Projection is NUTM33 (UTM, region
33, North).
Airport LICP start and end points of the runway are:
 - Point A
     X: 352091.5   Y: 4220579.4
 - Point B
     X: 352213.2   Y: 4219364.1
Knowing Datum, Projection and Coordinates is enough for determining the
point in the space, right?

- Second step (optional): coordinate conversion
I make use of "Geographic Translator Version 2.2.5" for getting the
conversion, which is usefull for further data verification.
The source data are the above ones; I specify that Datum is "WGE: World
Geodetic System 1984" (Ellipsoid is "WE: WGS84"), "Universal Transverse
Mercator (UTM)", Zone is 33, Hemisphere is North.
 - Point A
     Easting/X(m): 352091.5   Northing/Y(m): 4220579.4
 - Point B
     Easting/X(m): 352213.2   Northing/Y(m): 4219364.1
I asked Geographic Translator to give me the output so that Datum is "WGE:
World Geodetic System 1984" (Ellipsoid is "WE: WGS84"), Geodetic.
I get the following output:
 - Point A
     Longitude: 13 18 45.5E   Latitude: 38 7 15.4N
 - Point B
     Longitude: 13 18 51.4E   Latitude: 38 6 36.1N
These should be the coordinate values of the two points in FG Scenery,
right? Well these are not!

- Third step: aerial picture of LICP overlap to FGFS scenery LICP
I make use of FlightGear Scenery Designer for importing the aerial picture
and overlap it to the scenery so to complete it with surrounding buildings,
roads and so on. I make use of the tool called "Map Fragments". Here I can
import a picture of the terrain, fixing the coordinates of three known
www.atlanteitaliano.it gives me those three points (two of them being the
two above described, and choosing a third usefull point).
Well, here FGSD asks me which kind of coordinates I am importing. I set
"System: Universal Transverse Mercator", "Zone: 33", North, "Datum: WGS-84".
For the two points, I use the Coordinates(1).
Well, the problem is when I import this "MAP Fragment" into the scenery. The
result is the picture of the airport being translate by almost 500m north to
the position of the airport of the scenery.

The scenery airport coordinates, as viewed into FGSD, are:
 - Point A:
     E 013:18'50.4   N 38:06'18.0
 - Point B:
     E 013:18'45.8   N 38:06'57.6

The error is that (Coordinates(3)A.N)!=(Coordinates(2)A.N) .
I get the same error for PointB too, of course.

The two runways are perfectly parallel to each other. There seems not to be
any rotation error.

So now what's the mistake? Am I doing something wrong? Is FGSD doing
something wrong? Is atlanteitaliano.it reporting wrong coordinates? Is the
apt.dat wrong?
You can check the error with FGSD by yourself, simply download the XML MAP
File and the aerial picture at the URL

> > Anyway, do you think is possible that apt.dat is that wrong (550m)?
> Scenery
> > files for Europe are not precise at all. Are airport locations affected
> by
> > the same kind of errors? Maybe because of not enough precise source
> > informations?
> Someone else pointed out that airport data comes from published figures,
> but it is possible that some airports published their coordinates in a
> non WGS84 system but someone forgot to do the Molodensky transformation
> on them before adding them to the apt.dat files.

I checked other spots of the city around, some seem correct enough. The
overlapping is not very precise because the scenery is not high definition,
so I have to guess if a coastline seems correct enough because of correct
source data or just because of luck; anyway I think the error is just with
this LICP airport and not with the rest of the scenery territory around.


Geschenkt: 3 Monate GMX ProMail gratis + 3 Ausgaben stern gratis
++ Jetzt anmelden & testen ++ http://www.gmx.net/de/go/promail ++

Flightgear-devel mailing list

Reply via email to