Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Lukáš Tinkl wrote: Hello Flightgear crew, we at SUSE recently stumbled upon this problem: some of the code contained in FlightGear contains a non-commercial lincese which forbids us from further distributing it. The consequence is that FlightGear wouldn't be part of the upcoming SUSE Linux release. The affected files are: src/Time/moonpos.cxx src/Time/moonpos.hxx src/Time/sunpos.hxx Hmm, the .hxx files don't contain any code that couldn't be GPL or BSD. These files were newly created for FlightGear. The .cxx files are a different matter, although moonpos.cxx was derived from sunpos.cxx so there is basically one file that needs to be rewritten. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Curt forwarded from Lukas Tinkl: > we at SUSE recently stumbled upon this problem: some of the > code contained in FlightGear contains a non-commercial lincese > which forbids us from further distributing it. The consequence > is that FlightGear wouldn't be part of the upcoming SUSE Linux > release. SuSE is (or was, or would be) shipping FlightGear? I had no idea. We should probably fix this, I guess. Maybe the easiest way to do it would be to contact the author; is XEarth or descendents still an active project? Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Andy Ross wrote: We should probably fix this, I guess. Maybe the easiest way to do it would be to contact the author; is XEarth or descendents still an active project? Actually, I've tracked this down to just one function to calculate sun_angle_deg. We do already calculate that in SimGear/simgear/ephemeris/celestialBody.cxx so in theory it would be easy to change src/Time/sunsolver.cxx accordingly and get rid of all those files. It's just that I haven't figured it out completely yet. I was hoping Durk could take a look at it. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Andy Ross schrieb: > Curt forwarded from Lukas Tinkl: > >>we at SUSE recently stumbled upon this problem: some of the >>code contained in FlightGear contains a non-commercial lincese >>which forbids us from further distributing it. The consequence >>is that FlightGear wouldn't be part of the upcoming SUSE Linux >>release. > > > SuSE is (or was, or would be) shipping FlightGear? I had no > idea. SuSE was shipping it for ages. They were even advertising with FlightGear (under the Games section though - but it has changed: http://www.novell.com/products/linuxprofessional/games.html). Current links are: http://www.novell.com/products/linuxpackages/professional/flightgear.html http://www.novell.com/coolsolutions/feature/11290.html CU, Christian -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.0 (MingW32) iD8DBQFC4QTXlhWtxOxWNFcRApuQAJ9j0kSEisw0KSsPjg2aTqlPdvnx0QCeJhla 30QjPd7K58FCIUtwMBYzIJs= =4Joa -END PGP SIGNATURE- ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Fri, 2005-07-22 at 15:15, Andy Ross wrote: > We should probably fix this, I guess. Maybe the easiest way to do it > would be to contact the author; is XEarth or descendents still an > active project? > I've just been looking for xearth, and just about all the links I can find are dead. However, xearth spawned Xglobe and Xplanet, both of which claim to be GPL, and Xplanet is most certainly a live project. Xearth also spawned my own hack "xmars", but since Xplanet does everything in the solar system, I now consider xmars defunct. Xplanet claims that it pinched its moon position code from xearth, and Xglobe claims that it pinched its sun position code from xearth too. If xearth isn't GPL, that might compromise Xplanet and or Xglobe's claims to be GPL. However, Xplanet would seem like a good place to go looking for GPL sun-position code. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Steve Hosgood wrote: Xearth also spawned my own hack "xmars", but since Xplanet does everything in the solar system, I now consider xmars defunct. Since you are already familiar with this stuff, I need the function to calculate the sun position (in degrees or radians) above the horizon at a certain time/lat/lon. What is this normally called: RightAscension, Declination, Magnitude or something else? Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Erik Hofman wrote: > Since you are already familiar with this stuff, I need the function to > calculate the sun position (in degrees or radians) above the horizon > at a certain time/lat/lon. What is this normally called: > RightAscension, Declination, Magnitude or something else? None of the above. :) Right ascention and declination are the longitude and latitude of the celestial coordinate system. They specify directions to things that are outside our solar system. Things inside it will appear to move depending on their relative position with the earth. Magnitude refers to the brightness of a star. The sun position can be computed if you know the orbital parameters for the earth, but the details are tricky. The way it would work is to define some "sol-centric" coordinate system in which the earth moves, compute a line from the earthbound eyepoint to the sun, figure out what orientation the earth will be in at that moment, and then do an euler angle decomposition relative to the WGS-84 "up" vector and the earth's axis. Basically, it's not easy, which is why it's probably quickest to ask the author to change the license. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
RE: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
You should find everything you need to replace the objectional code here http://www.stjarnhimlen.se/comp/sunriset.c /* +++Date last modified: 05-Jul-1997 */ /* SUNRISET.C - computes Sun rise/set times, start/end of twilight, and the length of the day at any date and latitude Written as DAYLEN.C, 1989-08-16 Modified to SUNRISET.C, 1992-12-01 (c) Paul Schlyter, 1989, 1992 Released to the public domain by Paul Schlyter, December 1992 */ Norman > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Erik Hofman > Sent: Friday, July 22, 2005 12:09 PM > To: FlightGear developers discussions > Subject: Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux] > > > Steve Hosgood wrote: > > > Xearth also spawned my own hack "xmars", but since Xplanet does > > everything in the solar system, I now consider xmars defunct. > > Since you are already familiar with this stuff, I need the function to > calculate the sun position (in degrees or radians) above the horizon at > a certain time/lat/lon. What is this normally called: RightAscension, > Declination, Magnitude or something else? > > Erik > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Andy Ross wrote: Erik Hofman wrote: Since you are already familiar with this stuff, I need the function to calculate the sun position (in degrees or radians) above the horizon at a certain time/lat/lon. What is this normally called: RightAscension, Declination, Magnitude or something else? None of the above. :) Not even "something else"? :-) > Right ascention and declination are the longitude and latitude of the celestial coordinate system. They specify directions to things that are outside our solar system. Things inside it will appear to move depending on their relative position with the earth. Magnitude refers to the brightness of a star. The sun position can be computed if you know the orbital parameters for the earth, but the details are tricky. The way it would work is to define some "sol-centric" coordinate system in which the earth moves, compute a line from the earthbound eyepoint to the sun, figure out what orientation the earth will be in at that moment, and then do an euler angle decomposition relative to the WGS-84 "up" vector and the earth's axis. Basically, it's not easy, which is why it's probably quickest to ask the author to change the license. :) Well, I got the feeling everything needed is already present without those four files, it's just a matter of tying everything together in the right way. Someone with more knowledge about this stuff might do it in a relatively short time. It would also clean up the code a bit. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Friday 22 July 2005 16:22, Erik Hofman wrote: > Andy Ross wrote: > > We should probably fix this, I guess. Maybe the easiest way to do it > > would be to contact the author; is XEarth or descendents still an > > active project? > > Actually, I've tracked this down to just one function to calculate > sun_angle_deg. We do already calculate that in > SimGear/simgear/ephemeris/celestialBody.cxx so in theory it would be > easy to change src/Time/sunsolver.cxx accordingly and get rid of all > those files. > > It's just that I haven't figured it out completely yet. I was hoping > Durk could take a look at it. > > Erik > Maybe this is a good opportunity to go back to this and fix this more properly. I remember never having been entirely satisfied with the exsisting situation. It's been ages though since I last looked at the astronomy code. I'm in favor of fixing this. It would be a shame to let flightgear slip from the SuSe distribution, just because of small set of files that might be mostly redundant. By what time frame would the people at Suse require this to be fixed? Things are pretty hectic at work right now, so my time is really limited. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Norman Vine wrote: > You should find everything you need to replace the objectional > code here > > http://www.stjarnhimlen.se/comp/sunriset.c > > /* +++Date last modified: 05-Jul-1997 */ > > /* > > SUNRISET.C - computes Sun rise/set times, start/end of twilight, and > the length of the day at any date and latitude > > Written as DAYLEN.C, 1989-08-16 > > Modified to SUNRISET.C, 1992-12-01 > > (c) Paul Schlyter, 1989, 1992 > > Released to the public domain by Paul Schlyter, December 1992 > > */ > > Norman > > >>-Original Message- >>From: [EMAIL PROTECTED] >>[mailto:[EMAIL PROTECTED] Behalf Of Erik Hofman >>Sent: Friday, July 22, 2005 12:09 PM >>To: FlightGear developers discussions >>Subject: Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux] >> >> >>Steve Hosgood wrote: >> >> >>>Xearth also spawned my own hack "xmars", but since Xplanet does >>>everything in the solar system, I now consider xmars defunct. >> >>Since you are already familiar with this stuff, I need the function to >>calculate the sun position (in degrees or radians) above the horizon at >>a certain time/lat/lon. What is this normally called: RightAscension, >>Declination, Magnitude or something else? >> >>Erik >> >>___ >>Flightgear-devel mailing list >>Flightgear-devel@flightgear.org >>http://mail.flightgear.org/mailman/listinfo/flightgear-devel >>2f585eeea02e2c79d7b1d8c4963bae2d >> > > > ___ > Flightgear-devel mailing list > Flightgear-devel@flightgear.org > http://mail.flightgear.org/mailman/listinfo/flightgear-devel > 2f585eeea02e2c79d7b1d8c4963bae2d > Don't forget that the dude wanted to be cc'd on all this, apparently he didn't join the list. Josh ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Durk Talsma wrote: Things are pretty hectic at work right now, so my time is really limited. Here is what I have right now. I must be missing something obvious since the lighting isn't updated based on the sun angle: http://www.a1.nl/~ehofman/fgfs/download/sun_angle.diff Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Friday 22 July 2005 19:09, Erik Hofman wrote: > Durk Talsma wrote: > > Things are pretty hectic at work right now, so my time is really limited. > > Here is what I have right now. I must be missing something obvious since > the lighting isn't updated based on the sun angle: > > http://www.a1.nl/~ehofman/fgfs/download/sun_angle.diff > Okay, I'll see if I can find some time over the weekend. Cheers, Durk ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Fri, 2005-07-22 at 17:56, Erik Hofman wrote: > Andy Ross wrote: > > Erik Hofman wrote: > > > >>Since you are already familiar with this stuff, I need the function to > >>calculate the sun position (in degrees or radians) above the horizon > >>at a certain time/lat/lon. What is this normally called: > >>RightAscension, Declination, Magnitude or something else? > > > > None of the above. :) > > Not even "something else"? > :-) > Erik: The position of any astronomical object relative to a viewer standing on the planet's surface is usually given as "altitude" and "azimuth" - with the true horizon and true "North" used as the references. Normally, an object is said to "set" when it crosses the visible horizon. Simple rise/set programs assume that the visible horizon and true horizon are the same. It gets a bit more tricky in a flight sim because the visible horizon will be significantly below the "true" mathematical one, and thus the sun might well be visible even though it is below the true horizon. For orbit simulators, it gets even more extreme. Additional entertainment will be provided by the fact that and code for FG needs to work with a WGS84 spheroid, meaning that the distance to the earth's centre will vary with lat and long, but for *sun* rise and set, that's probably not significant. There's a great program called "ephem" which will yield all the routines you could ever want, though the pointers to "sunriset.c" that someone else posted here will likely do it too. Not sure of the licence for 'ephem' though. Somewhere I've got source for my own home-written version of a sun rise/set program that I wrote a very long time ago (1979 I believe). I'll see if I can find what I did with it. It started life in Fortran, but was converted to C ages ago, and will probably do the job just fine. I'd be quite happy to GPL any such source if it isn't already. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Steve Hosgood wrote: Erik: The position of any astronomical object relative to a viewer standing on the planet's surface is usually given as "altitude" and "azimuth" - with the true horizon and true "North" used as the references. Normally, an object is said to "set" when it crosses the visible horizon. Simple rise/set programs assume that the visible horizon and true horizon are the same. Flightgear being one of them ... It gets a bit more tricky in a flight sim because the visible horizon will be significantly below the "true" mathematical one, and thus the sun might well be visible even though it is below the true horizon. For orbit simulators, it gets even more extreme. Yes, I've wanted to fix that for some time, but never gotten to it. Additional entertainment will be provided by the fact that and code for FG needs to work with a WGS84 spheroid, meaning that the distance to the earth's centre will vary with lat and long, but for *sun* rise and set, that's probably not significant. There's a great program called "ephem" which will yield all the routines you could ever want, though the pointers to "sunriset.c" that someone else posted here will likely do it too. Not sure of the licence for 'ephem' though. Somewhere I've got source for my own home-written version of a sun rise/set program that I wrote a very long time ago (1979 I believe). I'll see if I can find what I did with it. It started life in Fortran, but was converted to C ages ago, and will probably do the job just fine. I'd be quite happy to GPL any such source if it isn't already. I thought we could do it with the current code, but there is a chicken and egg problem; To change the time, it is first calculated and then set. The time setting code (or rather ephemeris update code) relies on the time setting code. I was hoping to get the data from the ephemeris code but it can get me the right data only after it has been set based on the same settings ... Or in other words; we still do need some sort of offline code to calculate the sun_angle based on arbitrary time and position settings to update the lighting and planets and start positions. Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Mon, 2005-07-25 at 10:35, Erik Hofman wrote: > Steve Hosgood wrote: > > > Erik: > > The position of any astronomical object relative to a viewer standing on > > the planet's surface is usually given as "altitude" and "azimuth" - with > > the true horizon and true "North" used as the references. Normally, an > > object is said to "set" when it crosses the visible horizon. Simple > > rise/set programs assume that the visible horizon and true horizon are > > the same. > > Flightgear being one of them ... > > > It gets a bit more tricky in a flight sim because the visible horizon > > will be significantly below the "true" mathematical one, and thus the > > sun might well be visible even though it is below the true horizon. For > > orbit simulators, it gets even more extreme. > > Yes, I've wanted to fix that for some time, but never gotten to it. I've been thinking a bit more on this, and reckon that probably the horizon business is misleading. You only have to worry about it when you're trying to calculate a sunrise or sunset time. In flightgear, you just want to know the sun's true position at a given time, which is a single one-off calculation. You're only wanting to know the answer so as to set the lighting model. For any value of sun's altitude, you have to do object-intersection work to see if the sun itself is actually visible. One of the "objects" in that list is the planet itself (or, in simpler terms a flat obstruction representing the true horizon-line). Maybe you get the graphics card to do the intersection calculation anyway? Presumably flightgear's sky lighting models do need to know how far the sun is below the true horizon in order to change the sky colour from pale blue through all the shades of purple to black. > > Additional entertainment will be provided by the fact that and code for > > FG needs to work with a WGS84 spheroid, meaning that the distance to the > > earth's centre will vary with lat and long, but for *sun* rise and set, > > that's probably not significant. > > > > There's a great program called "ephem" which will yield all the routines > > you could ever want, though the pointers to "sunriset.c" that someone > > else posted here will likely do it too. Not sure of the licence for > > 'ephem' though. > > > > Somewhere I've got source for my own home-written version of a sun > > rise/set program that I wrote a very long time ago (1979 I believe). > > I'll see if I can find what I did with it. It started life in Fortran, > > but was converted to C ages ago, and will probably do the job just fine. > > I'd be quite happy to GPL any such source if it isn't already. > > I thought we could do it with the current code, but there is a chicken > and egg problem; To change the time, it is first calculated and then > set. The time setting code (or rather ephemeris update code) relies on > the time setting code. I was hoping to get the data from the ephemeris > code but it can get me the right data only after it has been set based > on the same settings ... > I'm a bit lost here! When calculation sunrise or sunset, you do have to do several iterations. First you find the sun's position in the sky for (say) 18:00 hrs locally. Then you guess a sunset time based on how far the sun is away from the true horizon. Then you recalculate the sun's position in the sky (its right ascension and declination) for that guessed sunset time, and convert to altitude and azimuth. Then you probably have to do at least one more loop, because you'll find that in the time between 18:00 and the first guess at sunset-time, the sun's position in the sky moved enough to change the results. Or more to the point, that the earth moved around the sun enough to change the results, but you know what I mean). However, none of this should be necessary for flightgear. You're not calculating the set time, you just want to put the sun in the sky correctly and illuminate the scenery accordingly. That should be a one-shot calculation. My code is on my home machine - I'll check tonight. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Steve Hosgood wrote: > The position of any astronomical object relative to a viewer standing on > the planet's surface is usually given as "altitude" and "azimuth" - with > the true horizon and true "North" used as the references. > [...] > Additional entertainment will be provided by the fact that and code for > FG needs to work with a WGS84 spheroid, meaning that the distance to the > earth's centre will vary with lat and long I humbly submit that this is yet another area where an Euler (angle) representation is a bug, not a feature. We have a sane cartesian coordinate system for the earth. All that's needed is to define one for the solar system* and then do reasonably trivial conversion. The moon should be even easier, presuming that the moon's orbit passes through the equatorial plane (it does, doesn't it?). * It can be 2D, in fact -- on the plane of the Earth's orbit and with one of the axes aligned with the orbit's major axis. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Mon, 2005-07-25 at 15:17, Andy Ross wrote: > I humbly submit that this is yet another area where an Euler (angle) > representation is a bug, not a feature. We have a sane cartesian > coordinate system for the earth. All that's needed is to define one > for the solar system* and then do reasonably trivial conversion. To be frank, that's close to what's happening anyway. The earth orbits the sun in an ellipse and it is considered to be a 2D system. Trouble is that the earth's orbital velocity isn't constant (as Johann Kepler and Tycho Brahe discovered in the 15th century - or was it the 14th?). Solving where the planet is in its orbit for any given calendar time is tricky. Once you've got that, you then do exactly what Andy says and do a "reasonably trivial conversion" to get the sun's position as seen from the POV of an observer on the planet (or over it) at that calendar time. The hard part is finding the calendar time given a phenomenum (like, say 'sunset'). I outlined that one in my previous post. > The > moon should be even easier, presuming that the moon's orbit passes > through the equatorial plane (it does, doesn't it?). > No. None of the planets share the earth's orbital plane either, but the moon is quite well offset. 18 degrees I think, and its orbital plane precesses w.r.t the earth's quite quickly too. The ancients deserve serious respect for managing to predict the moon's movements and eclipses at all. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Steve Hosgood wrote: > Solving where the planet is in its orbit for any given calendar time > is tricky. This is just the equal area thing, right? (angular orbital velocity goes as the inverse of the distance to the focus) I kinda-sorta remember doing a parameterization of that in college way back when. It was based on an energy balace, I think... If nothing else, we can certainly solve it by brute-force integrating it for +/- a few hundred years and storing the table. > The hard part is finding the calendar time given a phenomenum (like, > say 'sunset'). I outlined that one in my previous post. Right, but the point was we don't give a hoot about "sunset". That's a derived quantity specified in euler space (relative to an incorrect horizon, to boot). All we care about is direction. The sunset will take care of itself. (Well, no, because the renderer needs to draw pretty colors when the sun nears the horizon; but that, too, can be done in cartesian space and doesn't require a nothing of "sunrise/set" time). Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
I wrote: > that, too, can be done in cartesian space and doesn't require a > nothing of "sunrise/set" time). Heh, s/nothing/notion/ Most of my typos are clear from context, but that one reads like gibberish, sorry. :) Andy ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Mon, 2005-07-25 at 17:13, Andy Ross wrote: > Steve Hosgood wrote: > > Solving where the planet is in its orbit for any given calendar time > > is tricky. > > This is just the equal area thing, right? Yes. > If nothing else, we can > certainly solve it by brute-force integrating it for +/- a few hundred > years and storing the table. > :-) It's not *that* tricky! Tricky for pre-computer-era people to solve with log tables and slide-rules maybe, but it's just an iterative algorithm where you plug a suggested value of 'x' into a formula and it gives you a better approximation. Repeat until the new approximate 'x' is within an allowable tolerance of the original. Trivial on any modern computer. > > The hard part is finding the calendar time given a phenomenum (like, > > say 'sunset'). I outlined that one in my previous post. > > Right, but the point was we don't give a hoot about "sunset". That's > a derived quantity specified in euler space... Yeah, quite right. I think the discussion just went off a bit sideways there. So we're just down to the problem that the sun position code is possibly not GPL-able. I've dug out my own code that I'm quite happy to donate. Only part of 'src/Time/sunpos.cxx' seems to be derived from Kirk Johnson's 'xearth' anyway, and even he attributes it all to the legendary "Practical Astronomy with your Pocket Calculator" book by Peter Duffett-Smith. I think the interface routines to FlightGear (all starting with 'fg') are not Johnson's anyway, but I'm not totally sure. Durk Talsma may know better - his name is on some of the comments in those 'fg' routines. If it's just a case of changing ecliptic_to_equatorial(), julian_date(), and GST() then I'm up for it. Can someone confirm that doing this will fix the issue, or is there more? Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Steve Hosgood wrote: If it's just a case of changing ecliptic_to_equatorial(), julian_date(), and GST() then I'm up for it. We got routines for thee julian date and GST dated already in SimGear/simgear/timing/sg_time.[ch]xx Can someone confirm that doing this will fix the issue, or is there more? To prevent any problems in the future I would like to see that file removed and the functions added to tmp.[ch]xx But what is really needed is a way to get sun_angle() working in sunsolver.cxx which is done by replacing fgSunPositionGST() with a new version (or by writing a new function that can calculate the sun_angle any time of day at any location) Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Tue, 2005-07-26 at 10:37, Erik Hofman wrote: > To prevent any problems in the future I would like to see that file > removed and the functions added to tmp.[ch]xx > Remove sunpos.[ch]xx completely? OK. > But what is really needed is a way to get sun_angle() working in > sunsolver.cxx which is done by replacing fgSunPositionGST() with a new > version (or by writing a new function that can calculate the sun_angle > any time of day at any location) Funnily enough, I was just having a cup of tea and reading that very file just as your email came in (you're in Europe I presume?). fgSunPositionGST seems to be derived from Johnson's 'xearth' code, but it calculates where on earth the sun is directly overhead. That makes sense for 'xearth' where one of the options is to display the planet from the sun's point of view (so to speak). I can't work out what that routine is doing in FlightGear! It's only used in 'sunsolver.cxx' which was written by Curtis anyway, and is GPL of course. But why is called at all? The rest of Curtis's code does what I'd expect - which is to find the time of day when the sun is at a given angle (so you can specify flying at dusk, or noon or whatever). Give me a bit longer to disentangle it all! I can't work on it right now, (I'm at work) but I can take a quick look at lunchtime, and do more this evening. Steve. ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
Steve Hosgood wrote: Funnily enough, I was just having a cup of tea and reading that very file just as your email came in (you're in Europe I presume?). Yep. fgSunPositionGST seems to be derived from Johnson's 'xearth' code, but it calculates where on earth the sun is directly overhead. That makes sense for 'xearth' where one of the options is to display the planet from the sun's point of view (so to speak). I can't work out what that routine is doing in FlightGear! It's only used in 'sunsolver.cxx' which was written by Curtis anyway, and is GPL of course. But why is called at all? The rest of Curtis's code does what I'd expect - which is to find the time of day when the sun is at a given angle (so you can specify flying at dusk, or noon or whatever). Yes, and that's all it does, give an angle to display the pretty colors properly. Give me a bit longer to disentangle it all! I can't work on it right now, (I'm at work) but I can take a quick look at lunchtime, and do more this evening. I can imagine, I had trouble finding out what's going on also :-\ Erik ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Tuesday 26 July 2005 11:30, Steve Hosgood wrote: > > So we're just down to the problem that the sun position code is possibly > not GPL-able. I've dug out my own code that I'm quite happy to donate. > Only part of 'src/Time/sunpos.cxx' seems to be derived from Kirk > Johnson's 'xearth' anyway, and even he attributes it all to the > legendary "Practical Astronomy with your Pocket Calculator" book by > Peter Duffett-Smith. > > I think the interface routines to FlightGear (all starting with 'fg') > are not Johnson's anyway, but I'm not totally sure. Durk Talsma may know > better - his name is on some of the comments in those 'fg' routines. > Just looking through the sunpos.cxx file, I'm actually wondering how much code is part of the original Kirk Johnson code and how much was changed to adapt the code to our needs. I really think I would have to look at the original file to find out. As far as I remember though, the functions starting with the fg prefix were adaptations from the original Johnson code, but specifically adapted to our needs. Erik, having a look at your patch is next on my list. I'll how much I can find out. Cheers, Durk > If it's just a case of changing ecliptic_to_equatorial(), julian_date(), > and GST() then I'm up for it. > > Can someone confirm that doing this will fix the issue, or is there > more? > ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Tue, 2005-07-26 at 17:34, Erik Hofman wrote: > that's all [fgSunPositionGST] does, give an angle to display the pretty > colors > properly. > Doh! That's a silly way to do it (see below). > > Give me a bit longer to disentangle it all! I can't work on it right > > now, (I'm at work) but I can take a quick look at lunchtime, and do more > > this evening. > > I can imagine, I had trouble finding out what's going on also :-\ > Tell me about it! Here's a basic audit: The julian_date() routine is pretty much word for word the same as Johnson's original, but it's 'static' and only used by the GST() routine. The GST() routine is also word for word identical with Johnson's. It is 'static' and only used by fgSunPosition(). fgSunPosition() isn't used anywhere! So we could ditch all three of these routines immediately with no possible ill effect. FlightGear's 'ecliptic_to_equatorial()' routine is a modified version of Johnson's and it might be said that his copyright in it is no longer relevant. It is, after all just an implementation of the algorithm in Duffett-Smith's book (I've got a copy in front of me). The only novel thing is that my (first edition) copy of the book uses 'atan' and has to sort out the ambiguities caused by that afterwards, but Johnson's and FlightGear's version (sensibly) uses 'atan2()' to avoid the ambiguity in the first place. This is a pretty obvious implementation issue, but who thought of it? Johnson? Or is like that in the third edition of Duffett-Smith?. The 'ecliptic_to_equatorial()' routine gets used by fgSunPosition (not used) and fgSunPositionGST only. Both these routines are rewrites of Johnson's sun_position() routine, and are probably similar enough to be a problem. As stated at the start of the audit, we could lose 'fgSunPosition()' immediately since it isn't actually used anywhere. FlightGear's 'fgUpdateSunPos()' routine seems to have no obvious connection to Johnson's code, though it does call fgSunPositionGST(). I'm not convinced that FlightGear even wants to do this anyway. Surely it should have done a conversion from sun's equatorial coordinates (right ascension and declination) to horizon coordinates (altitude and azimuth) since, as Erik says above, all FlightGear wants to know is the bearing of the sun below the horizon so that it can get the dusk lighting correct! Altitude and azimuth would seem to be the ideal data for that. The only other call to 'fgSunPositionGST()' is in sunsolver.cxx and that's for finding sunrise or sunset time as mentioned before. Again, knowing solar alt/az from the location of the viewer would have been more useful I think. Looks like binning 'sunpos.cxx' will be relatively trivial. Still working on it though. Gotta be careful not to break some cunning interdependency... Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d
Re: [Flightgear-devel] [Fwd: licensing problems in SUSE Linux]
On Wed, 2005-07-27 at 12:29, Steve Hosgood (that's me) wrote: > The julian_date() routine is pretty much word for word the same as > Johnson's original, but it's 'static' and only used by the GST() > routine. > > The GST() routine is also word for word identical with Johnson's. It is > 'static' and only used by fgSunPosition(). > > fgSunPosition() isn't used anywhere! So we could ditch all three of > these routines immediately with no possible ill effect. > Just tried it. Also removed the 'extern' reference to 'fgSunPosition()' in sunpos.hxx and it all compiles just fine as expected. Much the same thing applies to moonpos.cxx too. There's a 'julian_date()', 'GST()' and 'fgMoonPosition()' set of defunct routines in there which can be deleted with no ill effect. Remove the 'extern' reference to 'fgMoonPosition()' from moonpos.hxx too. Still working on the remaining issues. Steve ___ Flightgear-devel mailing list Flightgear-devel@flightgear.org http://mail.flightgear.org/mailman/listinfo/flightgear-devel 2f585eeea02e2c79d7b1d8c4963bae2d