Jump to content

  •  

CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.

Photo

New Mars View Renderer!

charts planet planetarium software
  • Please log in to reply
27 replies to this topic

#1 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 12 October 2020 - 03:21 PM

You are checking out Mars this week, right?

 

Of course you are.

 

I made a new browser-based Mars view renderer to make it easier to identify features you see in an eyepiece or camera: 

 

https://rkinnett.github.io/mars/

 

Use the "Show now" button or "Show specific time" to lookup the view in the past or future.  Enable "mirror" if you're looking through a single mirror (or odd number of mirrors), i.e. through a diagonal.  Also try out different base maps!  Try it on a smartphone.

 

This tool is still very green.  I skipped over a lot of basic error handling, so there will be bugs.  I do not plan to maintain this rigorously (with bug tickets, etc) but I'll try and address individual issues if you leave me a note here.

 

Hope it's useful!

Attached Thumbnails

  • mars_view_renderer.jpg

Edited by rkinnett, 12 October 2020 - 03:54 PM.

  • Dave Mitsky, Mike Phillips, George N and 11 others like this

#2 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 12 October 2020 - 03:50 PM

Base maps!

 

mars_base_maps.jpg

 

These took a lot of work to touch-up and reshape.  I need to work out how to appropriately credit the underlying image sources.


  • Dave Mitsky, BFaucett, sunnyday and 1 other like this

#3 sunnyday

sunnyday

    Voyager 1

  • *****
  • Posts: 11,276
  • Joined: 23 Sep 2019
  • Loc: the Canadian nebula .

Posted 12 October 2020 - 03:56 PM

superb work ,thank you very much .


  • BFaucett and rkinnett like this

#4 descott12

descott12

    Mercury-Atlas

  • *****
  • Posts: 2,765
  • Joined: 28 Sep 2018
  • Loc: Charlotte, NC

Posted 12 October 2020 - 03:56 PM

Fantastic. Thanks alot for doing this. As a fellow software engineer I appreciate the effort. This will be my go-to reference.  A few things:

1) I noticed that the labels don't move when you click animate

2) Is there a way to provide more a less labels? May have different levels of detail like Level 1 is the major areas that you currently have, then Level 2 would be smaller details, etc...

 

Again, thanks. This is really cool


  • rkinnett likes this

#5 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 12 October 2020 - 04:57 PM

Fantastic. Thanks alot for doing this. As a fellow software engineer I appreciate the effort. This will be my go-to reference.  A few things:

1) I noticed that the labels don't move when you click animate

2) Is there a way to provide more a less labels? May have different levels of detail like Level 1 is the major areas that you currently have, then Level 2 would be smaller details, etc...

 

Again, thanks. This is really cool

Thanks Dave.  I noticed that non-rotating labels thing.  That'll be easy to fix today after work. EDIT: done!

 

Good idea regarding the labels.  That's basically what I originally had in mind.. multiple tiers of detail, each individually configurable, and populated dynamically based on names and coordinates in a json file, and the labels remain upright as you adjust the view.  I ended up just making a static labels overlay map in Photoshop as a shortcut, for now, but it's not a good, sustainable approach because it's a hassle to update manually.  I'll experiment more this week with dynamic labels, and if I get a functional prototype working then I'll probably ask around here for help generating lists of feature names and coordinates.  If I stick with the Photoshop static labels map approach, I could still split out levels of detail, as you suggested, and have those each controllable.  It would also be neat to automatically adjust those based on zoom level.. the finer detail labels disappear as you zoom out.

 

Anyways, thanks for your interest!  I'm not a software engineer by trade but I do plenty of amateur coding for various hobbies.  I'm pointing this out because any real software engineer would probably cringe at some of my code.. I neglected a lot of basic error handling for the sake of getting it roughly working, and general code structure is pretty haphazard.  If this project generates enough interest, then I would definitely need some help cleaning it up, making it more robust, and adding features.


Edited by rkinnett, 12 October 2020 - 05:11 PM.

  • BFaucett likes this

#6 BFaucett

BFaucett

    Surveyor 1

  • *****
  • Posts: 1,956
  • Joined: 12 Jul 2014
  • Loc: Houston, Texas

Posted 12 October 2020 - 11:47 PM

Very, very nice! Thank you for sharing this with us. waytogo.gif

 

Cheers! Bob F. smile.gif


  • rkinnett likes this

#7 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 13 October 2020 - 04:08 PM

