Question regarding the Cassini spice workshop:



Why do we need these .xyzv files?
As I believe, the .xyzv files were once obtained from the spice files.
Using the mentioned spice- and orientation files should be enough though ?

Your Cassini 2013 example works very fine

One remark:
Both Cassini ssc's in your workshop contain a duplicate entry for spice file "130807R_SCPSE_13182_13200.bsp".


During implementation I had one issue in combination with the default Cassini in the "extras-standard".
No mesh could be produced, only a white sphere.
Deleting the default Cassini in the "extras-standard" and not "replacing" but defining it in your examples, solved the issue.


Marco

Hi! Any suggestion about why the horizontal grid is displaced from the correct planetary positions?

if you are referring to the 100% FUBAR'ed file that was posted ONLY as a stop gap
and was only posted AS IS and was just a update to a file i have NO idea if it worked

the file was NEVER installed into celestia

it was only a update to the add on i had REMOVED
a file that was updated in 20 min.

with the 2013 only cassini posted after

then that file is no more so there is no issue

It's a different matter. Below is a screenshot of Uranus with VSOP87 orbit viewed from Rome. Its position against the horizontal grid does match with the JPL horizons azimuth for the date.


While below is a screenshot of Uranus with SPICE orbit still viewed from Rome. Its position against the horizontal grid does not match with the JPL horizons azimuth for the date.

A day after i put up the ssc there was a correction posted to it
check the ssc an see if de430 or Ura095 is used for Uranus

if ura095.bsp

grab a new copy from the google page it should be 430
https://docs.google.com/document/d/1U0l ... sp=sharing

However other than dates supported that should not make a difference
both are using ecliptic plane

two screenshots from CElestia 1.6.1 default and SVN 5229+spice
-- they are almost the same , the moons are a bit different in this shot
no sipce , then spice ( the spice orbit has Uranus's name displayed )

John, something still goes strange; all planets are displaced against the horizontal grid. Ecliptic, equatorial and galactic grids are ok. Another thing which is different respect to VSOP87 orbits are the declinations of the Earth and Sun for retrograde planets. Respect to VSOP87, SPICE gets inverted values concerning the emispheres north<->south's swap; SPICE get it already swapped, while VSOP87 needs their inversion.

i take it this is the lua add on

i only enable lua when i test add ons , and ONLY installed on celestia 1.6.1 ( all default settings)
all other times i have it disabled ( chmod 000 lua_edu_tools )

i suppose i can install lua_edu_tools on my svn build
then the Ephemerides add on

and have a look
however celestia is giving me a location of +115 x -59 deg ( for Uranus)
- the same as in Steliarium
I also have been double checking things against
http://space.jpl.nasa.gov/

so locations are correct

now Venus and Uranus ,have always been a bit odd in the orientation of north/south
and some of the minor moons ( that are in retrograde orbits ) are a bit "wonky"

but as far as i can tell even they are in the correct location


--- added ---
A thought
i am using OrbitFrame = EclipticJ2000
is the lua add on using EquatorJ2000

Maybe I've been misunderstood: the SPICE azimuths are correct: it is the horizontal grid which doesn't match the positions. Could you post a screenshot of a planet on (against?) the horizontal grid?

Venus has also the problem of the central meridian (this must be checked with the LT, light travel delay active). Note that the Ephemerides on openSUSE 12.3 works fine, whether they could help in checking. What I believe was an error with the declinations of Sun/Earth because the SPICE settings and that I've corrected, in now an error with the VSOP87.



Azimuths are got through equatorial coordinates, but because these latters are correct, either in value and graphically on grid (the equatorial), the azimuths are correct. The why about when on horizontal grid planets are displaced, does concern more the grid, at this point.

well the horizontal grid in 1.7 QT4 is basically useless you are on a surface

from MY location Detroit Mi. ,just after Uranus rise ( Horz. grid )

and with the galactic

115 , -59

now in ecliptic ( as seen from Earth )
Uranus is 10 deg. and the earth FROM Uranus is 190 deg. ( < shift >+ < * > )



that is a bit of a fun one to check , and i would not be surprised it is is 180 deg off
-- that is one of the things that DOSE need to be double checked



I do think something is " getting lost in translation"

as far as i can tell the Horizontal grid location at the time Uranus rises will be 90 ( West )
that appears correct
along with the galactic +115 x -59

now the retrograde rotation planets and retrograde orbital moons , they have always caused me problems in dealing with how celestia handles them
so if they are off , i would not be at all surprised .

Well, from your location I see so:



The Uranus's position at midnight is correct on calcolus, but the horizontal grid is about 27.5 degrees displaced. All planets are affect of such grid's displacement; and moreover this latter is not constant.

seeing as the HZ grid IS the relative north , south, east , west for the location
and the planet moves over time
it WILL be in a different place at "planet rise" and at 00:00.000 UT
from Detroit at 00:00.000 UT

it will be at about 131 deg roughly NW
at 22:31 UT about 1 hour after planet rise at the same location it is at 112 deg

at 23:00 it is at 116
at 01 on the 23 ( 2 hours later )it is at 153
at 04:00 it is at 215


now there is a 1 hour differince in the old 1.6.1 build ( on linux BUT using Microsoft TIME !!!!!!!!!!! )
and in svn and ALSO using Microsoft TIME ! ( "win7 - copy" is on a partition on a small drive and i HAVE to set the clock on the MB to EST( +4) and NOT to the linux UT time ) and win7 is using daylight savings

so the one hour difference is to be expected on my set up
the definition of
EST = UT+4 OR UT+5
or
UT = EST - 4 or EST - 5

marco klunder has been nice enough to check for my mistakes , -- thanks

once a spacecraft is added ,then it is a bit easy -- compare Cassini's ( or other craft) real images with the sim
NASA's Solar system Sim is good for location but not so well with rotation on small bodies
they use a spherical body for " small " moons

About the only ones i am not sure of are the retrograde orbits of some of the minor moons and HOW celestia interprets that
north and south might be flipped ? I do not know at this time .

Yes, thanks John for getting back to this important aspect. I followed with much interest the feedback coming e.g. from Marco. That's how such things should evolve in time

And then there are Massimo's mysterious "horizontal grid shifts". I'll surely get into ChrisL's revised grid code when I find a little free time from coding celestia.Sci... As far as I can remember, ChrisL one day presented completely new (adaptable) grids that he had recoded from scratch. This is not too long ago. I also seem to remember that no-one besides him ever checked these grids really in a quantitative manner.

Fridger

as i recall 1.6.1 and SVN are using two different ways for time
it was updated as i recall

My installs of the gtk 1.6.1 and the QT 1.7( svn) do have a 1 hour difference
basically the issue of having the coms clock set to EST and not UT
that 1 hour diff should disappear in 2 days ( i do have a funky set up )

so THAT is not Massimo's error

His looks like he is using DIFFERENT times and Uranus WILL be at a different north,south,east,west location as it rises in the east and sets in the west

It's location WILL change from planet rise to planet set as it moves from east to south to west
through the night .