Re: [Flightgear-devel] The future of FlightGear's support programs
On 04 Sep 2011, at 14:54, James Turner wrote: > > On 4 Sep 2011, at 07:05, Durk Talsma wrote: > >> If not, I might consider moving the taxidraw source over to gitorious and >> incorporate it as a subproject of fg. >> >> Any thoughts / ideas would be welcome. > > I think this is best answer - for programs the original author wishes others > to maintain / bugfix / enhance, they should live in the fg Gitorious project > (not necessarily the flightgear repository, of course). This could > potentially be done for Atlas, mpserver, and so on, if that helps > development. I agree; but ultimately, it should be up to the project admins whether they would prefer that or not. > > Are there reasons *against* moving support programs into the fg project? > Assuming the original developer is happy with other people on the flightgear > committers list potentially apply patches / bugfixes, of course. but I guess a slightly more refined version of my question is what to do when the original author / project admin no longer responds. I cannot recall what the actual situation is with regard to TaxiDraw. Last time I was in contact with David Luff, he mentioned that he would like to keep responsibility for the gps code, and was happy to abandon his ATC project. I also seem to recall that he mentioned something about taxidraw, but I'm not sure anymore what he wrote in this regard. Hopefully, I can find the email somewhere in my archieve and take it from there. > > Presumably we're require all such code to use the same license as FG or SG > (i.e either GPL or LGPL) to avoid headaches and confusion. > > Taxidraw is gpl licenced, so that shouldn't be a problem. On a more general note; while I think the discussion is about potential taxidraw substitutes is interesting (and also "on topic" considering my slightly broad subject title), I would like to mention that in addition to the GIS based tools, taxidraw is also the defacto tool for AI development. It is the most complete editing tool for creating ground networks, parking locations, etc etc. As such, it remains a vital and necessary tool. Cheers, Durk -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
I was refering to the post of: Geoff.-- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
No this must be automatic. I'd be prehistoric otherways. There was another discussion to move airports above ground for FPS (frames per second) reasons. Maybe someone should advice: psadro_gm-- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
HB-GRAL wrote: > To get XPlane gpl airport data into a postgres/postgis database as ESRI > shapes you can use the ogr2ogr gdal plugin written by Robin Peel [...] s/Robin Peel/Even Rouault/ I know because we've been exchanging a couple of EMails over the past three years while chasing a few bugs in his implementation ;-) BTW, I'm really wondering why this forum user "Psadro" decided to invent his own v8.50 apt.dat-parser because, according to his explanations, he's doing exactly what's already implemented in the corresponding OGR-frontend. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
Vadym Kukhtin wrote: > GeoFan from russian FG-forun had made airport layout in GRASS I have to admit that I'd rather trust a personal explanation of what this guy is actually doing than an automated translation ;-) Anyhow, note that, not only in real aviation life but also in FlightGear as well, there's a substantial difference between the visual representation of an arrangement which resembles the shape of an airfield on one hand and the logical entity of such on the other hand. Thus, if this guy has developed a tool to write an apt.dat-compatible file out of GRASS (or QGIS or whatever) after drawing an airport layout: Great. Otherwise I'd assume that TaxiDraw is still the best we have. It's still missing a few useful features (like reading geo-referenced background imagery for example) but aside from that it's doing a pretty good job for creating v8.10-compatible airfield-layouts. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Infrastructural changes to the AI system
Hi All, I just committed some changes to the flightgear/next branch of gitorious. I'm not reiterating my entire commit message, because that can be found here: https://www.gitorious.org/fg/flightgear/commit/35abe6d0ab947a8cd2a5eca703d7f731ad5dac65 I would just post this not here to note that I have made some changes to the caching mechanism of the traffic manager, as well as the recently introduced ground network cache. Because of this, you may see some warnings the next (few) time(s) you run flightgear, to inform you that the cache results are discarded. Because of this, traffic initialization may be a little slower than before, because the heuristics tables have to be rebuilt. This is normal, and you can safely ignore the warning. If anything more serious comes up, please let me know. I'm a little under the gun, work wise, until Tuesday afernoon 5PM, central european daylight savings time, but I hope to respond soon, should anything serious occur. Cheers, Durk -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Infrastructural changes to the AI system
Hi All, I just committed some changes to the flightgear/next branch of gitorious. I'm not reiterating my entire commit message, because that can be found here: https://www.gitorious.org/fg/flightgear/commit/35abe6d0ab947a8cd2a5eca703d7f731ad5dac65 I would just post this not here to note that I have made some changes to the caching mechanism of the traffic manager, as well as the recently introduced ground network cache. Because of this, you may see some warnings the next (few) time(s) you run flightgear, to inform you that the cache results are discarded. Because of this, traffic initialization may be a little slower than before, because the heuristics tables have to be rebuilt. This is normal, and you can safely ignore the warning. If anything more serious comes up, please let me know. I'm a little under the gun, work wise, until Tuesday afernoon 5PM, central european daylight savings time, but I hope to respond soon, should anything serious occur. Cheers, Durk-- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] flight recorder / replay system
Hi, I'm currently looking into an overhaul of the replay system. The buffer mechanisms of the existing replay system itself won't change, but I'm replacing the hard-coded recorder/FDM interface. Instead, I'll introduce a fully configurable "flight recorder". It's basically a "property recorder", so anything that's in the property tree can be recorded - and replayed. Aircraft-specific XML descriptions can be used to specify properties, data type and interpolation method (discrete, linear, or rotational in degrees/radiant) for each "signal". There'll be a set of default property lists which can be included, so only custom properties need to be specified manually. Naturally, all (existing) aircraft not providing any recorder configuration will use a default, matching the hard-coded system of <= FG 2.4.0. I have a prototype which also shows the new system is going to be faster, mainly since it doesn't resolve property paths at run-time and avoids copying data around. It'll also use less memory, since most properties can be recorded with reduced precision, e.g. it's unnecessary to record things like flap or gear position with full "double" precision. And the current system always records properties for 4 engines + 4 propellers + 6 tanks + 3 gear. With the new system, this can be easily adapted - a glider doesn't even need tank/gear/engine/propeller properties. On the other hand, most jet engine properties weren't recorded so far - this will also improve. And the obvious advantage of the new system is the option of recording custom properties. Finally, the new system also comes with a new replay "dialog". Looks more like a video player, provides a "time slider" and, also new, introduces slow-motion play back. Sneak preview: http://imageshack.us/photo/my-images/683/fgfsreplay.png/ I have a working prototype, but nothing ready to be committed. Meanwhile, constructive comments/ideas are welcome. cheers, Thorsten -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
2011/9/4 Martin Spott > Hi Yves, > > HB-GRAL wrote: > > > Personally I don?t know if there is a roadmap for taxidraw anymore. You > > can edit airport data with tools like Qgis directly and with much more > > comfort. > > Please explain. I haven't seen anyone building functional airports for > FlightGear out of data which had been edited in QGIS. > > Cheers, >Martin. > GeoFan from russian FG-forun had made airport layout in GRASS http://translate.googleusercontent.com/translate_c?hl=ru&rurl=translate.google.com.ua&sl=ru&tl=en&twu=1&u=http://www.flightgear.ru/forum/viewtopic.php%3Fp%3D1587%26sid%3D99b8153affdf249086a4bbbcf371d3eb&usg=ALkJrhi3YzbK9Pqg5ldWeYjsWX2n1AbNfg#p1587 -- --- WBR, Vadym. -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
Hi Yves, HB-GRAL wrote: > Personally I don?t know if there is a roadmap for taxidraw anymore. You > can edit airport data with tools like Qgis directly and with much more > comfort. Please explain. I haven't seen anyone building functional airports for FlightGear out of data which had been edited in QGIS. Cheers, Martin. -- Unix _IS_ user friendly - it's just selective about who its friends are ! -- -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
Am 04.09.11 17:11, schrieb Geoff McLane: > On Sun, 2011-09-04 at 15:01 +0200, Gijs de Rooy wrote: > [snip] >> Brings me to another question, are we allowed to use Robin's latest >> apt.dat, once we can handle the new format? Looks like that day isn't >> too far away anymore >> http://www.flightgear.org/forums/viewtopic.php?f=5&t=13240 >> >> Gijs >> > > Hi Gijs, > > Maybe I have the wrong understanding here but the > only reason we do not use the latest 850 apt.dat > is that it contains some 7,671 airports _NOT_ yet > in our scenery 1.0.1... > > So if you used this new data, and selected one > of those 'missing' airports, you would just be > placed in a field - with no airport/runways visible... > > Maybe in some cases, some of these airports may have > been added to the custom scenery data (via terrasync) > but that I do not know... and some individual efforts > like that in the forum messages... > > And conversely, using 850 you would NOT be able to > select some 301 airports that are in our 810 data, thus > drawn in our scenery 1.0.1, but are _NOT_ now in 850! > > And perhaps some similar problems with matching > ILS/DME etc... > > I guess the really _BIG_ question is, is there anyone > in our community currently working on re-generating > world wide scenery, taking advantage of this later > database? > Hi Geoff Interesting tool to compare recent data files, thanks ! Yes, I think there are people working on this very huge task of building World Scenery, at least Martin Spott is on I think. But this is such a big task, we still have to be patient. Just to clarify about my use of 810 and 850 aeronautical data: I am using 850 data experimental for the mapnik mapserver, as an example and to look into what comes around with current data cycle. I am NOT using it to promote this as base for scenery creation yet. Cheers, Yves ps. Anyway, when the experimental mapnik mapserver will run once on the official flightgear scenery server we will use current fg data from the flightgear database I think, and probably, probably some 850 data already integrated into our current official database by Martin Spott ... -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
On Sun, 2011-09-04 at 15:01 +0200, Gijs de Rooy wrote: [snip] > Brings me to another question, are we allowed to use Robin's latest > apt.dat, once we can handle the new format? Looks like that day isn't > too far away anymore > http://www.flightgear.org/forums/viewtopic.php?f=5&t=13240 > > Gijs > Hi Gijs, Maybe I have the wrong understanding here but the only reason we do not use the latest 850 apt.dat is that it contains some 7,671 airports _NOT_ yet in our scenery 1.0.1... So if you used this new data, and selected one of those 'missing' airports, you would just be placed in a field - with no airport/runways visible... Maybe in some cases, some of these airports may have been added to the custom scenery data (via terrasync) but that I do not know... and some individual efforts like that in the forum messages... And conversely, using 850 you would NOT be able to select some 301 airports that are in our 810 data, thus drawn in our scenery 1.0.1, but are _NOT_ now in 850! And perhaps some similar problems with matching ILS/DME etc... I guess the really _BIG_ question is, is there anyone in our community currently working on re-generating world wide scenery, taking advantage of this later database? I would certainly offer to help in any way I can in such a mammoth undertaking... I hope some others can clarify this very important scenery question... Regards, Geoff. OT: While recently testing Qt QThread interface I chose to load our FG 810, and compare it roughly with XP 850 - see http://geoffair.org/projects/qt_test_gui.htm where I also compared nav.dat, awy.dat and fix.dat files - FG versus XP (GPL) data seems to have a 90% plus correspondence, at least in 'names' - I did not do complete exact position/location testing... -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] Links for new FlightGear pilots
Hi Gijs, thank you very much for that detailed and competent analysis in such a short time-frame. Let me comment the most difficult question first: "Should it be a WIKI"? My many links "for further details see: WIKI..." and also several articles from me in the FGFS/wiki should reveal me as a big believer in WIKI's, as well FGFS as also WIKIPEDIA. I even have extracted some parts of the "current getstart.pdf" and put them into the FGFSwiki (and just reffed them with a few words in the manual). And I do want to do more of those! That way I also hope to get the valuable WIKI-idea promoted to be used even more, which would get them more attention and thus more chances to get them updated in reasonable time-spans. On the other hand: I believe WIKIs have their very big advantage in unique details - not really in manuals! In my eyes each product does need a manual that explains the "Basics" to the customer and then shows him where to get more infos.(Yes: I belong to the people looking into the manuals when buying a PC, TV, Auto, etc.!). And that basics (in my eyes) should express the "company's" (i.e. FlightGears inner devel circle) involvement/direction/supervision! My concern is, that many small pieces may be able to replace a manual at the beginning - but over a longer timeframe they will change, specialize, and lose their "connecting identities"! See the Curtis opening problem! And also see todays WIKI: All the informations are there - often in multiple versions and/or with different focuses. They are fantastic for the guys knowing the basics and thus what to look for - but difficult to select "what is needed" by a newbie! Surely it will be a big effort for anybody to keep it updated to all future FGFS-changes! But I believe those are easier to control in one single document under the Development responsibility and a defined content in unique chapters - then when the content is distributed in many small pieces without defined ownership and/or responsibility. (Does anybody have the slightest idea how many WIKIS are affected by the latest 2.4.0 changes??) Based on that fear I tried to structure "the Basics" in some unique Chapters that contain more technical dependencies and those that are more for teaching and looking. So with a new version you do not need to update everything - and what needs to be updated is at one known location only - not distributed in many uncontrollable pieces! And still it would be relatively easy to convert that manual to WIKI - if needed! Right now I would vote against it! And yes, sorry: I have forgotten to mention the very useful forums - - I will correct that! One more hot item I would like to sell: Sidebars or drop downs I decided against sidebars because of: 1) I wanted that book to be without any need for executable, supporting sftw. like e.g. "java" (virus-prone) 2) I tried it with sidebars - but then it becomes again very confusing if headers are more than just one short word. I hate indexes like now in the "getstart.pdf" - where you have long headers going over several lines. I like my solution that allows long, ease readable titles -- and still have room for a nice picture to it! 2) There are still many "customers" with old tiny screens - I rather wanted that valuable side-space for big illustrations 4) Those top/sidebars become pretty much a standard for industries and business pages - I thought my way gives more the feeling of "private pilot" to "private pilot" (I just did not yet find a place for the beer-can!) So I came up with that top menu-bar that stays there all the time. From wherever you are in the text, you can always just select any part in the bar (including the current one) and have that index in an easy to read fashion. I know it is unusual and may be one more mouse-click - but I personally like that more private atmosphere. But I would like to hear more comments to that. Thank you very much for the many other hints - they all seem very valuable - I will update accordingly. And surely we will talk again when I have a feeling for how that new style gets accepted inside the community. Thank you joe -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management sol
Re: [Flightgear-devel] ATC and radio signal attenuation
On Sunday, September 04, 2011 17:09:43 Torsten Dreyer wrote: > Hi Adrian, > > this all sounds very interesting and not only for AI Aircraft but also > for the navigation radios. I am currently refactoring the navradio code > and I'd really like to have a better propagation model than our current > distance-squared or hard-cutoff model. > > Torsten > Hi Torsten, the details of the implementation are as follows: - hard cut-off at 400km, - yet to be done: LOS mode with first Fresnel zone clearance (skips the point_to_point subroutine) - between user's aircraft and traffic/ATC within the 400 km zone, attenuation is calculated with point_to_point(): Line-Of-Sight Mode, Single Horizon, Double Horizon, Diffraction Dominant, Troposcatter Dominant. - the main issue is the fact that if the transmitter radio is located outside of the tile cache area, there will be no elevation profiles. I do not know how to handle this yet, but I know you probably do. - a link budget is established based on (yet) hardcoded values for transmitter power, receiver sensitivity and antenna gain at both ends. These are separated for ground stations and aircraft for obvious reasons. - loss is substracted from the link budget (working with dBm here). If resultant signal is lower then receiver treshhold, the communication is discarded. If the signal is within a zone where SNR has a great influence on reception, parts of the message are garbled. - this is all inside the trafficcontrol.cxx file, but it should probably be made independent. For me it was just a test run, to confirm that Durk's new ATC code works fine with this - and it does. I could see this applying to navradios too, except that in that case we have mostly continuous/repetitive transmissions, and this model relies on extracting an elevation profile between receiver and transceiver. Thus, optimizations to my code will most likely be necessary to use with navradios. Anyway, in all my tests terrain is blocking transmissions as expected and within the limits of the charts I have pre-generated and calibrated with physical signal-level readings. 73, Adrian, YO8RZZ -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
Am 04.09.11 16:01, schrieb Christian Schmitt: > HB-GRAL wrote: > >> Personally I don’t know if there is a roadmap for taxidraw anymore. You >> can edit airport data with tools like Qgis directly and with much more >> comfort. It’s sad, but I think we dont need it anymore. >> > > Well, you can import apt.dat data into QGIS via GDAL. But be aware that this > is a one-way road. Export is not possible with GDAL. > I hope I'll be able to write a postgres script to write out apt.dat text > files. Work is advancing slowly, however. > > Hi Chris Here is a link to some interesting(?) qgis plugins from Michael Minn. I use his .cvs export plugin from time to time, but the "direct" postgres or sql approach is probably a better way. Anyhow, here is the link: http://michaelminn.com/linux/mmqgis/ Cheers, Yves -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
Am 04.09.11 15:01, schrieb Gijs de Rooy: > Why not use Xplane's WED? Appears to be open-source (didn't check the license > though) and works with the 850 format... Hi Gijs I use QGis because with this one I edit current shape database directly, without any "conversion" of anything. And most of the geospatial resources like srtm data I need are avaiable als over- or underlays etc. To get XPlane gpl airport data into a postgres/postgis database as ESRI shapes you can use the ogr2ogr gdal plugin written by Robin Peel exactly for this purpose. Once you have this data in the database you can connect to the database with QGis and you see the points/lines/polygons, can edit this, save the result back to the database. No conversion and parsers etc. needed. Something we need, as I understand current ongoing processes is probably a QGis python or grass extension once which can write out to the current scenery format. > > Brings me to another question, are we allowed to use Robin's latest apt.dat, > once we can handle the new format? Looks like that day isn't too far away > anymore http://www.flightgear.org/forums/viewtopic.php?f=5&t=13240 > Robin Peels data is GPL2 and can be downloaded and used. Only one thing is not allowed, that is what I read in the forum, seeking the data, work on it and keep it private "out of GPL", like stated here http://www.flightgear.org/forums/viewtopic.php?f=5&t=13240#p134757 by mike4lin. This is complete rubbish, the original data is GPL, and also the edited data. Cheers, Yves -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] ATC and radio signal attenuation
Am 04.09.2011 14:15, schrieb Adrian Musceac: > I have started to implement radio signal attenuation into the ATC subsystem, > with the goal to later move this to it's own location. > I have chosen the Irregular Terrain Model (ITM) developed by Longley-Rice in > the 70's for several reasons: [..] Hi Adrian, this all sounds very interesting and not only for AI Aircraft but also for the navigation radios. I am currently refactoring the navradio code and I'd really like to have a better propagation model than our current distance-squared or hard-cutoff model. Torsten -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
HB-GRAL wrote: > Personally I don’t know if there is a roadmap for taxidraw anymore. You > can edit airport data with tools like Qgis directly and with much more > comfort. It’s sad, but I think we dont need it anymore. > Well, you can import apt.dat data into QGIS via GDAL. But be aware that this is a one-way road. Export is not possible with GDAL. I hope I'll be able to write a postgres script to write out apt.dat text files. Work is advancing slowly, however. Chris -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
Why not use Xplane's WED? Appears to be open-source (didn't check the license though) and works with the 850 format... Brings me to another question, are we allowed to use Robin's latest apt.dat, once we can handle the new format? Looks like that day isn't too far away anymore http://www.flightgear.org/forums/viewtopic.php?f=5&t=13240 Gijs Date: Sun, 4 Sep 2011 04:34:46 -0700 From: scrat_h...@yahoo.com To: flightgear-devel@lists.sourceforge.net Subject: Re: [Flightgear-devel] The future of FlightGear's support programs Qgis looks very good, but not very simple to use. Anyone to create a tutorial in the forum? -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
On 4 Sep 2011, at 07:05, Durk Talsma wrote: > If not, I might consider moving the taxidraw source over to gitorious and > incorporate it as a subproject of fg. > > Any thoughts / ideas would be welcome. I think this is best answer - for programs the original author wishes others to maintain / bugfix / enhance, they should live in the fg Gitorious project (not necessarily the flightgear repository, of course). This could potentially be done for Atlas, mpserver, and so on, if that helps development. Are there reasons *against* moving support programs into the fg project? Assuming the original developer is happy with other people on the flightgear committers list potentially apply patches / bugfixes, of course. Presumably we're require all such code to use the same license as FG or SG (i.e either GPL or LGPL) to avoid headaches and confusion. James -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
[Flightgear-devel] ATC and radio signal attenuation
Hi, This message is mostly meant for Durk, but I expect suggestions from anyone who knows the scenery subsystem of Flightgear. I have started to implement radio signal attenuation into the ATC subsystem, with the goal to later move this to it's own location. I have chosen the Irregular Terrain Model (ITM) developed by Longley-Rice in the 70's for several reasons: 1. the software was developed by an US government agency and is therefore public domain. Original code and documentation: http://flattop.its.bldrdoc.gov/itm.html 2. a more recent version of the software is available from the developers of Splat!, a GPL radio-propagation tool used by professionals and amateurs. This version is just a rewrite of the original C++ code that removes DLL-isms and adds useful comments. More information on Splat! and example use-cases can be found at: http://www.qsl.net/kd2bd/splat.html 3. this propagation model is extremely configurable and I have verified via experimental results it's precision (when fed with appropriate data). It is capable of computing line-of-sight atmospheric loss, troposcatter loss for non LOS endpoints, simple and double diffraction loss when terrain is a factor between the transceiver and the receiver. It does not calculate reflection on terrain features, and it's diffraction routines, especially for large knife-edge angles, have been verified to be inaccurate. Nevertheless, important improvements have been added by Sid Shumate et al. in the last few years, that increase the precision by a large number. These improvements, however, are limited by a non-commercial clause, so if there is a need for great accuracy one must compile his own ITM. His progress and detailed explanations on limitations and advantages of ITM can be tracked at the IEEE Broadcast Technology Society Newsletter. http://bts.ieee.org/ieee-broadcast-technology-society-newsletter.html This radio propagation model ensures that terrain between the station transmitting and the station receiving (the pilot) will block communication under the right circumstances, close to reality. The earth curvature is also taken into account and has an effect on signal quality. Apart from cutting off the transmission, I am also mangling the radio text if the signal-to-noise ratio is below a certain value. Coupled with festival voice, the results are interesting, but more could be done. The key point of the implementation is sampling of terrain elevation between the two radio terminals. This may require some scenery tile loading, but I leave that to the experts. So far, only ground to AI aircraft and AI aircraft to ground is implemented, as part of the FGATCController class. This system, if proven functional, should probably be split into a separate module and applied to all comunication, including player-to-ground and player- to-player. All code is available in my clone, branch radio-att. 73, Adrian, YO8RZZ -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
Qgis looks very good, but not very simple to use. Anyone to create a tutorial in the forum?-- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
Re: [Flightgear-devel] The future of FlightGear's support programs
Am 04.09.11 08:05, schrieb Durk Talsma: > Hi All, > > In the past, we've seen a large number of projects that were initiated for > FlightGear; Atlas, fgrun, the terragear toolchain, and taxidraw. Many of > these program have undergone substantial development, many contributors have > come and gone, and in a number of cases, the project management has changed > hands from one person to another. > > While this is really great, I also cannot escape the impression that some of > these programs either don't really live up to their full potential, or at the > verge of constant abandonment, due to limited developer access. Note that > for the latter, I have one specific case in mind, which is taxidraw. > TaxiDraw's most active developer, Ralf Gerlich recently resigned, and I've > been wondering how to proceed. The official taxidraw repository is hosted at > sourceforge and cvs based. Looking at the TaxiDraw project page, I could only > identify David Luff as the project admin. I've been trying to get in touch > with Dave to discuss taxidraw's future, but unsuccessfully thus far. > > I think that taxidraw is an essential piece of software and I think that > FlightGear could benefit tremendously, if it were only more easily > accessible. For this reason, I think that it would be a good idea if we > started bundling it's latest version along with the official release and > incorporate it into the automatic snapshot builds. Additionally, we need to > ensure future developers access. I hope that David Luff will respond, so that > we can work out a plan for improve future consistency of it's development > cycle. If not, I might consider moving the taxidraw source over to gitorious > and incorporate it as a subproject of fg. > > Any thoughts / ideas would be welcome. > > Cheers, > Durk > Hi Durk Personally I don’t know if there is a roadmap for taxidraw anymore. You can edit airport data with tools like Qgis directly and with much more comfort. It’s sad, but I think we dont need it anymore. Cheers, Yves -- Special Offer -- Download ArcSight Logger for FREE! Finally, a world-class log management solution at an even better price-free! And you'll get a free "Love Thy Logs" t-shirt when you download Logger. Secure your free ArcSight Logger TODAY! http://p.sf.net/sfu/arcsisghtdev2dev ___ Flightgear-devel mailing list Flightgear-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/flightgear-devel