Some features I plan to investigate soon:

  • NEED A CATCHY NAME!
  • experiment with other 3D view controls.. I don't like the "trackball" control scheme I have now.. OrbitControls or TransformControls are more intuitive.
  • preserve orientation of Mars polar axis relative to the observer viewing axis when updating ephemeris ("show now" or "show specific time")
  • add keyboard controls
  • find a way to control polar axis rotation relative to observer viewing axis via GUI slider (ideally with existing object properties and minimal new math)
  • add url parameter parsing so users can provide a static link to a view at a specific UTC time (i.g.  https://rkinnett.git...12&utcTime=0700) and maybe add a "get link" button in the GUI
  • add "information" button to pop up a modal window with basic instructions and info regarding sources and credits
  • overlay UTC time and other potentially useful info
  • split details into three tiers based on scales of associated surface features, each tier individually configurable in GUI
  • add a local time input
  • checkbox to show/hide stars

Longer term ideas:

  • Find a way to render labels from json file instead of static overlay images
  • Add feature info when you mouse-over things, or make little markers you can click on
  • Add configurable haze and/or blur to roughly represent seeing/optical limitations?
  • Let user load a custom base map and/or labels?
  • ...?

 

I want this to be useful to you while you're standing at your scope or looking at your images or sketches afterward. 

 

What else would make this useful to you?


Edited by rkinnett, 14 October 2020 - 02:54 PM.


#8 descott12

descott12

    Mercury-Atlas

  • *****
  • Posts: 2,765
  • Joined: 28 Sep 2018
  • Loc: Charlotte, NC

Posted 13 October 2020 - 04:19 PM

Hey Ryan,

That all sounds great and it also sounds like alot of work! By the way, what language/platform are you developing it in. I haven't done much browser-based programming. It is not really my cup of tea and it is way too late in life to learn yet another thing but I am completely impressed with what you have done (as well as other amazing web apps).



#9 Gert

Gert

    Messenger

  • *****
  • Posts: 452
  • Joined: 15 Apr 2008

Posted 13 October 2020 - 04:26 PM

Hi,

 

Can you do the same for Jupiter with Red Spot and Moon position and events ?

please include detection of local time zone from browser. It's awful that S&T page has UT and I always get the computation wrong if it crosses the prev/next date. I need this to be automated to pick up my location and time zone from the web.

cheers,

Gert



#10 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 13 October 2020 - 05:03 PM

Hey Ryan,

That all sounds great and it also sounds like alot of work! By the way, what language/platform are you developing it in. I haven't done much browser-based programming. It is not really my cup of tea and it is way too late in life to learn yet another thing but I am completely impressed with what you have done (as well as other amazing web apps).

Thanks Dave :)

 

I'm using javascript with the Three.js library which makes it incredibly easy to build 3D web apps.  That library simplifies the 3D rendering bits to just a few dozen lines of application code.  One of the best things about Three.js is its extensive documentation and examples which make it easy to basically copy and paste a lot of the core pieces for anything you want to make.  I initially based my Mars view renderer on this remarkably simple but effective Earth rendering tutorial.  Swapping out the Earth textures and elevation map for Mars ones worked right out of the box!  From there, I just followed some other examples for building GUI controls, then worked out a method for interpolating ephemerides for the "show now" and "show specific time" features.  I was really pleased at how easily the whole thing came together.  There were a few hiccups but overall the application is quite simple, and I knocked out this first rev in one weekend (although I did have some prior experience with three.js).  The meat of my code is here.

 

Also, here's a fascinating and useful explainer of how National Geographic's "Rewinding the Red Planet" page was developed.  Most of that was over my head.  They had a large team of professional coders on that project.  I might borrow the method they used to render labels.


  • descott12 likes this

#11 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 13 October 2020 - 05:19 PM

Can you do the same for Jupiter with Red Spot and Moon position and events ?

please include detection of local time zone from browser. It's awful that S&T page has UT and I always get the computation wrong if it crosses the prev/next date. I need this to be automated to pick up my location and time zone from the web.

