re [Flightgear-devel] Taxiway signage and default.apt file
Curt Olson writes: D Luff writes: Yes, that's basically what I'm planning to do. I keep forgetting you're a driving sim guy and probably have some very relevant expertise here. What co-ordinate systems are you using? That's not a trivial question to answer, why don't I say we are using the MN state plane coordinate system which maps into X, Y, Z with Z being up, X being in the longitude direction, and Y being in the latitude direction. I'm rapidly coming to the conclusion that nothing about coordinate systems is ever trivial :-) At airport level lat/lon spherical co-ordinates are really overkill for whats basically a planar problem. I was considering assuming that for a limited area (a few miles each way) one could assume that lines of lat and lon were straight and parallel, and possibly map the lat/lon to x/y depending on latitude to get the x and y axis subdivisions equal. This would be a lot cheaper that doing proper spherical - planar projection. The logical network would be defined in terms of these x,y and the airplanes lat/lon quickly and cheaply converted. Comments? For doing 2d positions near the airport that might be ok, but when you calculate which heading you want to travel to go from point A to point B, you might be a fair bit off if you don't use spherical or wgs-84 coordinates. This could result in the autonomous airport traffic taxing off the edge of a long taxiway, or getting pushed off the edge of a long runway, or doing other odd stuff. I think that should be OK, since the end points of all the long runs will be defined in the logical network in x,y, and they will have been converted in the same manner as the plane is, so it should hit them spot on. I'm just a touch worried that it will appear to describe an arc down the runway though as it gets converted to WGS84 in my simple scheme for rendering. Still, if it doesn't work I can always use a full conversion to WGS84 for both the network and planes. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
re [Flightgear-devel] Taxiway signage and default.apt file
Curt Olson writes: Well as you get towards the poles the distortions increase if you are using a lon/lat = x/y projection. The flaw in your logic is if you map lon/lat directly to x/y headings in this coordinate system will be significantly different from headings in the real world (or the wgs-84 approximation to the real world.) Since flightgear uses a wgs-84 world, the heading you have to follow in flightgear to get to some lat/lon will be significantly different than what you are calculating. If FlightGear used the same projection then you'd be ok, but the headings in the two projection become significantly different as you move away from the equator. There are plenty of hacks you could use to make things work, but be careful because usually these hacks will come back to bite you later. :-) Hack!%? I'm sure the phrase you were looking for was 'design time optimisation' :-) Still, I take your point. I'll probably stick to using Flightgears existing coord systems. Cheers - Dave ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway signage and default.apt file
D Luff writes: Could somebody please help me get up to speed on placing taxiway signage. Is it possible to specify it in an .ind file and then drop the file into the scenery directory for Flightgear to pick up, or does the .ind file have to be run through Terragear during scenery generation first? Things have changed and you want to add these sorts of things now to the corresponding .stg file. In this case: w130n30/w122n37/958416.stg In the following .ind file (from the San Jose scenery): OBJECT SanJose OBJECT_STATIC tower.ac -121.93 37.3592 20 45 OBJECT_TAXI_SIGN Fy -121.924674 37.360965 16.07 220 OBJECT_TAXI_SIGN Fn -121.924674 37.360965 16.07 40 OBJECT_RUNWAY_SIGN 30L-12R -121.926628 37.359911 16.91 220 OBJECT_TAXI_SIGN F -121.926628 37.359911 16.91 40 OBJECT_TAXI_SIGN Yc -121.919099 37.355383 18.44 130 OBJECT_TAXI_SIGN Y -121.919099 37.355383 18.44 310 what do the y, n and c mean after the taxiway sign letter? Dave, Reference this image: http://www.flightgear.org/Gallery/Link/KSJC-signex4.html The sign would be defined by Yc. - Capital letters are yellow on black. - Lowercase letters are black on yellow - '' and '' get mapped into arrows. - We don't have a symbol for arrows pointing in other directions. Additionally, does anyone have a description for the various letters used in the default.apt file, or is it necessary to e-mail Robin directly? I have made the FAQ for this file format available on the FlightGear web page: http://www.flightgear.org/Docs/AirNav/AptNavFAQ.FlightGear.html FWIW, ground ATC control needs some sort of encoding of taxiway and hold point names in order to give plausible directions, so automatic placement of taxiway signage should come for free on the back of this. Robin's database has space for the taxiway names, but this information is not been entered for any airports. If we had this info, we might be able to make a plausible stab at autogenerating runway/taxiway signs. Would not be an easy chore though ... Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway signage and default.apt file
- Capital letters are yellow on black. - Lowercase letters are black on yellow - '' and '' get mapped into arrows. - We don't have a symbol for arrows pointing in other directions. How about '/' and '\' for diagonal exits, '-' for the '' doublehead ? And, now I think about it, '$' for red-and-white do-not-enter sign and '*' (crater) for the word MIL ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: [Flightgear-devel] Taxiway signage and default.apt file
D Luff writes: Yes, thats what I was getting at. I didn't realise he had a name space though - I was assuming I'd have to make my own database. I still think I'll have to infact, since the information in Robin's is very much orientated towards rendering the taxiways and aprons, rather than describing them as a network. At the very minimum I'd probably need to add some junction and hold fields. I know Robin is interested in making his database as flexible and as complete as possible. He's a pretty good database guy, so it might be worth floating your ideas past him to see if he might be able to support these additional needs. In driving simulation we have the 3d model of the world, but we also have something called a 'logical road network.' You don't see the logical road network visually, but it allows the autonomous traffic to have reasonable behavior and it allows the system to do things like calculate your distance from the lane center. Perhaps for ATC and AI aircraft on the ground it would make sense to create a logical taxiway network (and perhaps a logical airway network too.) Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: re [Flightgear-devel] Taxiway signage and default.apt file
D Luff writes: Yes, that's basically what I'm planning to do. I keep forgetting you're a driving sim guy and probably have some very relevant expertise here. What co-ordinate systems are you using? That's not a trivial question to answer, why don't I say we are using the MN state plane coordinate system which maps into X, Y, Z with Z being up, X being in the longitude direction, and Y being in the latitude direction. At airport level lat/lon spherical co-ordinates are really overkill for whats basically a planar problem. I was considering assuming that for a limited area (a few miles each way) one could assume that lines of lat and lon were straight and parallel, and possibly map the lat/lon to x/y depending on latitude to get the x and y axis subdivisions equal. This would be a lot cheaper that doing proper spherical - planar projection. The logical network would be defined in terms of these x,y and the airplanes lat/lon quickly and cheaply converted. Comments? For doing 2d positions near the airport that might be ok, but when you calculate which heading you want to travel to go from point A to point B, you might be a fair bit off if you don't use spherical or wgs-84 coordinates. This could result in the autonomous airport traffic taxing off the edge of a long taxiway, or getting pushed off the edge of a long runway, or doing other odd stuff. Regards, Curt. -- Curtis Olson IVLab / HumanFIRST Program FlightGear Project Twin Cities[EMAIL PROTECTED] [EMAIL PROTECTED] Minnesota http://www.menet.umn.edu/~curt http://www.flightgear.org ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: re [Flightgear-devel] Taxiway signage and default.apt file
On Fri, 1 Mar 2002 20:37:57 -, D Luff [EMAIL PROTECTED] wrote: Curt Olson writes: In driving simulation we have the 3d model of the world, but we also have something called a 'logical road network.' You don't see the logical road network visually, but it allows the autonomous traffic to have reasonable behavior and it allows the system to do things like calculate your distance from the lane center. Perhaps for ATC and AI aircraft on the ground it would make sense to create a logical taxiway network (and perhaps a logical airway network too.) Yes, that's basically what I'm planning to do. I keep forgetting you're a driving sim guy and probably have some very relevant expertise here. What co-ordinate systems are you using? snip One idea for the future I had considered was the 'skymap': An alpha-chnneled 3D 'overlay' for the terrain showing TMA, airways, restricted airspace etc. This could (if kept up to date) have real-world value in relating chart information to visual references to allow pilots to gain a better appreciation of the 'lines in the sky' and so reduce incursions etc. (ob mainly useful for VMC pilots). This is particularly relevant to the UK, where the airspace is crowded and the 'areas' legion. An obvious companion/expnasion would be 3D 'approach plates'. Just a thought, anyway. Maybe in the far future... fx: climbs back under stone Rick -- David Farrent and Dougie O'Hara on the Cold War role of the ROC: 'What a world of sorrow is hidden in those few words - [Post attack] crew changes would have been based on crew availability.' ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
Re: re [Flightgear-devel] Taxiway signage and default.apt file
One idea for the future I had considered was the 'skymap': An alpha-chnneled 3D 'overlay' for the terrain showing TMA, airways, restricted airspace etc. Yup. It would be valuable for teaching the Class B areas in the USA too. Just a thought, anyway. Maybe in the far future... I mentioned a while ago that when someone gives me a tool I can understand for drawing airspace as 3D alpha'ed translucent walls, I would put the whole of the airspace restrictions around San Diego into the scenery as an overlay. Nobody has taken me up on this yet ... ___ Flightgear-devel mailing list [EMAIL PROTECTED] http://mail.flightgear.org/mailman/listinfo/flightgear-devel
