Hey,
If you want to proceed, lets take this offline.
dxwayne at . We can post summary
results later. To quiesce this particular thread...
I've just noticed some sort of disconnect between the
XEphem built-in Ast...edb files and the 'daily' type
of MPC orbit files. But!!! I am moving fast over this problem.
I downloaded the MPCORB.DAT.gz file and found
the asteroid you seek. However it would need to
be converted to .edb file. The XEphem user doc
describes the fields. The MPCORB.DAT file
is? a 'FORTRAN' like fixed column deal.
I deal with these types of files from Vizier all
the time, using python/editor as my choice approach
for the moment. There is a completely new
technique embedded in astropy for example, that allows
grabbing tabular data and converting to
ds9 tsv files pretty easy.
I downloaded the MPCORB.DAT file. It is big (as in I don't want to hand edit it!) and appears well formed.
The MPC states "At present MPCORB is not
available via anon-ftp on this site."
Not sure what the ramifications for XEphem might be.
I don't know the direct link between the XEphem
download files and this master file. I took Ceres as an example, and could not match the fields up between XEphem doc, edb, and Ceres' line from MPCORB. This is about as far as I can go with this, short of writing
a python script to convert the MPCORB to edb- several
hours at best. I don't have that time in my schedule. I
need to dig into the XEphem source code to understand
the real process. Someone might make a hack that takes the
file you get via the HTTP download and make the
files you need.
So, alas, this first cup of coffee exercise hit the bottom
of the cup before the bottom of the problem. Do I
get partial credit?
This page lets you enter asteroids, and will return
a .edb line for just your target(s) of interest. That
is how I got my little ast.edb file hacked together for
testing, and was able to spot the H issue. H is
in MPCORB.dat.
How well are your python skills?? I suggest to all to use
the Anaconda python package from Continuum.io site.
It is free, and well presented for general analytics
use on all platforms. I've used it under Mac and Linux,
astropy is there and completely integrated. There is
a trick to managing the PYTHONPATH etc to make
it sing. The 'Young Turks' of astronomy are migrating
to iPython (Anaconda is supporting this well)? from IDL.
For astronomy try to stick to the 2.7.6+, as the bulk
of existing stuff is there. Python 3.3.x is OK, but 2.7
seems to be the one for astronomy for now, seems to be
the base for os scripts too.
--W
On Wed, Dec 10, 2014 at 5:50 PM, Santiago Roland santiago@... [xephem] <xephem@...> wrote:
?
So, is this page of any use?
Cheers,
Santiago Roland.-
---------------------------------
Jabber: santiago@...
Diaspora*:
Identi.ca:
openPGP ID: 7BE512C5
openPGP key:
---------------------------------
El 10/12/14 a las 22:04, Wayne Green dxwayne@... [xephem] escribi¨®:
>
>
>
>
> is one place; I checked for your asteroids they are there, maybe
> with a different primary name?
>
> --W
>
>
> On Tue, Dec 9, 2014 at 9:17 AM, Wayne Green <dxwayne@...
> dxwayne@...>> wrote:
>
> Hey,
>
> using xephem 3.7.7-RC3
>
> I checked JPL and the MPC for the object 2010 JT123, for which
> they show an updated name of 2014 FD7.
>
> I don't find either name in the .edb files from Lowell or
> the MPC bright, or dim, even after update.
>
> MPC directly reports the mag as 23.2ish for now.
>
> JPL sez the object has a heliocentric distance ~1.52e8km (1AU).
>
> Can you send me the filename and line from your .edb file?
>
> grep '2014.*FD7' *edb
> and
> grep '2010.*JT123' *edb
>
> I don't get any output for either query. check your install
> base (mine is /usr/local/xephem/catalogs) and from
> your ~/.xephem dir.
>
> During this chase, I deleted files from /usr/share/xephem/catalogs...
> Reran the app.
> Found MPC files in my ~/.xephem directory!
> deleted those
> reloaded
>
>
> So, I asked the MPC for the single line for XEphem, and saved this
> into a file in ~/.xephem/ast.edb and I can find, load, query, and
> Sky Point the 2014*FD7 critter.
>
> The mag reports fine.
>
> # From MPO315289 (HACKED HERE, OK in ast.edb attached)
> 2014 FD7,e,15.4565,187.2564,138.8035
> ,1.203030,0.7469466,0.048986,50.8130,12/09.0/2014,2000,H21.5,0.15
>
>
> Attached is the hacked output from a JPL vector query
> with object data from JPL and the hacked table
> from the MPC direct query.
>
> I realize you are not looking for these data exactly, but
> trying to solve the XEphem .edb issue, but here is
> the 'truth' from my two main sources for a baseline
> for debugging.
>
> I don't have a lot of time to dig into the code, but hope this
> helps. Good first cup of coffee exercise for me this AM!
>
>
>
>
>
> --Wayne
>
>
>
> On Tue, Dec 9, 2014 at 5:37 AM, Santiago Roland santiago@...
> santiago@...> [xephem] <xephem@...
> xephem@...>> wrote:
>
> __
>
>
> Yeah, i keep having the same problem. I downloaded the Lowell dim
> catalog and magnitudes are fine, The issue is with the MPC files. I
> downloaded them in the orbital elements page for planetarium
> programs,
> fetched the link and entered in the download links in XEphem,
> deleted
> all catalogs and reloaded them several times. I get for unusual,
> magnitudes around 3 or 4. Any other ideas? Logs that i can post? I
> deleted the .edb and generated them again. See object 2010
> JT123, what
> magnitude do you have for this object? I compiled the lastest
> version
> and i'm running it on Debian, XEphem 3.7.6
>
> Best Regards,
>
> Santiago Roland.-
> ---------------------------------
> Jabber: santiago@... santiago@...>
> Diaspora*:
> Identi.ca:
> openPGP ID: 7BE512C5
> openPGP key:
> ---------------------------------
>
> El 21/11/14 a las 15:04, ecdowney@...
> ecdowney@...> [xephem] escribi¨®:
> >
> >
> > You do realize that Downloading just stores them on disk,
> right? You
> > must still Load them using Data -> Files.
> >
> >
> >
> >
>
>
>
>
> --
>
>
> -- Wayne
>
>
>
>
> --
>
>
> -- Wayne
>
>
|