Thanks Gert.  That would be awesome!  But it would be quite a bit more complex than rendering Mars, given the dynamically evolving cloud structures, not to mention handling multiple bodies.  I'll read up on what sort of time scales are relevant for the evolution of cloud structures, and I'll look into how other renderers (WinJUPOS, JPL's Solar System Simulator) handle that, in particular how to predict the position of the GRS at any given point in time.  I can get ephemerides for the moons and rendering those shouldn't be too hard but I would need to convert the planet rotation control to be time-based, whereas right now there is no concept of time other than the moment you click "show now" or when you enter a UTC time. 

 

EDIT:  by the way, three.js will automatically handle shadow casting.. it should look really amazing.  I'm looking forward to prototyping this, although it may take a while to find time for it.

 

Good suggestion regarding making it possible to enter any time in local timezone.  Detecting timezone is trivial, and adding a local time input should be easy too.  I'll add this to my list!


Edited by rkinnett, 13 October 2020 - 06:31 PM.


#12 Gert

Gert

    Messenger

  • *****
  • Posts: 452
  • Joined: 15 Apr 2008

Posted 15 October 2020 - 08:12 PM

Hi Ryan,

 

Yes. Jupiter GRS is handled worst in so many programs as it slowly drifts around in longitude. But there has to be some authority like JPL, RAS that have some website that has the most recent updated value. Then the task is just to pull the current data and convert to observer location and time. I would be happy with anything that draws a beige circle with two brown stripes and a red spot (in the right location). There are so many apps that either get it wrong because they don't update data or leave me with something in UT that is useless when I'm observing.

 

Cheers,

Gert



#13 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 16 October 2020 - 03:54 AM

I tried to go that route with the Mars renderer, querying JPL's HORIZONS ephemeris system, but it turns out that system has a strict cross-origin policy and the only wat to get around that is to write a proxy and have it hosted somewhere, maybe AWS or something like that.  I don't want to do that.  Instead, I just downloaded 5 years worth of ephemerides then converted that to json for fast lookup and interpolation.  I could do the same for the Galilean moons, but to render those I would need to work out some serious orbital math.

 

I see several potential avenues for accessing archived and projected GRS info.  JUPOS and PlutoProject each host observational data, PlutoProject provides projections for the rest of this year, and Sky&Telescope has a handy calculator.  Several of these sites provide equations, but it's still necessary to seed the projections with some recent observation point since GRS' drift rate varies over time.

 

It would be easy to whip up a cartoony Jupiter viewer, showing only the GRS and maybe displaying the start/end times of the next transit, or something like that.  There's not a ton of value in that, given you can get the same info from transit tables, but I guess it would be handy to pop out your phone, pull up the page, and instantly see whether the GRS is transiting right now.  Most of the time the render would just be shaded bands.  I wonder if WinJUPOS uses transit tables for the moons and moon shadows as well or of it does orbital calculations or some sort of planar simplification.  Showing the moons would make this thing worthwhile, but the calculations would be a lot to work out to render relative to Earth.

 

I'll think about it.  In the meantime, I'll knock out some of the Mars viewer to-do list this weekend.



#14 Jeff B1

Jeff B1

    Gemini

  • -----
  • Posts: 3,007
  • Joined: 07 Mar 2014
  • Loc: South Central Florida

Posted 17 October 2020 - 08:00 AM

The GRS is just a storm in some weird clouds and is hard to predict the drift.  I  have trued to keep up with it but some of the 90-day cycles and other variables keep getting in my way.   The last equation I came up with for GRS longitude drift starting 01/01/2020 is:

 

y = -2.536376015 x 10-5 X2 + 0.1202480497 X + 248.1185854, where X = Julian date.



#15 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 19 October 2020 - 12:00 PM

The GRS is just a storm in some weird clouds and is hard to predict the drift.  I  have trued to keep up with it but some of the 90-day cycles and other variables keep getting in my way.   The last equation I came up with for GRS longitude drift starting 01/01/2020 is:

 

y = -2.536376015 x 10-5 X2 + 0.1202480497 X + 248.1185854, where X = Julian date.

Interesting, your curve fit indicates gradual deceleration.  Your approach is a little different from the linear projections described on the Sky&Telescope page and elsewhere.  It might be interesting to compare projections graphically to see how important the acceleration term is.  In any case, as you described, all GRS transit projections require periodic calibration.  Now if I could just get you to sign up for updating your equation monthly for the foreseeable future..  wink.gif

office_space.jpg

 

If I were to go down the path of trying to render GRS, I would look for a robust way to access predictions from the JUPOS project which perpetually updates projections, or maybe the PlutoProject which also supplies projections though I haven't studied how they re-synch as the storm behavior evolves.  Even then I'm just not sure how accurate my interpolations would be.  It sounds like the main interest in having a view rendering tool for Jupiter is for session planning, and I don't want to be the guy that disappoints some poor soul who takes an hour to set up his/her rig in anticipation of a transit, only to find the prediction is off by several hours.  I had exactly that experience a few months ago when I thought I could rely on Stellarium for this.  Digging into it, I found a note in Stellarium documentation suggesting it references JUPOS data, so that dampens my hopes of using a similar approach. 

 

Given that nobody has expressed interest in a Jupiter view renderer for anything other than GRS transit projections, I pretty much would not build such a tool unless I have high confidence with the GRS projections.  Moon transits are also interesting, maybe even more interesting for me, but I would have to overlay a big disclaimer about the lack of accuracy in the rendering of cloud features.  I guess there's one other possibility.. letting the user manually enter a transit start time from whatever external/independent projection source they trust, but then I'm not sure what the value would be of this tool if the user has to go find that info on their own.

 

At this point, I'm going to put the Jupiter renderer idea on the backburner and maybe pick it up on a rainy day this winter.  Meanwhile, ideas and suggestions are welcome here.  Volunteers are also welcome, if anyone has javascript experience - that would bump this back up in my priority stack.



#16 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 19 October 2020 - 01:23 PM

I didn't make time to knock anything off my to-do list this weekend, but I did add two notable maps.

 

The first one is based on Lukas Sujka's (Lukasz83) recent projection which he describes in detail here, along with very helpful instructions for making your own map projections using WinJUPOS.  His map is great on its own and I've thanked him for letting me use it.  It's a useful reference for what a (post-processed) view looks like from a backyard telescope.  What I appreciate most about this map is that we have a clear workflow for users projecting their own maps onto the textured Mars globe.  I plan to add a feature to allow users to load a local image file as a base map.

 

mars_view_sujka_map.jpg

 

The second derives from a stunningly detailed topo map created by Daniel Machacek, with impressively fine-scaled labels of seemingly all named surface features, along with elevation callouts.  This is the map you should use for looking up names of finer features.

 

mars_topo_machacek_map.jpg

 


  • BFaucett likes this

#17 Jeff B1

Jeff B1

    Gemini

  • -----
  • Posts: 3,007
  • Joined: 07 Mar 2014
  • Loc: South Central Florida

Posted 19 October 2020 - 02:22 PM

I have several listings of the GRS longitudes, plus some cycles that stray away from the linear regression, and a data file (Jmess.dat) in WinJUPOS with some break points.  I only use a 2nd order regression since in the past the 3rd and 4th order equations didn’t quite teach me anything.  There is a complex 90-day cycle that seems to excite some researchers, but never interested me, so I use the JUPOS graphic to interpret the data points.  Not a great way and I wish he would publish the raw data.   All I wanted is to use it in my WIMP programs for the Jupiter ephemeris, not a lifetime cloud study.   The graph makes it appear the longitude drifts along with a few bumps in the curve, so for my purposes I just straighten it out.

 

My WIMP Jupiter real-time program plots the GRS fairly close to a degree or so for the UT; that is good enough.   One can find various equations for predicting the central meridians for CM-I, -II and -III that are close to each other, but some programs do not compensate for minor tweaks and differences in a few degrees occur. I use Jean Meeus’s Astronomical Algorithms.  If anyone is so interested in GRS transits they should learn how to compute this stuff.

 

This is what my VB code looks like, without all the VSOP87 stuff:

 

    RAD = 1.74532925199433E-02

 

    DJ = JuDt - 2451545
    VJ = 172.74 + 0.00111588 * DJ
    MJ = 357.529 + 0.9856003 * DJ
    NJ = 20.02 + 0.0830853 * DJ + 0.329 * Sin(RAD * VJ)
    JJ = 66.115 + 0.9025179 * DJ - 0.329 * Sin(RAD * VJ)
    Call NORM(JJ)
    AJ = 1.915 * Sin(RAD * MJ) + 0.02 * Sin(RAD * 2 * MJ)
    BJ = 5.555 * Sin(RAD * NJ) + 0.168 * Sin(RAD * 2 * NJ)
    KJ = JJ + AJ - BJ
    sep = Rearth / DA * Sin(RAD * KJ)
    ep = sep
    Call Arcsin(ep)
    D1 = DJ - DA / 173
    SK = Sgn(Sin(KJ)) * -1
    C0 = SK * 57.2958 * (2 * Rjupiter * DA + Rearth * Rearth - Rjupiter * Rjupiter - DA * DA) / (4 * Rjupiter * DA)
    CMI = 210.98 + 877.8169088 * D1 + ep - BJ + C0
    Call NORM(CMI)
    CMII = 187.23 + 870.1869088 * D1 + ep - BJ + C0
    Call NORM(CMII)
    CMIII = 68.89 + 870.4529147 * D1 + ep - BJ + C0
    Call NORM(CMIII)


Edited by Jeff B1, 19 October 2020 - 02:25 PM.

  • rkinnett likes this

#18 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 19 October 2020 - 07:37 PM

Thanks Jeff for the info.  Do I understand correctly that you generate your own curve fit to the GRS data in Jmess.dat, and that gets you accuracy within a few degrees (longitude)?  That's very promising.  How do you read that file?  What do the section heading and columns mean?  I knew that Jmess.dat file was significant to how WinJUPOS stays up to date, but I wasn't sure how. 

 

Funny story, I was wondering how WinJUPOS stays up to date, so I used Wireshark to watch TCP traffic while I opened up WinJUPOS, and I saw that it sends a get request for Jmess.dat.  The remote site returns a bunch of binary.  I just now found the Jmess.dat file in my WinJUPOS app data directory and I can see it's just an ASCII file in some sort of lookup table format.  I couldn't find that file just searching google or trying various urls at the host address, but it looks like I might be able to get to it programmatically through an http request.

 

Anyways, since you're here and interested, please tell me, would a Jupiter renderer tool be useful to you?  How would you use it?  Are all three CMs useful?  How would you suggest rendering the planet.. using a static texture map or maybe a simplified cartoon just showing the extents of the main bands and GRS, plus moons and shadows?  Any other ideas?

 

 

 

EDIT:  found the Jmess data table decoder in Grischa Hahn's dissertation:

Format:        OBJEKT  REGION  ta       te       t0       l0     S   Drift   [ß"]
Bsp.:   WC     WOS-DE  C3      19980101 19980707 19980301 111.3  2  -0.345  -32.1 

Ahah!  In my Jmess.dat file I see objects "rs" (as in Grs), "wos-fa", "wos-de", and "wos-bc" which JUPOS documentation tells me are long-lived white ovals.. the pearls that trail behind and south of the GRS!  Cool!

 

Translating the subsequent description in GH's thesis:

The values ​​ta, te and t0 are start, end and reference dates in the format YYYYMMDD and refer to 12 UT (Universal Time) of the specified day. l0 is the jovigraphic length position of the object at time t0 in the rotation system S. Drift denotes the daily change in length position in [° / day]. Optionally, the jovigraphic latitude "ß" can be specified in [°]

Hmm.. "start", "end", and "reference" dates?  scratchhead2.gif  Presumably "length position" = longitude, and the rest looks easy enough. 

 

last 2 entries in Jmess.dat:

?c rs     e3 20181126 20191227 20190610 310.8  2  +0.0572 -22.5
?c rs     e3 20191228 20210128 20200714 337.7  2  +0.0713 -22.5

Can I just grab that last entry, from July 14, at 337.7 deg longitude, and propagate that +0.0713 deg per day?  That yields 345 deg.  Indeed, WinJUPOS shows GRS centered at 345 deg in L2 system!

 

Am I doing this right?


Edited by rkinnett, 19 October 2020 - 09:03 PM.


#19 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 19 October 2020 - 09:25 PM

Hey mods, is it possible to split this thread?  I'm imagining I would open a new thread on the topic of a Jupiter renderer tool, then we can move all of the Jupiter- related replies from this thread over to that thread..



#20 Jeff B1

Jeff B1

    Gemini

  • -----
  • Posts: 3,007
  • Joined: 07 Mar 2014
  • Loc: South Central Florida

Posted 20 October 2020 - 09:23 AM

Ryan,  I use the Jmess.dat numbers up to a point, then take data points from WinJUPOS for 2020, and until around 2021/02/01 when the longitude stops increasing past 351.3 degrees.  I assume from then on the curve is just straight up at a steady rate.  Getting lazy so I use Online Polynomial Regression

(http://www.xuru.org/...R.asp#CopyPaste) to get a 2nd order equation.   The more I tried to get fancy with 4th or 5th order equations the worse it gets, so I knew by then something smells in JUPOS, Denmark, so to speak. smile.gif  I just assume Hahn’s math is close to truth and they use some complex differentiations to come up with their drift rates.  Someday I’ll ask Grischa. Years ago I sent him an old FORTRAN program to compute the Moons of Mars and he owes me one. cool.gif

 

Norton’s doesn’t like WinJUPOS updates so they are using some open Internet connect or something in the programs.  Not sure about his data file columns, they appear to make sense to someone, but not me. 

 

I have retired for observing and my forte is Mars, so Jupiter holds no fascination for me. blush.gif  I do enjoy new program schemes to fiddle with, but that too has gotten a bit stale in my old age.  In August I had a cleaning of my right carotid artery, 90% blocked, and have not felt any better or worse, so my memory seems to be failing at the same rate as before and I do not feel any smarter with all the blood to my brain.  The only way to keep my thinking brain cells from going out is to visit the old computer programs and astronomy mathematics. cool.gif  Oh, I turned 80 last Saturday!


Edited by Jeff B1, 20 October 2020 - 09:24 AM.


#21 Jeff B1

Jeff B1

    Gemini

  • -----
  • Posts: 3,007
  • Joined: 07 Mar 2014
  • Loc: South Central Florida

Posted 20 October 2020 - 09:56 AM

After all the years observing planets, Mars in particular and then Jupiter, my memories of the cloud bands, bars, ovals, lagoons ,etc., on Jupiter taught me each second of observing it the first and last time I would see such events and they would never repeat. Don Parker used to call me whenever a disturbance on Jupiter would occur so we could work together and image it all.  After that I only casually looked at Jupiter because nothing would ever repeat and what I saw as endless formations of clouds.  Sort of like our clouds, they are an endless array of globs that never seem to look the alike. lol.gif

 

Don and I studied Mars’ clouds for many years and try as hard as we could, none of them actually returned the same shape, in the exactly the same locations.   Never the less we did regressions and articles on them like we really knew what we were doing.  Even peer reviews were puzzled but passed along their views as though they know what we were doing.  Science is funny at times.  Even dust storms have an infinite variety of shapes, movements and intensities, so at best it is a guessing game to formulate their behavior.



#22 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 20 October 2020 - 05:06 PM

Thanks Jeff.  Fascinating history!  You guys really put in hard work.

 

I worked out a method to reach out to Grischa Hahn's site to get his latest Jmess.dat, and I wrote a parser to pick out the latest GRS measurement, and I'm just linearly interpolating from that reference longitude using the indicated drift rate.  WinJUPOS is definitely using a more complicated interpolation/projection scheme because WinJUPOS projects an L2 value that doesn't match the latest measurement when you ask WinJUPOS to show you the view on the same date as the latest measurement.  I suppose I could take a much deeper look like you did, charting WinJUPOS' 2019 and 2020 projects and seeing how those relate to measurements in Jmess.dat, to figure out what kind of curve fit it uses.  Or one could simply ask Grischa lol.gif .  You pointed out that higher order interpolations don't seem to yield higher accuracy.. I think I'll stop at just 1st order!  My linear projection gets me within about 10 degrees of the WinJUPOS estimates for any time in 2020.

 

I said I was putting the Jupiter visualizer on the backburner, but I just couldn't resist! 

 

I opened a new thread for it:  https://www.cloudyni...rk-in-progress/

 

Let's please resume any discussion of Jupiter projections and rendering in that thread.  Thanks!



#23 Jeff B1

Jeff B1

    Gemini

  • -----
  • Posts: 3,007
  • Joined: 07 Mar 2014
  • Loc: South Central Florida

Posted 20 October 2020 - 05:41 PM

Ryan, here is a text file with my equations that you can piddle with.

 

Attached File  GRS equations.txt   1.21KB   3 downloads

 

Will look at your Jupiter stuff later, busy with getting old lol.gif .


Edited by Jeff B1, 21 October 2020 - 05:27 PM.


#24 Dobserver

Dobserver

    Lift Off

  • *****
  • Posts: 11
  • Joined: 13 Jun 2020
  • Loc: Pasadena, CA, USA

Posted 21 October 2020 - 12:31 AM

Outstanding, sir! Thank you for your hard work.


  • BFaucett and rkinnett like this

#25 rkinnett

rkinnett

    Viking 1

  • *****
  • topic starter
  • Posts: 589
  • Joined: 08 Aug 2018
  • Loc: La Crescenta, CA

Posted 21 October 2020 - 02:57 PM

Outstanding, sir! Thank you for your hard work.

Thanks neighbor :)




CNers have asked about a donation box for Cloudy Nights over the years, so here you go. Donation is not required by any means, so please enjoy your stay.


Recent Topics





Also tagged with one or more of these keywords: charts, planet, planetarium software



Cloudy Nights LLC
Cloudy Nights Sponsor: Astronomics