[Dxspider-support] sh/muf has wrong location name

[Dirk Koopman]

On Mon, 2006-02-13 at 11:10 -0800, Jim Reisert AD1C wrote:
> How do I delete old satellites that are no longer maintained in the various sets of keps?
> 
> For example, on my node AO-37, SO-43, UO-14 and WO-39 were updated neither through the NASA keps nor the ones on celestrak.
>  

It is a bit of a palaver. And it should be easier. In fact, currently,
it relies on me and is rather unsatisfactory.

The problem is basically this: Keps are an extremely unreliable source
of data. There is no canonical source. Individuals value different sets
of data because they are interested in their own particular area of the
sky (or whatever).

The consequence of this is that I decided to make the satellite data
persistent. I did this, at the time, because my advice was (ex-G3IOR)
that having too many satellites was better than too few and if some of
them had older data (because the keps were not available every week)
then that was better than nothing. 

So my solution to this (up to now at least) is that I empty
the /spider/perl/Keps.pm hash out, store the file, run convkeps.pl on
the current AMSAT keps, copy the resultant Keps.pm in /spider/local into
the /spider/perl tree and put that back into CVS as the "base" set that
is then updated (and added to) by subsequent updates. 


*** NB:
*** 
*** I am the only person that can do this and not break CVS updating
*** 
*** (that means: you leave it alone!!!). 
***

This is now done and in CVS. What this means is that to get a clean set
of keps is that you must either remove the /spider/local/Keps.pm and
then do a 'load/keps' else, if you have updates that you think give
better numbers or have other keps you want, then do a 'convkeps.pl -c
keps.txt' (or whatever the file is called) and then a 'load/keps'. 

If you don't do one or the other, any keps that are in the local Keps.pm
will override any that are in the issue version (even if they are older)
and also any old satellites that are in the local copy will remain until
you do a 'convkeps.pl -c ...'  

When I design something to hang around come what may, I do not mess
about :-)

If anybody has any suggestions of a better way that still allows me to
distribute a base (default) set of keps, I would be happy to read them.

I suspect that me simply doing this more often, instead of doing it once
every 18 months when someone complains (or simply reminds me) would go a
long way to solving the problem.

Dirk