Re: [Flightgear-devel] Wrong coordinates with airport LICP?
On Wed, 2005-06-22 at 17:05, Roberto Inzerillo wrote: 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. True. It's not a coordinate system by it's own. Right? No - it is a coordinate system as well. WGS84 is in some ways a bit confusing as it defines two things: a spheroid (known as the WGS84 spheroid, apparently) and a reference system on top of that (i.e an equator and a prime meridian). The reference system doesn't seem to have a name other than maybe the WGS84 reference system :-)). But WGS84 is only any use for describing points on a spheroid. If you want to make paper maps of any area of the world you need a projection system. Italy (evidently) uses UTM33N. 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? Nothing! Read on I visited 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). This is interesting. It implies that the data points coming from that web site are originally WGS84 already. If the site gave you lat/long then you could forget the UTM33 knowledge - lat/long would be the same on both. However, your comments below show that the coords given on the site are in UTM33 Eastings and Northings, and you'll have to convert them. Airport LICP start and end points of the runway are: Coordinates(1) - 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? Yes I think so. Looks like point A is 353.0915km east and 4220.5794km north of the UTM33N reference point. - 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. Coordinates(1) - 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: Coordinates(2) - 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! OK, so either Geographic Translator Version 2.2.5 is buggy, or the published UTM33N eastings and northings are wrong. - 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 points. 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: Coordinates(3) - 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. Yeah, I see that. So potentially FGSD is doing a dud conversion too. At least we have the source code for FGFS and can check it 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
Re: [Flightgear-devel] Wrong coordinates with airport LICP?
You can check if fgsd is correct by importing a map that has both UTM33N and longitude/latitude markings. You calibrate the map with the UTM coordinate system, and then over the mouse on the main window to see if the reported latitude/longitude ( in the status bar ) are correct according to the second scale. I did that with a map of La Réunion french island in Indian Ocean and it worked well at that time. FGSD use functions that are extracted from a program call UTM2LL ( IIRC ) -Fred ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] I18N (was: Re: gear/flaps handling (b29, hurricane, ...))
* Melchior FRANZ -- Wednesday 22 June 2005 22:51:
* Giles Robertson -- Wednesday 22 June 2005 21:58:
which would allow us to deal with the kb
localisation issues that were mentioned earlier this month.
Better in *this* respect would be files with a few swap instructions:
keyboard-fr.xml: - swap US/65 bindings with US/81 bindings.
What about this: fgfs first loads $FG_ROOT/keyboard.xml into the property tree,
as it always did. Then, if localization is requested, the same part that loads/
loaded the strings file does also load a stripped down keyboard file, e.g.
$FG_ROOT/Translations/keyboard-fr.xml. No bindings here, only references:
?xml version=1.0?
PropertyList
input
keyboard-map
descTableaux des clefs franc,oiwhatever/desc
key n=97
namea/name
desctranslation of: what used to be q/desc
property/input/keyboard/key[113]/property
/key
key n=113
nameq/name
desctranslation of: increase speed-up (formerly known as
'a')/desc
property/input/keyboard/key[97]//property
mod-up
property/input/keyboard/key[97]/mod-up/property
/mod-up
mod-alt
property/input/keyboard/key[1234]/property
/mod-alt
/key
/keyboard-map
/input
/PropertyList
And finally, if such a subtree /input/keyboard-map exists, _init_keyboard()
goes through this and replaces all occurrences of property by the contents
of this referenced node. When it's done, it dumps /input/keyboard (Erik:
delTree()! :-) and moves /input/keyboard-map to /input/keyboard. Viola!
BTW: with both (and other) solutions one could easily write a script
that extracts all existing bindings from a running fgfs, and makes a key
overview table. Could even be done as nasal module that writes TeX code
(as soon as Nasal can write files, that is).
It doesn't write TeX (or PostScript) yet, but it's a start.
See attachment. Just dump it into $FG_ROOT/Nasal/.
m.
stripPeriod = func {
substr(arg[0], 0, strc(arg[0], (n = size(arg[0])) - 1) == 46 ? n - 1 :
n);
}
writeMap = func {
kbd = props.globals.getNode(/input/keyboard);
foreach (k; kbd.getChildren(key)) {
writeKey(k);
}
}
writeKey = func(key) {
name = (n = key.getNode(name)) != nil ? n.getValue() : noname;
out = name ~ ( ~ key.getIndex() ~ ): ;
if ((n = key.getNode(desc)) != nil) {
out ~= stripPeriod(n.getValue());
}
addDesc = func(key, name, tag) {
if ((n = key.getNode(name ~ /desc)) != nil) {
out ~= ; ~ tag ~ : ~ stripPeriod(n.getValue());
}
}
addDesc(key, mod-up, UP);
addDesc(key, mod-shift, SHIFT);
addDesc(key, mod-ctrl, CTRL);
addDesc(key, mod-alt, ALT);
print(out);
}
settimer(writeMap, 0);
___
Flightgear-devel mailing list
Flightgear-devel@flightgear.org
http://mail.flightgear.org/mailman/listinfo/flightgear-devel
2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: Ground vehicles
To go along with the ground vehicles, is there a way to have them move on the terrain within the scenes? Thanks, Stacie ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Ground vehicles
I've been looking into this myself, and found a couple of ways. First is the AI models. You can give a vehicle a predetermined 'flight plan', if it needs to change elevations and turn and so forth. I haven't looked into the details of this...hopefully it's not too aircraft-specific to use for ground vehicles. If you're on level ground, you can also treat a ground vehicle as a ship, and allow it to follow a continuous, circular path. If you look in the base package, there's a file called data/Docs/AI_doc.html that describes how to use AI models. What I ended up doing, though, is use the Model Manager interface, which allows objects to be controlled using the property manager. In my preferences.xml file, I have the following script: models model nametruck/name pathAircraft/vehicles/Models/truck.xml/path longitude-deg-prop/models/truck/longitude/longitude-deg-prop latitude-deg-prop/models/truck/latitude/latitude-deg-prop heading-deg-prop/models/truck/heading/heading-deg-prop elevation-ft-prop/models/truck/elevation-ft/elevation-ft-prop /model /models Now, I can control my truck by adjusting the properties I associated with its position and orientation. By the way, if you find any good models of a truck, Jeep, or Humvee...let me know. Drew On 6/23/05, Corrubia, Stacie K [EMAIL PROTECTED] wrote: To go along with the ground vehicles, is there a way to have them move on the terrain within the scenes? Thanks, Stacie ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Ground vehicles
Oh, I should add that I don't think there's a simple mechanism for real-time determination of the terrain height at the vehicle's location. I think you'll have to use predetermined profiles in order to keep it at ground leve. On 6/23/05, Corrubia, Stacie K [EMAIL PROTECTED] wrote: To go along with the ground vehicles, is there a way to have them move on the terrain within the scenes? Thanks, Stacie ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] I18N
Melchior FRANZ wrote: of this referenced node. When it's done, it dumps /input/keyboard (Erik: delTree()! :-) and moves /input/keyboard-map to /input/keyboard. Viola! I was already afraid this would happen, we're both waiting for a response aren't we? :-) Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Ground vehicles
On Donnerstag 23 Juni 2005 18:14, Drew wrote: Oh, I should add that I don't think there's a simple mechanism for real-time determination of the terrain height at the vehicle's location. I think you'll have to use predetermined profiles in order to keep it at ground leve. You might use the groundcache in src/FDM/grouncache.cxx. You can see how this is used in the FDM interface. I have also started to clean up that stuff a bit so that there is a clear api to: - either query one single ground level a step - or use the groundcache for multiple queries in the same area. ... not yet finished, but I hope during the next time... Greetings Mathias -- Mathias Fröhlich, email: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] Re: Ground vehicles
Le jeudi 23 juin 2005 à 10:15 -0500, Corrubia, Stacie K a écrit : To go along with the ground vehicles, is there a way to have them move on the terrain within the scenes? Thanks, Stacie You could refer to ship AI ! It should work too. -- Gerard ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] Re: I18N
* Erik Hofman -- Thursday 23 June 2005 18:23: I was already afraid this would happen, we're both waiting for a response aren't we? :-) Hehe ... yes. I'm still waiting for the OK, I'll do it message. Let's at least rename SGPropertyNode::removeChild() to ...detach() or makeZombie(). For the curious: it turned out that there's no way to remove a property subtree. removeChild() only removes that very child, but not its children etc. So the complete removed tree ends up as zombie. The implementation of a tree-deleter is somehow complicated by the fact that nodes can be referenced as aliases or tied, only the latter state of which is currently known to a node. There's some rudimentary refcounting, but that's not sufficient. Does anyone know an already implemented way to remove a property tree that we may have missed? m. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
[Flightgear-devel] New aircraft ideas ?
Got an idea for a new aircraft (not airplane) you'd like to try ? http://www.dodsbir.net/Topics/Default.asp Topic: A05-208 ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
