Isis3: Kaguya spiceinit not using correct InstrumentPosition kernel path

[korimac]

ISIS version(s) affected: 4.2.0

Description
Running spiceinit with local kernels on a Kaguya TC_s_Level2B0 or TC_w_Level2B0 file fails with:

**ERROR** Unable to initialize camera model.

In the full output, the InstrumentPosition is not pointing to the correct location for the spk kernel:

Group = Kernels
  NaifCkCode                = -131350
  NaifFrameCode             = -131351
  LeapSecond                = $base/kernels/lsk/naif0012.tls
  TargetAttitudeShape       = ($base/kernels/pck/pck00009.tpc,
                               $kaguya/kernels/pck/moon_080317.tf,
                               $kaguya/kernels/pck/moon_assoc_me.tf)
  TargetPosition            = ($kaguya/kernels/tspk/moon_pa_de421_1900-2050.b-
                               pc, $kaguya/kernels/tspk/de421.bsp)
  InstrumentPointing        = ($kaguya/kernels/ck/SEL_M_ALL_D_V02.BC,
                               $kaguya/kernels/fk/SEL_V01.TF)
  Instrument                = $kaguya/kernels/ik/SEL_TC_V01.TI
  SpacecraftClock           = $kaguya/kernels/sclk/SEL_M_V01.TSC
  InstrumentPosition        = /usgs/cpkgs/isis3/data/kaguya/kernels/spk//SEL_-
                              M_071020_090610_SGMH_02.BSP
  InstrumentAddendum        = $kaguya/kernels/iak/kaguyaTcAddendum007.ti
  ShapeModel                = $base/dems/ldem_128ppd_Mar2011_clon180_radius_p-
                              ad.cub
  InstrumentPositionQuality = Reconstructed
  InstrumentPointingQuality = Reconstructed
  CameraVersion             = 2
  Error                     = "Spice file does not exist
                               [/usgs/cpkgs/isis3/data/kaguya/kernels/spk//SEL-
                               _M_071020_090610_SGMH_02.BSP]"
End_Group

Where that specific kernel is located in $kaguya/kernels/spk/ similar to the others, and I do not have a usgs folder at all.

I had seen pull request #3713, and associated issue, and therefore created a second conda environment to run ISIS 4.2.0 instead of 3.9.1, which I had been holding on to for ASP compatibility (although I am just now seeing that I can upgrade both packages), and I appreciate that this could be causing issues on my end if this winds up not being reproducible.

However within the testing data in ISIS3/isis/tests/data/LineScannerImage (here), both .pvl files show the same usgs path + double slash in the InstrumentPosition slot of the spiceinit output.

How to reproduce
I am able to reproduce the issue with the Kaguya datafile at ISIS3/isis/tests/data/kaguyatc2isis (here) by running:

kaguyatc2isis from=TC1S2B0_01_05186N225E0040_mini.lbl to=TC1S2B0_01_05186N225E0040_mini.cub
spiceinit from=TC1S2B0_01_05186N225E0040_mini.cub

[jessemapel]

This looks like a bug in the kerneldb file, it has the local path here at the USGS instead of a relative path.

@korimac For right now, can you paste the following into a new file at $ISISDATA/kaguya/kernels/spk/kernels.0005.db

Object = SpacecraftPosition
  RunTime = 2019-06-11T08:29:29

  Group = Dependencies
    LeapsecondKernel = $base/kernels/lsk/naif0012.tls
  End_Group

  Group = Selection
    Time = ("2007 OCT 20 02:31:05.182393 TDB",
            "2007 DEC 11 02:31:05.183325 TDB")
    Time = ("2007 DEC 11 16:16:05.183340 TDB",
            "2008 FEB 04 20:31:05.184873 TDB")
    Time = ("2008 FEB 05 04:16:05.184881 TDB",
            "2008 MAR 29 16:31:05.185651 TDB")
    Time = ("2008 MAR 30 00:16:05.185652 TDB",
            "2008 MAY 24 15:01:05.185062 TDB")
    Time = ("2008 MAY 24 20:44:05.185057 TDB",
            "2008 JUL 16 07:31:05.183677 TDB")
    Time = ("2008 JUL 16 15:31:05.183667 TDB",
            "2008 SEP 10 05:31:05.182490 TDB")
    Time = ("2008 SEP 10 13:31:05.182486 TDB",
            "2008 NOV 03 00:31:05.182546 TDB")
    Time = ("2008 NOV 03 09:01:05.182551 TDB",
            "2008 DEC 26 21:01:05.183784 TDB")
    Time = ("2008 DEC 27 05:31:05.183794 TDB",
            "2009 JAN 01 04:01:05.183936 TDB")
    Time = ("2009 JAN 01 04:01:06.183936 TDB",
            "2009 FEB 20 20:01:06.185240 TDB")
    Time = ("2009 FEB 20 23:46:06.185243 TDB",
            "2009 MAR 19 18:01:06.185602 TDB")
    Time = ("2009 MAR 19 22:01:06.185603 TDB",
            "2009 APR 16 19:01:06.185615 TDB")
    Time = ("2009 APR 16 21:31:06.185614 TDB",
            "2009 JUN 10 19:31:06.184658 TDB")
    File = $kaguya/kernels/spk/SEL_M_071020_090610_SGMH_02.BSP
    Type = Reconstructed
  End_Group

  Group = Selection
    Time = ("2008 OCT 30 02:31:05.182496 TDB",
            "2008 NOV 03 00:31:05.182546 TDB")
    Time = ("2008 NOV 03 09:01:05.182551 TDB",
            "2008 DEC 26 21:01:05.183784 TDB")
    Time = ("2008 DEC 27 05:31:05.183794 TDB",
            "2009 JAN 01 04:01:05.183936 TDB")
    Time = ("2009 JAN 01 04:01:06.183936 TDB",
            "2009 FEB 20 20:01:06.185240 TDB")
    Time = ("2009 FEB 20 23:46:06.185243 TDB",
            "2009 MAR 19 18:01:06.185602 TDB")
    Time = ("2009 MAR 19 22:01:06.185603 TDB",
            "2009 APR 16 19:01:06.185615 TDB")
    Time = ("2009 APR 16 21:31:06.185614 TDB",
            "2009 JUN 08 12:31:06.184717 TDB")
    Time = ("2009 JUN 08 12:37:36.184717 TDB",
            "2009 JUN 10 19:31:06.184658 TDB")
    File = $kaguya/kernels/spk//SELMAINGRGM900CL660DIRALT2008103020090610.bsp
    Type = Smithed
  End_Group
End_Object
End

[jessemapel]

I realized I can also just push the updated kerneldb to our rsync server! You can download that file by running `rsync -azv --delete --partial isisdist.astrogeology.usgs.gov::isisdata/data/kaguya/kernels/spk/ $ISISDATA/kaguya/kernels/spk/

[korimac]

Awesome - I was able to pull down the updated kernel from the rsync server, and now spiceinit is working! Thank you very much!!

[jessemapel]

This looks like an issue that's been around for a while based on the existing kerneldbs so I'm glad you caught it!