Learn how easy it is to sync an existing GitHub or Google Code repo to a SourceForge project! See Demo

Close

getSelectedObjectInfo() Bug? - Azimuth figures reported incorrectly

Feedback
Anonymous
2013-12-29
2014-01-06

  • Anonymous
    2013-12-29

    Hi all!

    I think I've come across a bug with getSelectedObjectInfo(), specifically the figure it reports for a selected objects azimuth.

    For the record I'm using 0.12.4 64bit on Win 7 Home Premium 64 bit. Also tried with the 32bit version of Stellarium but no difference.

    There's a couple of examples below, but if you run the script in the console with an object selected, you'll see similar strangeness

    This is the script:


    TargetData = core.getSelectedObjectInfo();
    TargetName = TargetData["localized-name"];
    TargetGeoAzi = TargetData["azimuth-geometric"];
    TargetGeoAlt = TargetData["altitude-geometric"];
    core.debug(TargetName + "\t" + TargetGeoAzi + "\t" + TargetGeoAlt);
    

    Observer Location: London
    Date: 2013-12-11 04:30 UTC

    Target: Arcturus
    Azimuth: +95° 54' 54"
    Altitude: +29° 18' 57"

    These are the figures shown in the information panel, top left of screen - all good

    And when I run the script, the numbers that come out are haywire.

    Script Azimuth: 84.08502474297381 (84° 05' 06.09")
    Script Altitude: 29.31577612575129 (29° 18' 56.793")

    The altitude is correct, but the azimuth is not.

    It only makes sense with the formula:

    180° - Actual Azimuth = Reported Azimuth

    e.g.
    180° - 95° 54' 54" = 84° 05' 06.09"

    This is only true of objects with an actual azimuth of between 0° and 180°. Things get stranger if you go past 180°....

    ====================================

    Observer Location: London
    Date: 2013-12-11 04:30 UTC

    Target: Pollux
    Azimuth: +236° 26' 14"
    Altitude: +57° 00' 46"

    Script Azimuth: -56.43734108748945 (-56° 26' 14.4276")
    Script Altitude: 57.01283417030654 (57° 00' 46.2018")

    Again altitude is correct, but the situation with the azimuth is worse. Now the formula appears to be

    Actual Azimuth - 180° = (-)Reported Azimuth

    e.g.
    236° 26' 14" - 180° = -56° 26' 14.4276"

    You see what happened? It took the actual azimuth, subtracted 180° to get a result, and then made the result negative!

    I also noticed this behaviour with getObjectInfo

    Any input greatly appreciated!
    Many thanks
    Richard

     

  • Anonymous
    2013-12-29

    No problem Alex, happy to help catch it

    I see the changes you've made to the StelMainScriptAPI.cpp. Is there any way I can implement them into 0.12.4, or is it a case of waiting for release of the next version?

     
    • Alexander Wolf
      Alexander Wolf
      2013-12-29

      You can add this patch to source code for Stellarium 0.12.4 and rebuild it from source code. Or you can add workaround for current wrong values in script.

       

  • Anonymous
    2013-12-29

    Honestly I don't think I can work out how to build from source, I read the instructions but they don't make a whole lot of sense to me, not really my area... :)

    No problem, I guess for the time being I can enter the azimuth values I need to know manually. I did try to work out an Excel formula that could compensate but again, getting beyond my knowledge

    Anyway, the bug's been taken care of at your end now so fix will be in next public release (I assume), I'll eagerly look forward to that!

    Thanks again Alex
    Richard

     

  • Anonymous
    2014-01-02

    Hi Alex

    Just a quick follow up on this...

    So I got brave and did actually work out how to compile 0.12.4 from source and have successfully produced a libStelMain.dll for 0.12.4 32-bit Windows that includes the fix for the azi/alt figures. Works great, script / core.getSelectedObjectInfo() is now reporting correct numbers and my project is well under way. Would be happy to send this file to you if it's of any use to you or anyone else.

    Don't know if this might be important to you, but in the updated StelMainScriptAPI.cpp, there is reference to a variable 'az' (lines 735-848) - I could only get it to compile successfully if that variable was 'azi', as it was before the fix.

    Thanks, Richard

     


Anonymous


Cancel   Add attachments