Re: [Flightgear-devel] apt.dat changes ?
Hi, let me comment on the current apt.dat performance i.e. of the time spent in fgAirportDBLoad: ~25% of time time is spent in simgear::strutils::split ~10% is spent in atof() Measured with Intel VTune using MS Visualc C++ 2005. IMHO it is an indicator that we should not use a plain text format. I have no experiences with the performance of binary XML representations. Cheers Olaf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Olaf Flebbe wrote : Hi, let me comment on the current apt.dat performance i.e. of the time spent in fgAirportDBLoad: ~25% of time time is spent in simgear::strutils::split ~10% is spent in atof() Measured with Intel VTune using MS Visualc C++ 2005. IMHO it is an indicator that we should not use a plain text format. I have no experiences with the performance of binary XML representations. There is not much information here. If you tell us what cost us fgAirportDBLoad in the whole initialisation process, we could decide if it's worth optimizing it. And you're missing a bit of history here : The airport file used to be binary and it was decided that a text file was easier to maintain. No endianess or integer size problem, no compilation phase. MetaKit was a PITA at the time. -Fred -- Frédéric Bouvier http://frfoto.free.fr Photo gallery - album photo http://www.fotolia.fr/p/2278 Other photo gallery http://fgsd.sourceforge.net/ FlightGear Scenery Designer ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Guys, I've been operating under the assumption that load performance for FG is not a requirement for apt.dat because you guys are already pre-processing the file to make scenery, and could thus convert the apt.dat file to something faster to read _if_ you wanted to trade load time for the benefits of text. *cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
2006/6/15, Frederic Bouvier [EMAIL PROTECTED]: Olaf Flebbe wrote : Hi, let me comment on the current apt.dat performance i.e. of the time spent in fgAirportDBLoad: ~25% of time time is spent in simgear::strutils::split ~10% is spent in atof() Measured with Intel VTune using MS Visualc C++ 2005. IMHO it is an indicator that we should not use a plain text format. I have no experiences with the performance of binary XML representations. There is not much information here. If you tell us what cost us fgAirportDBLoad in the whole initialisation process, we could decide if it's worth optimizing it. Reading the airportlist needs roughly half of the startup time. And you're missing a bit of history here : The airport file used to be binary and it was decided that a text file was easier to maintain. No endianess or integer size problem, no compilation phase. MetaKit was a PITA at the time. I didn't know this. Was there an attempt to create a binary representation on-the-fly when a new apt.dat was detected? Cheers Olaf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Reading the airportlist needs roughly half of the startup time Sorry, more precisly it is 19% ;-) ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Am Montag 12 Juni 2006 01:10 schrieb Ampere K. Hardraade: On Saturday 10 June 2006 13:15, Tony Pelton wrote: heck, even taking the records, and stuffing those records, as they are now, into XML would be a start. Already in XML format... http://www.cs.yorku.ca/~cs233144/export_cyyz.svg http://www.cs.yorku.ca/~cs233144/export_eddf.svg http://www.cs.yorku.ca/~cs233144/export_eddh.svg http://www.cs.yorku.ca/~cs233144/export_etou.svg http://www.cs.yorku.ca/~cs233144/export_ksfo.svg Which brings me to an idea. What if the airport format is enriched svg. That way the physical airport layout is in svg and might be viewed with a standard svg viever/editor. Converting electronic airport charts to svg works already. The logical layout (taxiway names, aprons, tower locations etc.) is then put on top of that (i.e. extra tags and attributes). Don't know wether svg editors will preserve unknown tags and attributes. If they do, the physical airport layout can then be changed with a standard svg drawing program (e.g. inkscape). Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Thomas Förster wrote: Don't know wether svg editors will preserve unknown tags and attributes. If they do, the physical airport layout can then be changed with a standard svg drawing program (e.g. inkscape). That's the nice thing about XML: you just have to put your own tags and attributes in your own namespace, include that namespace and then tools should at least preserve them, even if they don't understand their meaning. Nine ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Having edited airports there are a few things that tools like TaxiDraw provide that are invaluable; 1) super-imposing the airport layout on top of a scaled background image to allow placement of taxiways etc in proportion to the RL layout. 2) providing lat/long readout for any point on the layout. 3) showing centre lines for runways/taxiways. 4) catering for such things as edge lighting and centre line lighting etc. 5) exporting the beacon information to stg files not to mention; layering info, (even biezer curves will need layering at the interfaces), surface types etc. If a program like Inkscape can duplicate this and is multiplatform then by all means. As you might have gathered, I have no experience with Inkscape and am looking for comments and affirmations rather than flame-wars... I believe a more generic and structured approach to the apt format is desirable as long as there isn't a re-adjustment period that means we are left devoid of current capabilities. I also see merit in maintaining a commonality between x-plane ad fgfs as it increases the resources available for further development albeit on a cooperative basis. We also need to keep in mind that a number of people have devoted a large amount of time and effort to interfacing with the apt.dat format, I feel their voices should be most prominent when any change like this is considered. :-D ene From: Thomas Förster [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] apt.dat changes ? Date: Mon, 12 Jun 2006 09:50:12 +0200 Am Montag 12 Juni 2006 01:10 schrieb Ampere K. Hardraade: On Saturday 10 June 2006 13:15, Tony Pelton wrote: heck, even taking the records, and stuffing those records, as they are now, into XML would be a start. Already in XML format... http://www.cs.yorku.ca/~cs233144/export_cyyz.svg http://www.cs.yorku.ca/~cs233144/export_eddf.svg http://www.cs.yorku.ca/~cs233144/export_eddh.svg http://www.cs.yorku.ca/~cs233144/export_etou.svg http://www.cs.yorku.ca/~cs233144/export_ksfo.svg Which brings me to an idea. What if the airport format is enriched svg. That way the physical airport layout is in svg and might be viewed with a standard svg viever/editor. Converting electronic airport charts to svg works already. The logical layout (taxiway names, aprons, tower locations etc.) is then put on top of that (i.e. extra tags and attributes). Don't know wether svg editors will preserve unknown tags and attributes. If they do, the physical airport layout can then be changed with a standard svg drawing program (e.g. inkscape). Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Need more speed? Get Xtra Broadband @ http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hallo Thomas ! Thomas Förster wrote: Which brings me to an idea. What if the airport format is enriched svg. That way the physical airport layout is in svg and might be viewed with a standard svg viever/editor. Converting electronic airport charts to svg works already. The logical layout (taxiway names, aprons, tower locations etc.) is then put on top of that (i.e. extra tags and attributes). This idea actually _does_ have appeal - hey, I'm right now busy with creating an SVG drawing - but I see one drawback here: Airport-creators or -maintainers are not _forced_ to think of the logical layout. Let's assume some flight simulation does not honour the logical layout at all and we'll experience people submitting airports without _any_ logic, not even the direction of the taxiway centerline, just consisting of the outlines of taxiways and runways. In order to do it 'right' (TM, yes, I know ;-) I'd prefer to have an airport description language that consists of nothing but the logical layout at least for those objects, that relate to the core airport operations (runway, taxiway, apron, tower location), forcing the user to create a logical sense behind _every_ object. Yes, I feel that this path might be a bit steep in the beginning but I believe it's the only one that saves us from major trouble once we expect every airfield to contain a certain amount of logic and realizing that noting's there. Opinions ? I must admit that from reading some explanations on the 8.50 format I still didn't understand which route this new format is heading for - I simply failed to find the logic in the description Regards, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Hallo Thomas ! Thomas Förster wrote: Which brings me to an idea. What if the airport format is enriched svg. That way the physical airport layout is in svg and might be viewed with a standard svg viever/editor. Converting electronic airport charts to svg works already. The logical layout (taxiway names, aprons, tower locations etc.) is then put on top of that (i.e. extra tags and attributes). This idea actually _does_ have appeal - hey, I'm right now busy with creating an SVG drawing - but I see one drawback here: Airport-creators or -maintainers are not _forced_ to think of the logical layout. Let's assume some flight simulation does not honour the logical layout at all and we'll experience people submitting airports without _any_ logic, not even the direction of the taxiway centerline, just consisting of the outlines of taxiways and runways. In order to do it 'right' (TM, yes, I know ;-) I'd prefer to have an airport description language that consists of nothing but the logical layout at least for those objects, that relate to the core airport operations (runway, taxiway, apron, tower location), forcing the user to create a logical sense behind _every_ object. Yes, I feel that this path might be a bit steep in the beginning but I believe it's the only one that saves us from major trouble once we expect every airfield to contain a certain amount of logic and realizing that noting's there. Opinions ? I must admit that from reading some explanations on the 8.50 format I still didn't understand which route this new format is heading for - I simply failed to find the logic in the description Regards, Martin. -- Agreed if I understand you placing blobs on a layout just to get the outline right is not productive in the long run it might solve an immediate problem but doesn't contribute to the maintenance of that data hence curves are going to be necessary to allows whatever tools to enforce the certain amount of logic ideal ...as mentioned I believe there will be a degree of resistance if it is perceived that current tools (that people are familiar with) won't be valid... I don't believe this is a reason not to pursue the certain amount of logic ideal, but a reason to mitigate a migration path that everyone involved, understands. :-D ene _ Shop til you drop at XtraMSN Shopping http://shopping.xtramsn.co.nz/home/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
This idea actually _does_ have appeal - hey, I'm right now busy with creating an SVG drawing - but I see one drawback here: Airport-creators or -maintainers are not _forced_ to think of the logical layout. Let's assume some flight simulation does not honour the logical layout at all and we'll experience people submitting airports without _any_ logic, not even the direction of the taxiway centerline, just consisting of the outlines of taxiways and runways. Better have just the outlines than having nothing at all. People more experienced in airport layout could take over and add the missing parts. Welcome to the power of open source. I for myself would volunteer for this since I don't like redrawing runway borders from an aerial. Its all about collaboration :-) In order to do it 'right' (TM, yes, I know ;-) I'd prefer to have an airport description language that consists of nothing but the logical layout at least for those objects, that relate to the core airport operations (runway, taxiway, apron, tower location), forcing the user to create a logical sense behind _every_ object. This is exactly what I have in mind. It just contains 'embedded' svg descriptions of the physical layout of the parts that make up the logical model. Something like this fg:runway id=03L fg:runwaypart material=concrete svg:polygon /fg:runwaypart fg:runwaypart material=asphalt svg:polygon ... /fg:runwaypart /fg:runway (NOTE I dont know svg syntax :-)) Of course this also means that only an svg editor is not enough to fully specify an airport. Yes, I feel that this path might be a bit steep in the beginning but I believe it's the only one that saves us from major trouble once we expect every airfield to contain a certain amount of logic and realizing that noting's there. Opinions ? I think this is a quality control issue. So it should be solved in the process rather than in the data format. I must admit that from reading some explanations on the 8.50 format I still didn't understand which route this new format is heading for - I simply failed to find the logic in the description ASFIU they only want to provide the high-level description and leave everything else to the sim. That makes it easy for airport modellers since there are less options but I can see issues arising regarding flexibility. Example case: I've seen taxi lights standing besides the asphalt and on the other hand others buried within the taxiway concrete. Just specifying that there is taxiway lighting is not enough in my opinion. Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On 12/06/2006, at 9:37 PM, Thomas Förster wrote: snip Of course this also means that only an svg editor is not enough to fully specify an airport. In the case of Inkscape (I don't know about any of the other SVG editors), a reasonably simple plugin should suffice for editing the non-graphical aspects of the airport layout. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi This idea actually _does_ have appeal - hey, I'm right now busy with creating an SVG drawing - but I see one drawback here: Airport-creators or -maintainers are not _forced_ to think of the logical layout. Let's assume some flight simulation does not honour the logical layout at all and we'll experience people submitting airports without _any_ logic, not even the direction of the taxiway centerline, just consisting of the outlines of taxiways and runways. Better have just the outlines than having nothing at all. People more experienced in airport layout could take over and add the missing parts. Welcome to the power of open source. I for myself would volunteer for this since I don't like redrawing runway borders from an aerial. Its all about collaboration :-) it's not just layout that is important, there have been instances where people have wanted uni-directional runways... this could just as equally apply to taxiways (I haven't come across any examples of this YET!)... defining taxi-ways as unirdirection or bidirectional could cater for specifically styled runway signs (if indeed this was the case in RL)... taking it a step further... apron markings could be layered over this. With the proprietry APT format this would be hard to implement...a more generic tree structure would be more extensible (I think this has been mentioned before as an advantage) In order to do it 'right' (TM, yes, I know ;-) I'd prefer to have an airport description language that consists of nothing but the logical layout at least for those objects, that relate to the core airport operations (runway, taxiway, apron, tower location), forcing the user to create a logical sense behind _every_ object. This is exactly what I have in mind. It just contains 'embedded' svg descriptions of the physical layout of the parts that make up the logical model. Something like this fg:runway id=03L fg:runwaypart material=concrete svg:polygon /fg:runwaypart fg:runwaypart material=asphalt svg:polygon ... /fg:runwaypart /fg:runway (NOTE I dont know svg syntax :-)) Of course this also means that only an svg editor is not enough to fully specify an airport. Just as a text editor will edit a dat file... TaxiDraw does a much better job because it enforces a set of rules. Yes, I feel that this path might be a bit steep in the beginning but I believe it's the only one that saves us from major trouble once we expect every airfield to contain a certain amount of logic and realizing that noting's there. Opinions ? I think this is a quality control issue. So it should be solved in the process rather than in the data format. Agreed, the tool enforces the quality control and the data format stores that information such that the result of the rules is also stored for other editing sessions. I must admit that from reading some explanations on the 8.50 format I still didn't understand which route this new format is heading for - I simply failed to find the logic in the description ASFIU they only want to provide the high-level description and leave everything else to the sim. That makes it easy for airport modellers since there are less options but I can see issues arising regarding flexibility. Example case: I've seen taxi lights standing besides the asphalt and on the other hand others buried within the taxiway concrete. Just specifying that there is taxiway lighting is not enough in my opinion. Thomas :-D ene _ Need more speed? Get Xtra Broadband @ http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi, dene maxwell wrote: it's not just layout that is important, there have been instances where people have wanted uni-directional runways... this could just as equally apply to taxiways (I haven't come across any examples of this YET!)... defining taxi-ways as unirdirection or bidirectional could cater for specifically styled runway signs (if indeed this was the case in RL)... taking it a step further... apron markings could be layered over this. With the proprietry APT format this would be hard to implement...a more generic tree structure would be more extensible (I think this has been mentioned before as an advantage) As it seems, the X-Plane authors are not keen to go away from the apt.dat format, so if FlightGear would go away from bidirectional compatibility with apt.dat, this would result in a clear split of the databases and in ceasing the up to now fruitful exchange of data between FlightGear and X-Plane. Keep this in mind when assessing the advantages of a new, totally different format. Thomas Förster wrote: Example case: I've seen taxi lights standing besides the asphalt and on the other hand others buried within the taxiway concrete. Just specifying that there is taxiway lighting is not enough in my opinion. ...and that's why that is to change in the new apt.dat-format. They have both polygonal pavement sections, but also polyline sections, by which rows of lights, markings, etc., can be placed accurately. Which brings us to the point where we have to draw our borderlights, etc., ourselves _in addition_ to the pavement, where in the past we simply placed a rectangle and activated lighting. However, given proper tools - which is what TaxiDraw is going for - we can make the tool support the user, by, e.g., automatically placing lines of borderlights around any new pavement polygon and allow the user to edit them or remove them as they wish. Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi, Ralf Gerlich schrieb: However, given proper tools - which is what TaxiDraw is going for - we can make the tool support the user, by, e.g., automatically placing lines of borderlights around any new pavement polygon and allow the user to edit them or remove them as they wish. Erm...I just wanted to add, that I don't mean that TaxiDraw isn't a proper tool right now %-) The intention was to express the direction of TaxiDraw towards a more flexible tool with the possibility for more high-level support in airport editing. At least that is my vision, and it seems that TaxiDraw-master Dave Luff seems to like that vision. Am I wrong, Dave? ;-) Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Am Montag, 12. Juni 2006 12:28 schrieb Ralf Gerlich: Hi, Ralf Gerlich schrieb: However, given proper tools - which is what TaxiDraw is going for - we can make the tool support the user, by, e.g., automatically placing lines of borderlights around any new pavement polygon and allow the user to edit them or remove them as they wish. Erm...I just wanted to add, that I don't mean that TaxiDraw isn't a proper tool right now %-) The intention was to express the direction of TaxiDraw towards a more flexible tool with the possibility for more high-level support in airport editing. Neither do I. Taxidraw is an amazing tool right now. I was just thinking of ways to decrease your programming burden. :-) Thomas ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Ralf Hi, dene maxwell wrote: it's not just layout that is important, there have been instances where people have wanted uni-directional runways... this could just as equally apply to taxiways (I haven't come across any examples of this YET!)... defining taxi-ways as unirdirection or bidirectional could cater for specifically styled runway signs (if indeed this was the case in RL)... taking it a step further... apron markings could be layered over this. With the proprietry APT format this would be hard to implement...a more generic tree structure would be more extensible (I think this has been mentioned before as an advantage) As it seems, the X-Plane authors are not keen to go away from the apt.dat format, so if FlightGear would go away from bidirectional compatibility with apt.dat, this would result in a clear split of the databases and in ceasing the up to now fruitful exchange of data between FlightGear and X-Plane. Keep this in mind when assessing the advantages of a new, totally different format. I have made this point before, IMHO it is preferrable that we both (FG Xplane) stay with the same format if only for the reason that the more people that are working on getting airport layouts correct the better both the end results are going to be no matter how we process the data in each application. My flights (pardon the pun) of fancy are only a way of sharing some ideas on where the furture will lead us. They are certainly not a proposal we go our(FGFS) own way independantly. The more discussion and more ideas that are proposed then any final choice can only be more informed (even the most ridiculous idea might have some merit even if to discount it). Thomas Förster wrote: Example case: I've seen taxi lights standing besides the asphalt and on the other hand others buried within the taxiway concrete. Just specifying that there is taxiway lighting is not enough in my opinion. ...and that's why that is to change in the new apt.dat-format. They have both polygonal pavement sections, but also polyline sections, by which rows of lights, markings, etc., can be placed accurately. Which brings us to the point where we have to draw our borderlights, etc., ourselves _in addition_ to the pavement, where in the past we simply placed a rectangle and activated lighting. However, given proper tools - which is what TaxiDraw is going for - we can make the tool support the user, by, e.g., automatically placing lines of borderlights around any new pavement polygon and allow the user to edit them or remove them as they wish. as mentioned, a certain amount of logic can be enforced at a data structure level or at a tool level, I believe it should be done at the tool level at this stage of the discussion as it leaves the data structure more open and able to cater for unforseen developments. Whether or not the APT data format is most suitable now is largely irrelevant...without a universal agreement that it should be discarded and a clean start should be made it is the legacy format and the 850 proposal is a definite step forward... who knows what ingenious changes are possible in the apt format to accomodate some of the flights of fancy that have been expressed. Cheers, Ralf regards :-D ene _ Find the coolest online games @ http://xtramsn.co.nz/gaming ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Guys, First I must say I have not read the past FG-dev discussion on this ... if someone can point me to a thread title name or date range I will catch up. The 850 apt.dat format came out of about 3 years of banging our head on the problem inside LR, but I suspect that the things we've struggled with are similar to some of the approaches described here. To try to answer some questions: X-Plane has ended up more and more using a 'compiler' approach to our scenery, where we view the process of making scenery as a series of transformations on data. The final transformation is into some kind of distribution format, the assembly code of our scenery, where the format is meant to be fast to read, compact, and things the sim doesn't care about but tools do have been thrown out. Overall this has worked well for us, and I think is appearing a bit in apt.dat 850. In particular, really the apt.dat 850 taxiway layouts should be thought of as a planar map of bezier curves, but X-plane doesn't care, so 850 apt.dat is more of a derivative product of which a planar map is one of multiple possible sources. A topological network that has been 'extruded' into a taxiway set could also be the source. One of the advantages of a compiler approach is that different tools can create simcompatible layout without accepting the same abstractions. With that in mind, apt.dat 850 is low level...if you guys can get an SVG editor to output the kind of format you need, then that's great ! I just recommend that you consider the process a transform and not insist that the intermediate and final formats be the same...the design needs of the sim and the editing tools may be very different. (I should also say, for us they are different because X-plane is a commercial sim, so it's possible that FG can use the editing format as the distribution format where other sims can't. But I think having the two decoupled is useful for backward compatibility, if this is a goal.) ATC and Logical Layout: apt.dat 850 is a total punt - it makes no attempt to provide logical layout, machine-ready analysis of the layout, or things an ATC or AI implementation would need. This came out of pragmatism...we couldn't find a format that enforced these high level constructs, was still expressive enough to do all of the special-case things that authors would want to model real life, and would still be practical to implement. Based on the compiler model, a logical layout could be compiled into an apt.dat layout, but an apt.dat 850 layout might not be decompilable. Our assumption was that given higher level layouts, we would separately compile ATC/AI data if/when we need it. I see comments that something is better than nothing and also that this isn't a step in the right long-term direction. I will only say: right now we have _no_ higher level metadata defined in layouts and frankly the way that even the outline of the layout is expressed is a bit kludgy. So to me going to bezier curves is a step away from the wrong direction, even if it isn't a step in the right direction. (Did that make any sense?) I guess what I'm trying to say is: I wouldn't suggest sticking with overlapping quads because bezier curves don't have logical layout. If you can make a logical layout system work, then that's great, but at LR we saw that as out of our current scope. Border Lights: two thoughts...the apt.dat 850 spec specifically defines layouts as made entirely of old or new records...one of the things this implies is that FG or X-plane or any sim only has to generate 'clipped' taxiway lights for an old layout. That code can be skipped for a new layout, where all lights are explicitly placed. The problem of inset/non-inset lights is a tricky one...we're still going up and back on how much of these kinds of effects should be automatic vs explicit. For example, it seemed logical that x-plane would choose inset vs non-inset approach lights by looking at the presence of crossing taxiways, displaced threshholds, etc. On the other hand, we didn't think we could change a taxi line to have/not-have a black stripe based on the underlying terrain pavement. So I'm not sure what's best here...basically anything that could have a logical ruling but is considered too much of a PITA for the sim ends up pushed off to the tools...for our current code base the tools do a lot of work to make scenery pre-digestible and by choosing a similar strategy for airports we risk the same thing happening. But then it's all code that has to get written, whether it's in a tool or the sim's code base. In the end of the day I suppose it's a question of whether inset taxi lights are fundamentally different from non-inset ones or whether they represent two variations of the same concept. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK:
Re: [Flightgear-devel] apt.dat changes ?
Hi, Thomas Förster schrieb: Ralf Gerlich schrieb: Erm...I just wanted to add, that I don't mean that TaxiDraw isn't a proper tool right now %-) The intention was to express the direction of TaxiDraw towards a more flexible tool with the possibility for more high-level support in airport editing. Neither do I. Taxidraw is an amazing tool right now. I was just thinking of ways to decrease your programming burden. :-) Heh! You don't need to decrease my programming burden by (mentally) replacing TaxiDraw with an SVG-tool. I'd like to keep TaxiDraw, if only for the fun of working on it ;-) (of course, there's parts of that job that are a PITA, but gladly, it's only parts) Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Ralf, Ralf Gerlich wrote: As it seems, the X-Plane authors are not keen to go away from the apt.dat format, so if FlightGear would go away from bidirectional compatibility with apt.dat, this would result in a clear split of the databases and in ceasing the up to now fruitful exchange of data between FlightGear and X-Plane. Keep this in mind when assessing the advantages of a new, totally different format. I'm not 100% what you mean by this...we are supporting older apt.dat formats in x-plane ... we have to - in X-plane apt.dat can be embedded in custom scenery packas, so users can add old-format data to the sim in-field. So X-Plane will continue to read and show old-format data but without any new features. ...and that's why that is to change in the new apt.dat-format. They have both polygonal pavement sections, but also polyline sections, by which rows of lights, markings, etc., can be placed accurately. Accurately and arbitrarily! And this is one of our design choices. Given a choice between come up with a logical model that explains every possible combination of pavement and taxiway line markings and let the user put the paint where it is in real life we ended up at the second, after trying some schemes for the first and just spiraling totally out of control. We considered 'total realism' to be the goal, e.g. it would be unacceptable to have the wrong pavement markings (by real life standings) because the algorithm to generate them couldn't be expressed by our logic model. Of course, such an expressive logic model would be valuable for a number of things, so it might make sense to develop one for FG...in the case of X-Plane it didn't fit with our development roadmap. However, given proper tools - which is what TaxiDraw is going for - we can make the tool support the user, by, e.g., automatically placing lines of borderlights around any new pavement polygon and allow the user to edit them or remove them as they wish. The 850 format also supports the tagging of the bezier edges with light codes, so to some extent the procedure of wrapping lights around pavement is made a little bit simpler, or at least the data file a little smaller. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi, BTW: Durk Talsma's AI-extension using external XML-files shows us that we _can_ extend the format without changing apt.dat at all. However, we still have the problem of keeping extensions like that in sync with changes from Robin Peel's database. Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
* Ralf Gerlich -- Monday 12 June 2006 13:42: BTW: Durk Talsma's AI-extension using external XML-files shows us that we _can_ extend the format without changing apt.dat at all. Of course, this is a bad example, as those extensions make the format basically useless for any other purpose than for the AI subsystem. No other subsystem in fgfs can load them, which is why I would rather get rid of this sooner than later and keep further such nonsense from being added to FlightGear. In the apt case an extension would surely be less evil. m. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Ralf, Ralf Gerlich wrote: There was criticism of the physical storage model of apt.dat, as it has been and probably will continue to be in version 850. I just wanted to say that, if the FlightGear project were to invent its own format - let's call it FGAPT for simplicity - and would then not be able to convert from APT to FGAPT _and_ backwards, we would lose the possibility of properly interchanging data with X-Plane and Robin Peel's database. We might not lose the possibility in total, but at least in part. Ah...well, it's that translatability that's most important I think ... there's really no reason why FG should be stuck with an X-Plane container model. Some time ago (it might be already a year ago) I had a discussion with Dave Luff on the topic of making TaxiDraw a bit more useable. At that time I had started customising scenery for my local area and found the way of working with single rectangles in TaxiDraw very awkward and time-consuming, in contrast to, e.g., just clicking along the centerline of a taxiway and having TaxiDraw generate the rectangles from that. This is where the compiler model works...it doesn't dictate a higher level abstraction, so it leaves authors like you and David to make the best internal model for TaxiDraw that you can come up with, one that plays to TaxiDraw's strengths and doesn't saddle you with implementing things you don't need. We had Christian Franz trying to take X-plane's final modeling format (OBJ) and stick extensions into it to make it into an editing format...this ended in repeated failure; by comparison, exporting from Blender works well. I also like the mindset of interpreting apt.dat as some kind of intermediate format of a compiler. However, as decompilation into a higher-level format is not possible, apt.dat even in its new form does not seem to be a good format for keeping in a central database based on which updates to the airport layouts are made. Such a format needs to keep the top-level information modellers see in their editor, so that the next one can simply import that top-level model from the database and go on where his/her predecessor left. This is exactly the reason why we have sourcecode in our CVS and not the intermediate register transfer language (RTL) of the GNU C/C++ compiler suite ;-) Well, there is the problem: if you want to database the highest level layout info, you need to standardize the high level model. I'm not against doing that...but to some extent it's beyond the scope of apt.dat 850...to some extent apt.dat 850 says what data x-plane will eat, but nothing about where it comes from. The intention is that the programs that create that data will have a more descriptive format that makes editing practical. *Cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Ben, bsupnik schrieb: Ralf Gerlich wrote: There was criticism of the physical storage model of apt.dat, as it has been and probably will continue to be in version 850. I just wanted to say that, if the FlightGear project were to invent its own format - let's call it FGAPT for simplicity - and would then not be able to convert from APT to FGAPT _and_ backwards, we would lose the possibility of properly interchanging data with X-Plane and Robin Peel's database. We might not lose the possibility in total, but at least in part. Ah...well, it's that translatability that's most important I think ... there's really no reason why FG should be stuck with an X-Plane container model. Exactly. [SNIP] Well, there is the problem: if you want to database the highest level layout info, you need to standardize the high level model. Then that's where we need to work with you and Robin Peel regarding the next generation database ;-) Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hello Ben, bsupnik wrote: X-Plane has ended up more and more using a 'compiler' approach to our scenery, where we view the process of making scenery as a series of transformations on data. FlightGear uses this compilation aproach for ages and we're currently working on improving the process - this is why a foresighted airport description format would come very handy right now ;-) But scenery generation actually is not the whole story. Think of placing your aircraft at the beginning of runway 05R at EDDL at runtime - the simulation somehow needs to have access to the runway locations and the FlightGear simulation runtime uses the 'apt.dat' for this purpose as well. Which pint is the simulation supposed to pick for this purpose ? I still failed to understand the logic in the description on: http://www.x-plane.org/home/robinp/Apt850.htm to my current impression the description is a bit inconsistent. The explanation for type '100' contains the following text: The following rows are repeated for each end of the runway: 35.04420900 Latitude (in decimal degrees) of runway threshold at centreline -106.59855700 Longitude (in decimal degrees) of runway threshold at centreline The example for KABQ reads: 100 08x 49 02 2 0.25 1 2 1 35.04420900 -106.59855700 300 200 3 2 1 1 2 \ 2 3.00 35.04420900 -106.59855700 0300 3 2 0 1 1 2 3.50 How is this gonna work when the thresholds of the opposing runway ends are situated at the same location ? Shouldn't the meaning of the cited text be The following _columns ? I'm not trying to torpedo your work on the new schema, I'm simply trying to understand it _before_ I point my gun at you ;-) Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Ralf, Ralf Gerlich wrote: Well, there is the problem: if you want to database the highest level layout info, you need to standardize the high level model. Then that's where we need to work with you and Robin Peel regarding the next generation database ;-) Just to play devil's advocate: 1. How hard would it be to reconstruct a layout from the low-level apt.dat layout? I'm imagining a layout started in WorldEditor and then modified in TaxiDraw. Would you and I have to agree on a high-level interchange format, or could we reconstitute the info we need from the low level format? (I suppose this is a question about the editors - for an editor that truly built layouts from centerlines, there would I think be no way to reconstitute a layout. Because WED will be area-focused, it could probably rebuild a layout from its export, with the risk that some layouts would be invalid within WED.) 2. What if we databased the last author of a layout...the implication being that if you want to edit a layout in the DB and cannot work with the final apt.dat data, you contact the author and resolve the problem directly? Without this, it becomes necessary for all editors to agree on a high level format that is in the DB and thus is involved in lockstep. So I'm looking for a practical solution that would decouple this dependency. *cheers* Ben -- Scenery Home Page: http://scenery.x-plane.com/ Scenery blog: http://xplanescenery.blogspot.com/ Plugin SDK: http://www.xsquawkbox.net/xpsdk/ Scenery mailing list: [EMAIL PROTECTED] Developer mailing list: [EMAIL PROTECTED] ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hello Ben, bsupnik wrote: Martin Spott wrote: 100 08x 49 02 2 0.25 1 2 1 35.04420900 -106.59855700 300 200 3 2 1 1 2 \ 2 3.00 35.04420900 -106.59855700 0300 3 2 0 1 1 2 3.50 How is this gonna work when the thresholds of the opposing runway ends are situated at the same location ? Shouldn't the meaning of the cited text be The following _columns ? This appears to be a zero-meters-long runway. :-) I think this is simply a bad example in Robin's spec. The lat/lon pairs for the runway ends really should (must?) be different. It would be extremely nice to have at least one single, completely working example that really matches the proposed spec. This would significantly help to understand the schema by having a means to cross-check what I've grasped from the idea behind the new spec. Until then it's really difficult to tell if the new schema actually delivers what I'd expect from it or not - or at least to tell if the schema is comprehensive enough to derive missing information. Thanks, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Mon, 12 Jun 2006 09:24:05 -0400, bsupnik wrote in message [EMAIL PROTECTED]: Martin Spott wrote: It would be extremely nice to have at least one single, completely working example that really matches the proposed spec. This would significantly help to understand the schema by having a means to cross-check what I've grasped from the idea behind the new spec. Until then it's really difficult to tell if the new schema actually delivers what I'd expect from it or not - or at least to tell if the schema is comprehensive enough to derive missing information. Agreed...and as soon as we have such a thing, we will post it! (I would find such a thing useful too.) This stuff is still very very new. ..a proposal: Timed entries: I see 5 (6, 7, 8) versions of KOSH (Oshkosh, Wi), yours (_do_ check it out ;o)), the 3 RL ones (KOSH outside AirVenture, KOSH-North and KOSH-South) and Dene's version of the latter 3 that I (and maybe Pigeon) will put on one or more FGLiveCD's. ;o) ..during this and the next 4 AirVenture's, KOSH loses the 2 RWYs crossing RWY09/27 and dies, the carcass is chopped into KOSH-North which gains these 2 RWYs as taxiways while KOSH-South trades taxiway Alpha for RWY 18L/36R, details at AirVenture.org/atc/ . ..any chance these _timed_ entries versions of KOSH can replace your current version of KOSH? -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Melchior FRANZ wrote: * Melchior FRANZ -- Monday 12 June 2006 13:53: Of course, this is a bad example, as those extensions make the format basically useless for any other purpose than for the AI subsystem. No other subsystem in fgfs can load them, which is why I would rather get rid of this sooner than later [...] Again, this would much less apply to an apt.dat extension. But for the AI/Traffic system it's an artificial barrier for future improvements, and a violation of the FlightGear Way[TM]. It's beyond me how this could be accepted into cvs. The XML format in FlightGear has been chosen such that tag attributes are only used to describe the node properties (data-type, read-only, etc.). They are deliberately *not* used for *information*, because this couldn't be cleanly mapped to the property system. I was about to add a feature to the UFO editor that would have allowed to load AI files, to visualize the waypoints, to edit them, to assign vehicles etc. One would have been able to create paths by clicking on the tarmac, defining curve radii, etc. Finally, one could have saved the result into a ready-to-use AI file again. But all this doesn't work, because of this braindead decision. Melchior, I've tossed around various ideas with different people, and made a decision that seemed to be right at the time. I'm open to any constructive suggestion. Note that most people working on flightgear are doing this in their spare time and for personal reasons. Keep in mind that everybody writing code is inclined to do things in the best way possible in the best interest of the project. At times this involves the need to make decisions on the basis of limited information and even more limited feedback. Therefore, calling the decisions related to the AI traffic xml files braindead is just plain offensive, and has nothing to do with criticism. As other people have observed, criticizing other people's work is not you're strongest point, so please let me offer you some advice. If you follow the guidelines below, chances are you're still getting your message across, but without running the risk of accidentally or purposefully pissing somebody off. In the long run, I'll guarantee that that will not only be more beneficial to the project, but that it will also help in keeping this fine bunch of people motivated to work on the project: 1) Stick to the facts, leave out you're emotional appraisal of the problem. 2) Give explicit and objective reasons why something is wrong 3) If possible, propose an alternative solution. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Arnt Karlsen wrote: ..any chance these _timed_ entries versions of KOSH can replace your current version of KOSH? Wrong thread, please don't always hijack threads that deal with a totally different topic. This thread is about the structure, not about the content, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Monday 12 June 2006 04:22, dene maxwell wrote: Hi Having edited airports there are a few things that tools like TaxiDraw provide that are invaluable; 1) super-imposing the airport layout on top of a scaled background image to allow placement of taxiways etc in proportion to the RL layout. 2) providing lat/long readout for any point on the layout. 3) showing centre lines for runways/taxiways. 4) catering for such things as edge lighting and centre line lighting etc. 5) exporting the beacon information to stg files not to mention; layering info, (even biezer curves will need layering at the interfaces), surface types etc. If a program like Inkscape can duplicate this and is multiplatform then by all means. Let see... 1) Tracing taxiway outlines is time consuming and plain dumb. It takes hours just to create one airport. The SVG files on the other hand, are converted from FAA Airport Diagrams, and it only took one command. Separating all the info in a SVG files took me less than ten minute. 2) Lat/Long information is in the diagram itself. 3) You can create a new layer in inkscape and draw the center lines wherever you want. This degree of freedom would be extremely valuable when creating centerlines on the apron. 4) The lights could be automatically generated a long the edge of a taxiway, no big deal. 5) This functionality could be added to the bash script. Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Monday 12 June 2006 05:55, Hugo Vincent wrote: In the case of Inkscape (I don't know about any of the other SVG editors), a reasonably simple plugin should suffice for editing the non-graphical aspects of the airport layout. There should be no need for a plugin. Just create a new layer, name it as no-render, then put those non-graphical assets into it. Simple. Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Monday 12 June 2006 19:47, dene maxwell wrote: Unfortunately the data kept by FAA/CAA or what ever the local administration is called is often out-of-date or just plain wrong. Experience of the last month has taught me that. Poring over aerial photos and current third-party documentation has shown significant discrepencies. Keep in mind that those FAA/CAA diagrams are being used in real aviation right now, not the aerial photos or third-party documentation. While I would not rule out that that those airport diagrams may contain errors, I am more certain that the aerial photos and third-party documentation you mentioned are the ones that are wrong. Dumb is a very subjective assessment, agreed it is time-comsuming, but is sometimes necessary to get not only positioning correct but also surface type. The positioning would be correct as long as the lat/lon information on the aerial photo is correct. If those lat/lon information is incorrect, then all those time spent on positioning would be wasted. I seem to remember a while ago I provided examples of CAA airport documentation for conversion into SVG format and it couldn't be done because the color scheme used was not what the automated process needed. I am not aware of any numerical description available that would solve this. It is really great that you have managed to get this working for FAA diagrams ... It will be even better when it can be applied globally. It could be done. It just that I hardcoded the color information into my script, and was too lazy to alter it just to prove that it would work for CAA airport diagrams. 2) Lat/Long information is in the diagram itself. Generally the lat/long information in the FAA/CAA diagrams is too coarse for some uses. I am currently doing AI flightplans and need to get Lat/long for touch-down points, braking points, and taxi-ing points. TaxiDraw provides this 6 decimal places. The FAA diagram doesn't. So what? Users like you and I generate those 6 decimal places, from aerial photos and third-party documentations that have incorrect lat/lon information. Who have better access to those information? Us or the authorities? IIRC the French CAA diagrams don't even have lat/long references apart from the various navaid locations. Yes they do. Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Mon, 12 Jun 2006 18:56:02 -0400, Ampere wrote in message [EMAIL PROTECTED]: On Monday 12 June 2006 03:50, Thomas F�rster wrote: The logical layout (taxiway names, aprons, tower locations etc.) is then put on top of that (i.e. extra tags and attributes). You can group objects into different layers that you can named. You can also name an object, such as a polyline, as Taxiway X or Runway ##. The above SVG examples have the buildings, runways, and taxiways separated into different layers. These layers are named buildings, runways, and taxiways respectively. ..I like this scheme, will allow the 3 RL KOSH'es, KOSH-normal, and KOSH-North and KOSH-South during AirVenture, each in its own set of layers. :o) -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Ampere, I really don't want to pursue an arguement about right and wrong... the approaches are different and each has it's merits .. I would have really liked to have your tools available to me when I started converting the current FAA diagram On Monday 12 June 2006 19:47, dene maxwell wrote: Unfortunately the data kept by FAA/CAA or what ever the local administration is called is often out-of-date or just plain wrong. Experience of the last month has taught me that. Poring over aerial photos and current third-party documentation has shown significant discrepencies. Keep in mind that those FAA/CAA diagrams are being used in real aviation right now, not the aerial photos or third-party documentation. While I would not rule out that that those airport diagrams may contain errors, I am more certain that the aerial photos and third-party documentation you mentioned are the ones that are wrong. refer; http://airventure2006.blogspot.com/2006/06/kosh-apt-810-layout.html this is the data out of the apt-810 file represented in TaxiDraw and also appears in FGFS Scenery 09.10 http://airventure2006.blogspot.com/2006/06/faa-representation-of-kosh.html this is the current FAA representation of KOSH, note is does have taxiway Alpha and taxiway Papa is connected to the end of rwy22. http://airventure2006.blogspot.com/2006/06/aerial-photo-photo-only-2-years-old.html this is a 2-year old aerial photo notice the additional grass taxiways to the right and left of runway 36/18, the surarface types on runways 22 31 I have heaps more evidence of the various anomalies between the various documention sources and RL but I don't want to prove you wrong ... can we agree that TaxiDraw provides certain functionality at the moment that works with the current format of apt.dat... any replacement should provide the same functionality OR a mechanism whereby that functionality is not needed? is there away to convert svg format to btg to avoid TerrorGear? IIRC the French CAA diagrams don't even have lat/long references apart from the various navaid locations. Yes they do. Not Toulouse http://airventure2006.blogspot.com/2006/06/toulouse-aip.html Ampere Mate, I am really interested in the work you're doing and see real benefit it in as I said before right/wrong is not on my agenda ...how do we achieve the best given a starting point and a goal is. best regards :-D ene _ Become a fitness fanatic @ http://xtramsn.co.nz/health ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Tuesday 13 June 2006 00:06, dene maxwell wrote: but I don't want to prove you wrong ... can we agree that TaxiDraw provides certain functionality at the moment that works with the current format of apt.dat... any replacement should provide the same functionality OR a mechanism whereby that functionality is not needed? Sure. IIRC the French CAA diagrams don't even have lat/long references apart from the various navaid locations. Yes they do. Not Toulouse http://airventure2006.blogspot.com/2006/06/toulouse-aip.html You are on the wrong page! :P Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Tuesday 13 June 2006 00:32, Ampere K. Hardraade wrote: IIRC the French CAA diagrams don't even have lat/long references apart from the various navaid locations. Yes they do. Not Toulouse http://airventure2006.blogspot.com/2006/06/toulouse-aip.html You are on the wrong page! :P Ampere Haha, wrong document to begin with. Page 3, in http://www.cs.yorku.ca/~cs233144/Toulouse.pdf Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
What was ths source URL for that ..? ...it certainly provides that data needed I would like to add it to my AIP database Cheers :-D ene From: Ampere K. Hardraade [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] apt.dat changes ? Date: Tue, 13 Jun 2006 00:37:50 -0400 On Tuesday 13 June 2006 00:32, Ampere K. Hardraade wrote: IIRC the French CAA diagrams don't even have lat/long references apart from the various navaid locations. Yes they do. Not Toulouse http://airventure2006.blogspot.com/2006/06/toulouse-aip.html You are on the wrong page! :P Ampere Haha, wrong document to begin with. Page 3, in http://www.cs.yorku.ca/~cs233144/Toulouse.pdf Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Need more speed? Get Xtra Broadband @ http://jetstream.xtra.co.nz/chm/0,,202853-1000,00.html ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
dene maxwell wrote: What was ths source URL for that ..? French AIP VFR is on: http://www.sia.aviation-civile.gouv.fr/aip/enligne/UK/home.htm Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Saturday 10 June 2006 13:15, Tony Pelton wrote: heck, even taking the records, and stuffing those records, as they are now, into XML would be a start. Already in XML format... http://www.cs.yorku.ca/~cs233144/export_cyyz.svg http://www.cs.yorku.ca/~cs233144/export_eddf.svg http://www.cs.yorku.ca/~cs233144/export_eddh.svg http://www.cs.yorku.ca/~cs233144/export_etou.svg http://www.cs.yorku.ca/~cs233144/export_ksfo.svg Ampere ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Is there anybody on this list who is (or will be) following this discussion? There is one thing I would like to see added to this; It becomes pretty common for (former) Military airports over here to have an asphalt runway with two concrete touchdown zones giving best of both worlds, low friction and high (touch down) strength. I don't think this can be specified in the new format. Erik -- http://www.ehtw.info (Dutch)Future of Enschede Airport Twente http://www.ehofman.com/fgfs FlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Valid point Erik, I have run into a situation where a KOSH runway is 1/2 asphalt and 1/2 concrete...taking this to the nth degree a single runway might need to be divided into n segments each of different function...as you say an asphalt runway with two concrete touchdown zones or the KOSH situation above. What can be done to accomodate these situations and is it realistic to hope to get them into the next update I'm unsure as to the status of the apt850 doc, is it a proposal for comment or a statement of what the next version WILL be? regards :-D ene From: Erik Hofman [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] apt.dat changes ? Date: Sat, 10 Jun 2006 10:16:25 +0200 Is there anybody on this list who is (or will be) following this discussion? There is one thing I would like to see added to this; It becomes pretty common for (former) Military airports over here to have an asphalt runway with two concrete touchdown zones giving best of both worlds, low friction and high (touch down) strength. I don't think this can be specified in the new format. Erik -- http://www.ehtw.info (Dutch) Future of Enschede Airport Twente http://www.ehofman.com/fgfsFlightGear Flight Simulator ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Discover fun and games at @ http://xtramsn.co.nz/kids ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Fri, 9 Jun 2006 22:35:02 -0400, Tony wrote in message [EMAIL PROTECTED]: not sure if folks on this list care, or are aware ... but Ben Supnik has made a couple of RFC type posts to one of the x-plane lists, talking about a new design for the airport data coming from Robin Peel. This is apparently the spec that is emerging from those conversations. http://www.x-plane.org/home/robinp/Apt850.htm ..this proposal may improve things, but will not work for KOSH: http://80.239.32.252/notams/notam06.pdf and http://airventure.org/atc/ ..the above changes can be done in several ways, but all of these ways require a time or date header, and headers for _temporary_ or _recurring_ changes to the airport. E.G. KOSH effectively ceases to exist during AirVenture, and KOSH-SOUTH and KOSH-NORTH or somesuch replaces it. ..given timed headers, Robin's apt850 could last 5 years with no change for KOSH, the AirVenture dates has been set for the next 5 years. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Arnt, If you mean time and date headers that correspond to Real-Time for project teams developing Live like CD's they may cause problems..you and I and the rest of the project team want KOSH to be in the AirVenture configuration at the moment... but now doesn't fall within the time/date header parameters... would a Special Events check list be more flexible? Similair to selecting a starup RWY, you select a/or series of Special Event configurations... This could cater for AirVenture, WarBirds over Wanaka, Farnham or any other event that causes changes to an airport. I know from my experience with FGTools, FGFS and TaxiDraw that parsing the APT file is not trivial ...the downside is of course the need for a SpecialAPT.DAT to cater for this and the inherent support and maintenance needed. Mind you your say does mean that if I fly over the area( quite randomly) and it happens to fall within the 24 July-30 July timeframe the AI scenarios may also be active and the sky would be filled with planes... ;-) Cheers :-D ene not sure if folks on this list care, or are aware ... but Ben Supnik has made a couple of RFC type posts to one of the x-plane lists, talking about a new design for the airport data coming from Robin Peel. This is apparently the spec that is emerging from those conversations. http://www.x-plane.org/home/robinp/Apt850.htm ..this proposal may improve things, but will not work for KOSH: http://80.239.32.252/notams/notam06.pdf and http://airventure.org/atc/ ..the above changes can be done in several ways, but all of these ways require a time or date header, and headers for _temporary_ or _recurring_ changes to the airport. E.G. KOSH effectively ceases to exist during AirVenture, and KOSH-SOUTH and KOSH-NORTH or somesuch replaces it. ..given timed headers, Robin's apt850 could last 5 years with no change for KOSH, the AirVenture dates has been set for the next 5 years. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Find the coolest online games @ http://xtramsn.co.nz/gaming ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Sat, 10 Jun 2006 22:01:37 +1200, dene wrote in message [EMAIL PROTECTED]: Hi Arnt, If you mean time and date headers that correspond to Real-Time for project teams developing Live like CD's they may cause problems..you and I and the rest of the project team want KOSH to be in the AirVenture configuration at the moment... ..yup. ;o) but now doesn't fall within the time/date header parameters... would a Special Events check list be more flexible? ..you mean as an FG start-up menu entry? That and airventure.apt.gz and other.special.events.apt.gz's etc will work ok for us (FG) but not for xplane so they have to do a similar hack. Similair to selecting a starup RWY, you select a/or series of Special Event configurations... This could cater for AirVenture, WarBirds over Wanaka, Farnham or any other event that causes changes to an airport. ..aye. I know from my experience with FGTools, FGFS and TaxiDraw that parsing the APT file is not trivial ...the downside is of course the need for a SpecialAPT.DAT to cater for this and the inherent support and maintenance needed. Mind you your say does mean that if I fly over the area( quite randomly) and it happens to fall within the 24 July-30 July timeframe the AI scenarios may also be active and the sky would be filled with planes... ;-) ..like in RL, that's the idea, yes. Cheers :-D ene not sure if folks on this list care, or are aware ... but Ben Supnik has made a couple of RFC type posts to one of the x-plane lists, talking about a new design for the airport data coming from Robin Peel. This is apparently the spec that is emerging from those conversations. http://www.x-plane.org/home/robinp/Apt850.htm ..this proposal may improve things, but will not work for KOSH: http://80.239.32.252/notams/notam06.pdf and http://airventure.org/atc/ ..the above changes can be done in several ways, but all of these ways require a time or date header, and headers for _temporary_ or _recurring_ changes to the airport. E.G. KOSH effectively ceases to exist during AirVenture, and KOSH-SOUTH and KOSH-NORTH or somesuch replaces it. ..given timed headers, Robin's apt850 could last 5 years with no change for KOSH, the AirVenture dates has been set for the next 5 years. -- ..med vennlig hilsen = with Kind Regards from Arnt... ;o) ...with a number of polar bear hunters in his ancestry... Scenarios always come in sets of three: best case, worst case, and just in case. ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On 6/10/06, dene maxwell [EMAIL PROTECTED] wrote: I know from my experience with FGTools, FGFS and TaxiDraw that parsing the APT file is not trivial ...the downside is of course the need for a SpecialAPT.DAT to cater for this and the inherent support and maintenance needed. it's interesting that you would say this. i had the same experience when i was doing some work for an x-plane plugin, that parsing those files was tedious and so ... 1980's ... when Ben put the word out about changes to apt.data, as an RFC to the x-plane scenery list, i tried to advocate for an XML solution. i was shot down immediately, and _one_ of the reasons was that it was deemed that the current format is simple, and an XML format is more difficult, which i found to be the oppossite of my own thinking. it's nice to hear someone else say the current format is a pain too. Tony -- X-SA user ? 0.5.1 is out ! XData 0.1 for X-SA is out ! http://x-plane.dsrts.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi, Tony Pelton schrieb: On 6/10/06, dene maxwell [EMAIL PROTECTED] wrote: I know from my experience with FGTools, FGFS and TaxiDraw that parsing the APT file is not trivial ...the downside is of course the need for a SpecialAPT.DAT to cater for this and the inherent support and maintenance needed. it's interesting that you would say this. i had the same experience when i was doing some work for an x-plane plugin, that parsing those files was tedious and so ... 1980's ... [SNIP] it's nice to hear someone else say the current format is a pain too. Writing a parser is always work we rather wouldn't be doing as we'd rather devote ourselves to working with the data than to reading or writing it from or to file. What makes XML easier to parse is the presence of generic parser libraries that physically parse the XML entities. You still don't have your data cleanly fetched out of that. The property tree probably is one of the obligatory exceptions. The reason why parsing apt.dat is a PITA is the lots of data to be parsed and interpreted for runways and taxiways (lighting, material, stopways, etc.). This data doesn't get less with XML and it certainly won't get less with the new format. Cheers, Ralf ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On 6/10/06, Ralf Gerlich [EMAIL PROTECTED] wrote: Writing a parser is always work we rather wouldn't be doing as we'd rather devote ourselves to working with the data than to reading or writing it from or to file. yes. using XML, any number of parsers are available, AND they can do well formedness checks for you, AND XML is inherently more self documenting than record/delimeter based formats. The reason why parsing apt.dat is a PITA is the lots of data to be parsed and interpreted for runways and taxiways (lighting, material, stopways, etc.). This data doesn't get less with XML and it certainly won't get less with the new format. well, for me, it had nothing to do with the volume. it had to do with having to write lots of brittle code to parse the data. i mean seriously, a format that relies on having to understand the first field for any given record, as defining its type ... and having to do stuff like skip the first N lines ... and having an end of file record ? and to be advocating for expanding it ... in 2006 ? i was trying to advocate for XML, as i could have then brought XSLT and XPath tools to the table, in addition to having the parsing done for free, which would have made the data easier to use. i was also trying to point out that, ime, XML formats are much easier to mutate and keep compatible over the longer term, and XSLT is a great way for migrating older formats to newer formats. ultimately though, it looks like the decision will be more of the same ... Cheers, Ralf Tony -- X-SA user ? 0.5.1 is out ! XData 0.1 for X-SA is out ! http://x-plane.dsrts.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Tony Pelton wrote: well, if austin wrote it, besides being amused by the thought, you'd have to question his sanity, given the code base of parsers already available in the wild. I'm sure that XML would also end up with a few new features, like extend DTD while in flight and each element and tag now has it's Cl, Cm and Cd calculated individually, giving unprecedented flight realism. Josh ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Sat, 10 Jun 2006 11:40:23 -0500 Curtis L. Olson wrote: That's the big argument that Ben Supnik gave me. He converted a single airport to an xml represenation and it was about 2Mb just for the one airport. Of course he used the most verbose xml variant he could devise, but it is true that the data size would expand, and for this particular amount of data, it would likely be a substantial expansion. So you break the file up? -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear signature.asc Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Saturday 10 June 2006 20:34, Ralf Gerlich wrote: BTW: We still have some issues regarding the FlightGear graphics engine to solve if we want curved taxiways and generalised markings (stopbars, etc.), don't we? Yes, TerrorGear won't do anything with the new data. Who's up for some hairy 3D maths? Paul ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] apt.dat changes ?
not sure if folks on this list care, or are aware ... but Ben Supnik has made a couple of RFC type posts to one of the x-plane lists, talking about a new design for the airport data coming from Robin Peel. This is apparently the spec that is emerging from those conversations. http://www.x-plane.org/home/robinp/Apt850.htm fwiw. Tony -- X-SA user ? 0.5.1 is out ! XData 0.1 for X-SA is out ! http://x-plane.dsrts.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
Hi Tony, From my limited knowledge of how these are used (within the FG environment) they appear to be a positive evolutionary step. I like the idea of curves being corporated. Until tools like TaxiDraw integrate these changes there will be a gap but backward compatibiltiy appears catered for, so great. TerraGear will need to incorporate these changes for the full effect to be felt in the resulting btg files for FGFS. I like the concept of these changes, and look forward to these changes being rippled through to TaxiDraw and TerraGear. Thanks for the heads up :-D ene From: Tony Pelton [EMAIL PROTECTED] Reply-To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net To: FlightGear developers discussions flightgear-devel@lists.sourceforge.net Subject: [Flightgear-devel] apt.dat changes ? Date: Fri, 9 Jun 2006 22:35:02 -0400 not sure if folks on this list care, or are aware ... but Ben Supnik has made a couple of RFC type posts to one of the x-plane lists, talking about a new design for the airport data coming from Robin Peel. This is apparently the spec that is emerging from those conversations. http://www.x-plane.org/home/robinp/Apt850.htm fwiw. Tony -- X-SA user ? 0.5.1 is out ! XData 0.1 for X-SA is out ! http://x-plane.dsrts.com ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel _ Shop til you drop at XtraMSN Shopping http://shopping.xtramsn.co.nz/home/ ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] apt.dat changes ?
On Fri, 9 Jun 2006 22:35:02 -0400 Tony Pelton wrote: not sure if folks on this list care, or are aware ... but Ben Supnik has made a couple of RFC type posts to one of the x-plane lists, talking about a new design for the airport data coming from Robin Peel. This is apparently the spec that is emerging from those conversations. http://www.x-plane.org/home/robinp/Apt850.htm Yeah, Robin's been discussing doing this for quite some time; it's good to see it coming closer to fruition. Curt, have you been following this? Maybe it'd be good if folks here who work on apps that read/work with apt.dat were involved in the RFC's discussion? -c -- Chris Metzler [EMAIL PROTECTED] (remove snip-me. to email) As a child I understood how to give; I have forgotten this grace since I have become civilized. - Chief Luther Standing Bear signature.asc Description: PGP signature ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
