seti / rms-webtools Goto Github PK

• In Pds4File/pdsfile.py, convert from_path function to work with instantiation on files under Pds4FileTest/pds4/bundles

Currently the documents directory does not have associated pickle files, which means any access by PdsFile needs to go to the filesystem instead of the pickle files. It would be more consistent to have pickle files for the documents directory as well. This involves updating the scripts in validation and also making any needed modifications to PdsFile.

• In Pds4File/pdsfile.py, convert from_filespec function to work with instantiation on files under Pds4FileTest/pds4/bundles

This has brought down OPUS twice now.

Something like this:

(p3venv) rfrench@tools:/volumes/pdsdata-server2/holdings/archives-previews$ ls -l
total 82681568
drwxr-xr-x  74 4294967294 4294967294       2516 Apr 21  2018 COCIRS_0xxx
drwxr-xr-x  74 4294967294 4294967294       2516 May 25  2017 COCIRS_0xxx_v3
drwxr-xr-x  95 4294967294 4294967294       3230 Aug 16  2018 COCIRS_1xxx
drwxr-xr-x  92 4294967294 4294967294       3128 Jan 24 15:48 COCIRS_1xxx_v3
drwxr-xr-x  11 4294967294 4294967294        374 Apr 24  2017 COISS_1xxx
-rw-r--r--   1 4294967294 4294967294  975573499 May 23 23:14 COISS_2001_previews.tar.gz
-rw-r--r--   1 4294967294 4294967294  908442043 May 23 23:25 COISS_2002_previews.tar.gz

causes errors like this:

[Thu Jun 06 06:41:46.700694 2019] [wsgi:error] [pid 29599:tid 139796204164864] [remote 79.94.238.19:51273]   File "/home/django/src/pds-opus/opus/application/settings.py", line 301, in <module>
[Thu Jun 06 06:41:46.700696 2019] [wsgi:error] [pid 29599:tid 139796204164864] [remote 79.94.238.19:51273]     pdsfile.preload(PDS_DATA_DIR)
[Thu Jun 06 06:41:46.700701 2019] [wsgi:error] [pid 29599:tid 139796204164864] [remote 79.94.238.19:51273]   File "/home/django/src/pds-webtools/pdsfile.py", line 488, in preload
[Thu Jun 06 06:41:46.700705 2019] [wsgi:error] [pid 29599:tid 139796204164864] [remote 79.94.238.19:51273]     _preload_dir(pdsdir)
[Thu Jun 06 06:41:46.700711 2019] [wsgi:error] [pid 29599:tid 139796204164864] [remote 79.94.238.19:51273]   File "/home/django/src/pds-webtools/pdsfile.py", line 374, in _preload_dir
[Thu Jun 06 06:41:46.700714 2019] [wsgi:error] [pid 29599:tid 139796204164864] [remote 79.94.238.19:51273]     for basename in pdsdir.childnames:
[Thu Jun 06 06:41:46.700719 2019] [wsgi:error] [pid 29599:tid 139796204164864] [remote 79.94.238.19:51273]   File "/home/django/src/pds-webtools/pdsfile.py", line 1164, in childnames
[Thu Jun 06 06:41:46.700721 2019] [wsgi:error] [pid 29599:tid 139796204164864] [remote 79.94.238.19:51273]     self._childnames_filled = self.sort_basenames(childnames)
[Thu Jun 06 06:41:46.700726 2019] [wsgi:error] [pid 29599:tid 139796204164864] [remote 79.94.238.19:51273]   File "/home/django/src/pds-webtools/pdsfile.py", line 3798, in sort_basenames
[Thu Jun 06 06:41:46.700729 2019] [wsgi:error] [pid 29599:tid 139796204164864] [remote 79.94.238.19:51273]     basenames.sort(key=modified_sort_key)
[Thu Jun 06 06:41:46.700745 2019] [wsgi:error] [pid 29599:tid 139796204164864] [remote 79.94.238.19:51273] TypeError: '<' not supported between instances of 'bool' and 'str'

• Currently regex pattern for VOLSET_REGEX is hard coded for our test directory, generalize the pattern when we know more about the bundle set name later.

• rules/COCIRS_xxx.py never executes the loop at 1108 or the if at 1116.
• rules/COUVIS_0xxx.py doesn't exercise various branches in DATA_SET_ID()
• rules/COVIMS_0xxx.py doesn't exercise various branches in OPUS_ID_TO_PRIMARY_LOGICAL_PATH()
• filename_keylen is never tested
• tests/test_pdsfile_blackbox.py The clause at line 1271 is never executed
• tests/test_pdsfile_blackbox.py The loop at line 3042 never starts
• tests/test_pdsfile_whitebox.py The loop at 877 never starts

From pds-webserver created by rfrenchseti: SETI/pds-webserver#24

Moved from pds-opus because this is now working in OPUS.

For example, go here:

https://pds-rings.seti.org/viewmaster/volumes/GO_0xxx_v1/GO_0017/J0/OPNAV

And then go down into any of the subdirectories:

https://pds-rings.seti.org/holdings/volumes/GO_0xxx_v1/GO_0017/J0/OPNAV/C034640/

and you will get a Viewmaster internal error.

From pds-opus created by rfrenchseti: SETI/rms-opus#483

There are different versions of NH observations with suffixes like "_0x630" and "_0x631". These suffixes are ignored when making the OPUS ID, but the different versions are available for downloading. However, each version also has its own preview image, which means ViewSet has multiple previews for a given OPUS ID and size.

How do we choose which one to display? What do we do if we want the user to choose which one to look at?

• Use Pds4FileTest/pds4/bundles as an example, the pds3 volset level should be the uranus_occs_earthbased in our pds4 bundles directory.

Shelf files were a later addition to the PdsFile class. Re-factoring the code to use them for this purpose would not be a bad idea. Somebody would have to implement a glob.glob replacement that uses shelf files. Feel free!

Note that, if the match pattern crosses volume boundaries, it could actually be slower than a direct call to glob.glob. That's because each volume has its own shelf files.

On Dec 4, 2018, at 1:39 PM, Rob French [email protected] wrote:

It seems like PdsFile maintains these enormous "shelve" files (or pickle
files) that contain all sorts of useful information about every file in
pdsdata. But then when you call opus_products(), it uses glob() on the
real file system instead of looking into these files. Likewise when you
create a ViewSet for preview images, it has "must_exist=True", which
checks the actual filesystem. Same for the "exists" property.

Shouldn't we be using the shelve files for all of these cases?

.

• Need to update opus_id rule in each rules file under pds-webtools/rules

At least for now, the nascent Pds4File code should live in its own directory. Establish this directory, which should contain a copy of all PdsFile code.

The --mode option is only used for tests inside the tests directory. Tests in rules do not appear to use the mode setting and instead always have use_shelves(False).

Occultation profiles are associated with a large number of raw data products. There needs to be a way to associate the profile with the products (and vice versa!) so that when the user goes to download the profile, they can also download the raw data. This will probably be stored in some kind of index file in the metadata directory for each affected volume.

From Joshua Elliott [email protected]

Hello Mark,

Thanks for getting back to me. Sure, so for example if I want to use the following DAT file (and it's LBL file):
https://pds-rings.seti.org/holdings/volumes/COUVIS_0xxx/COUVIS_0019/DATA/D2007_138/FUV2007_138_00_09.DAT
https://pds-rings.seti.org/holdings/volumes/COUVIS_0xxx/COUVIS_0019/DATA/D2007_138/FUV2007_138_00_09.LBL
OPUS gives me both the DAT and LBL file, which is great.

But then there is a calibration file and its associated LBL file located here:
https://pds-rings.seti.org/holdings/volumes/COUVIS_0xxx/COUVIS_0019/CALIB/VERSION_3/D2007_138/FUV2007_138_00_09_CAL_3.DAT
https://pds-rings.seti.org/holdings/volumes/COUVIS_0xxx/COUVIS_0019/CALIB/VERSION_3/D2007_138/FUV2007_138_00_09_CAL_3.LBL

This matrix gets multiplied against each readout in the dataset. Each UVIS dataset should have a corresponding CAL file (I think).

What I'm doing now, is using OPUS to find the observations I want, and then I go download the calibration files manually. But it would be great to have this included automatically.

Thanks for taking a look at this feature request. OPUS is a great tool, and I think this would be a good enhancement.

Thanks,
Josh

• Clean up to make sure naming are consistent in the repo, we use snake case (replace white space with "_") in the naming for python code in the repo, so we can do something like Pds4_File instead of camel case Pds4File to make it consistent.

• Need to update opus_products rule in each rules file under pds-webtools/rules

From pds-opus created by rfrenchseti: SETI/rms-opus#1290

OPUS import now throws out thousands of lines that say:

2023-01-09 13:26:18 | pds.opus_import.main |--| WARNING | Retrieving viewable shape: /volumes/pdsdata-raid45/holdings/documents/NHxxLO_xxxx/LORRI-responsivity-plot.png
2023-01-09 13:26:18 | pds.opus_import.main |--| WARNING | Retrieving viewable shape: /volumes/pdsdata-raid45/holdings/documents/NHxxLO_xxxx/NH-Boresight-FOVs.png

during import, because of recent changes to PdsFile. These warnings should be captured and not included in the import log file.

Here are two example observations from HSTN0_7319:

"HSTJ0_7319","DATA/VISIT_01/N41S01010.LBL","N41S01010","N41S01010", 7319,"Goguen, Jay ","HST-J-NICMOS-5-ID7319-V1.0 ","NICMO
S","NIC2 ","IMAGE ","HST_PREVIEW_DOCUMENT","BINARY","1997-06-12","2017-12-20T15:33:13","1997-06-12T19:43:02","1997-06-12T19:47:18",
256.0,"JUPITER","IO ","IO-N2BO ","POL0L ",1.9950,0.2100,0.2100,2.1000,1.8900,"NIC2FIX
","NORMAL ","FINE ","N/A ","MULTIACCUM",116 ,85
"HSTJ0_7319","DATA/VISIT_01/N41S01011.LBL","N41S01011","N41S01011", 7319,"Goguen, Jay ","HST-J-NICMOS-5-ID7319-V1.0 ","NICMO
S","NIC2 ","IMAGE ","HST_PREVIEW_DOCUMENT","BINARY","1997-06-12","2017-12-20T15:33:13","1997-06-12T19:48:28","1997-06-12T19:52:44",
256.0,"JUPITER","IO ","IO-N2BO ","POL0L ",1.9950,0.2100,0.2100,2.1000,1.8900,"NIC2-FIX
","NORMAL ","FINE ","N/A ","MULTIACCUM",256 ,256

Note the names are N41S01010 and N41S01011. We now give them the same OPUS ID. However, they have different start times: 1997-06-12T19:43:02 vs. 1997-06-12T19:48:28. This implies to me they are separate observations, not "different versions" of the same observation.

Should we be dropping that last character of the NICMOS filename as we currently are, or keep it and make these observations separate?

• Current from_path expected results based on comments:

  • 'COISS_2001.targz' --> 'archives-volumes/COISS_2xxx/COISS_2001.tar.gz'
  • 'COISS_2001_previews.targz' --> 'archives-previews/COISS_2xxx/COISS_2001_previews.tar.gz'
  • 'COISS_0xxx_tar.gz' --> 'archives-volumes/COISS_2xxx'

• Actual return results from function:

  • 'COISS_2001.targz' --> previews/COISS_2xxx/COISS_2001
  • 'COISS_2001_previews.targz' --> volumes/COISS_2xxx/COISS_2001
  • 'COISS_0xxx_tar.gz' --> 'volumes/COISS_0xxx'

The VERSIONS part of rules/CORSS_8xxx.py has the following code:

    (r'volumes/CORSS_8xxx(|_v[0-9\.]+)/(CORSS_8...)/(\w+)(|/.*)', 0,
            [r'volumes/CORSS_8xxx*/\2/#LOWER#\3\4',
             r'volumes/CORSS_8xxx*/\2/#LOWER#\3#MIXED#\4',
             r'volumes/CORSS_8xxx_v1/\2/#UPPER#\3\4',
             r'volumes/CORSS_8xxx_v1/\2/#UPPER#\3#MIXED#\4',
            ]),

The last two lines duplicate the results from the first two, except they also capitalize the REV prefix. When enumerating version files, this results in things like:

'/volumes/pdsdata-admin/holdings/volumes/CORSS_8xxx_v1/CORSS_8001/EASYDATA/REV07E_RSS_2005_123_X43_E/RSS_2005_123_X43_E_CAL.TAB'
'/volumes/pdsdata-admin/holdings/volumes/CORSS_8xxx_v1/CORSS_8001/EASYDATA/Rev07E_RSS_2005_123_X43_E/RSS_2005_123_X43_E_CAL.TAB'

There is code to de-dup lists like this using the Python set() constructor, but this de-dup is case-sensitive and thus both examples of the file end up being present (see, e.g. PdsFile.all_versions()). Usually this is caught in a later phase of PdsFile, but it causes a warning to be logged (which we don't usually see because we don't have PdsFile logging turned on).

The reason I found this is it changes the code coverage for the PdsFile tests when they are run against Linux-vs-Mac filesystems.

There is no other case where we have this problem, leading me to believe the VERSIONS for CORSS are incorrect in this instance.

PdsFile and its associated systems (e.g. build/validate shelf files, parse and store index files) need to be updated to PDS4. This is a placeholder issue. Over time, as the scope is better understood, it can be expanded into issues for each stage.

Right now OPUS always gives a link to the ViewMaster labels for surface and ring geo, even if the observation doesn't actually exist in those index files. PdsFile needs to give information on whether the observation is there so we don't include a link that ends up returning no data.

See pds-opus issue #323

2019-06-10 11:30:15 | pds.opus_import.main |--| WARNING | [HSTU0_8634 index row 24] Empty opus_product key for files: /Volumes/pdsdata-server2/holdings/volumes/HSTUx_xxxx/HSTU0_8634/DATA/VISIT_07/U62M0702R.png

This is the only HST preview image that's a PNG file instead of a JPG.

At some point during preload (about an hour into the process), Viewmaster stops serving webpages even though the preload is continuing to run.

• In Pds4File/pdsfile.py, convert from_abspath function to work with instantiation on files under Pds4FileTest/pds4/bundles

On Nov 7, 2018, at 1:53 PM, Rob French[email protected] wrote:

OK...so fundamentally there is a mismatch here. If I read the "primary
file spec" from an index file, assuming it is in the proper format
(ending in .LBL), then I have no way of using PdsFile.from_filespec() to
look it up and get a viable ViewSet from it, since ViewSets explicitly
don't work with the .LBL extension.

So either we need to change PdsFile to look up Viewables when the
extension is .LBL, or we need to change the extension of the primary
file spec before sending it to PdsFile for lookup. Or is there already
some automated way to ask PdsFile for the "primary data product" which
DOES have a ViewSet?

There's also the problem that Cassini ISS and Galileo SSI do NOT use
.LBL as the extension in the index files. That means that, in OPUS, some
observations have a primary file spec ending in .LBL and some end in
.IMG. Do we want to make these consistent by having the import pipeline
switch the extension to all be .LBL? Or do we want to keep the OPUS
database consistent with what's actually in the PDS archives?

On 11/7/2018 12:28 PM, Mark Showalter wrote:

OK, I remember now why I did this and it has to do with making sensible Viewmaster pages.

We can solve this problem by having a PdsFile attribute "primary_data_abspath" that returns the absolute path to the primary data file. Then...

pdsf = pdsfile.PdsFile.from_path(filespec)
viewset = pdsfile.PdsFile.from_abspath(pdsf.primary_data_abspath).viewset

...would do the trick. The problem is that the association between a random file and the primary data file is currently not easy to make unless you turn on "set_opus_lookups()", which is slow. I can fix that.

This will be the quantity that should be used as primary filespec, no matter what appears in the label. Also, PdsFile.from_abspath(primary_filespec).viewset will return a valid viewset.

On Nov 7, 2018, at 9:45 PM, Rob French [email protected] wrote:

OK, hopefully last question - do you really want abspath stored in the
OPUS database? That exposes our internal filesystem structure. Wouldn't
the logical_path, or better yet the logical_path with "volumes" stripped
off, be more appropriate?

yes, logical path after "volumes/".

• In Pds4File/pdsfile.py, convert viewset to return the PdsViewSet used for the pdsfile instance.

_get_shelf in pdsfile.py is sorting the pickle files as they are read because they are coming in out of order. But Python 3 stores dictionaries in insertion order, so we need to investigate why the pickle files are out of order. It could just be that some of the files are old and were written with Python 2, in which case we can update the pickle files and remove the sort.

pdslogger.py is a wonderful module for increasing the usefulness of the base Python logging module. However, it various ways it is PDS-specific (not the least of which is its name). It would be nice it we could generalize the module a little so it would be more useful to the general public.

Another improvement we could make is allowing PdsLogger.open to be a context manager, so you can do with PdsLogger.open(...) to change indent levels.

Michael Aye requests that OPUS product_types (e.g. coiss-raw) use underscores instead of dashes (coiss_raw) so that they are easier to use as Python class members.

• Use Pds4FileTest/pds4/bundles as an example, the pds3 volume level should be the uranus_occ_u0_kao_91cm in our pds4 bundle uranus_occs_earthbased directory.

• In Pds4File/pdsfile.py, convert childnames property to list all the child names of a pdsfile instance.

The commit on 9/22/2022: "Update opus types products for documentation" broke viewmaster, but we didn't know because we never tried updating the servers. The problem is that when you browse to the volumes COCIRS_5xxx, COCIRS_6xxx, COUVIS_0xxx, COUVIS_8001, COVIMS_0xxx, or COVIMS_8001, you get only a list of files/directories and not the full Viewmaster treatment of the directory.

There is no relevant entry in the viewmaster debug log or the Apache error log.

• Modify the code the make sure these two properties (frequently used) exists and logical_path work.

From pds-opus created by rfrenchseti : SETI/rms-opus#564

mysql> select volume_id, opus_id, ert1, ert2 from obs_mission_cassini where ert1 > ert2;
+------------+--------------------+---------------+---------------+
| volume_id  | opus_id            | ert1          | ert2          |
+------------+--------------------+---------------+---------------+
| COISS_1001 | co-iss-n1349081927 |  23957818.153 |  23957006.639 |
| COISS_1001 | co-iss-n1349087639 |  23958093.216 |  23957268.716 |
| COISS_1001 | co-iss-n1349087709 |  23958149.519 |  23957337.486 |
| COISS_1001 | co-iss-n1349369175 |  24119298.375 |  24118479.149 |
| COISS_1001 | co-iss-n1349375027 |  24119605.215 |  24118785.653 |
| COISS_1001 | co-iss-n1349518442 |  24388803.394 |  24387978.906 |
| COISS_1001 | co-iss-n1349518626 |  24388938.077 |  24388126.111 |
| COISS_1001 | co-iss-n1349805794 |  24550378.995 |  24549558.758 |
| COISS_1001 | co-iss-n1349805908 |  24550457.652 |  24549638.799 |
| COISS_1001 | co-iss-w1349949286 |  24819620.349 |  24818811.102 |
| COISS_1001 | co-iss-n1350230678 |  24980803.252 |  24979984.757 |
| COISS_1001 | co-iss-n1350236633 |  24981181.735 |  24980362.302 |
| COISS_1001 | co-iss-n1350380089 |  25250402.168 |  25249576.829 |
| COISS_1001 | co-iss-n1351092421 |  25842473.925 |  25841655.725 |
| COISS_1001 | co-iss-n1351235654 |  26111543.337 |  26110718.667 |
| COISS_1001 | co-iss-n1351235695 |  26111569.701 |  26110745.332 |
| COISS_1001 | co-iss-n1351235760 |  26111615.937 |  26110805.667 |
| COISS_1001 | co-iss-n1351235805 |   26111656.88 |  26110848.006 |
| COISS_1002 | co-iss-n1352103365 |  26973743.071 |  26972877.895 |
| COISS_1002 | co-iss-w1352534103 |  27404540.266 |  27403732.059 |
| COISS_1002 | co-iss-w1352821385 |  27565905.805 |  27565088.735 |
| COISS_1002 | co-iss-w1352821450 |  27565967.928 |  27565150.793 |
| COISS_1002 | co-iss-n1352959142 |  27691835.991 |  27691020.614 |
| COISS_1002 | co-iss-w1352959250 |  27691949.284 |  27691133.049 |
| COISS_1002 | co-iss-w1352959604 |  27692140.761 |  27691325.654 |
| COISS_1002 | co-iss-n1353103023 |  27835932.817 |  27835089.134 |
| COISS_1002 | co-iss-n1353246939 |  27997432.803 |  27996612.476 |
| COISS_1002 | co-iss-w1353389896 |  28122619.158 |  28121808.323 |
| COISS_1002 | co-iss-n1353390109 |  28122811.371 |  28121979.005 |
| COISS_1002 | co-iss-w1353534699 |  28267166.167 |  28266301.865 |
| COISS_1003 | co-iss-w1354108491 |  28859039.841 |  28858218.133 |
| COISS_1003 | co-iss-n1354108602 |  28859097.564 |  28858263.538 |
| COISS_1003 | co-iss-n1354251550 |  28984275.917 |  28983462.481 |
| COISS_1003 | co-iss-w1354251658 |   28984393.59 |  28983577.447 |
| COISS_1003 | co-iss-n1354396007 |  29128726.534 |  29127883.944 |
| COISS_1003 | co-iss-w1354539405 |  29289944.366 |  29289122.259 |
| COISS_1003 | co-iss-n1354539714 |  29290009.316 |  29289188.938 |
| COISS_1003 | co-iss-n1354539825 |  29290058.459 |  29289225.574 |
| COISS_1003 | co-iss-n1354540018 |  29290075.479 |  29289255.267 |
| COISS_1003 | co-iss-w1354825928 |  29559115.881 |  29558270.098 |
| COISS_1004 | co-iss-n1356864735 |  31567469.092 |  31566648.944 |
| COISS_1004 | co-iss-n1356864777 |   31567506.48 |  31566702.471 |
| COISS_1004 | co-iss-n1356975912 |  31679022.099 |  31678229.579 |
| COISS_1004 | co-iss-w1357431545 |   32109327.67 |  32108502.242 |
| COISS_1004 | co-iss-n1357431653 |  32109393.818 |  32108575.733 |
| COISS_1004 | co-iss-w1357431786 |  32109505.133 |  32108678.177 |
| COISS_1005 | co-iss-n1357863387 |  32564818.116 |  32564001.064 |
| COISS_1005 | co-iss-w1357971535 |  32661833.307 |  32661048.098 |
| COISS_1005 | co-iss-n1358245168 |  33002132.033 |  33001347.082 |
| COISS_1005 | co-iss-w1358663405 |  33363658.981 |  33362851.696 |
| COISS_1005 | co-iss-n1358663623 |  33363788.801 |  33362981.883 |
| COISS_1005 | co-iss-n1358927780 |  33662603.336 |  33661821.067 |
| COISS_1005 | co-iss-n1358927964 |  33662771.458 |  33661974.278 |
| COISS_1005 | co-iss-n1359070782 |  33806348.667 |  33805549.494 |
| COISS_1005 | co-iss-n1359071373 |  33806525.275 |   33805733.94 |
| COISS_1006 | co-iss-w1359502060 |  34237307.461 |   34236508.77 |
| COISS_1006 | co-iss-w1360363027 |  35098798.924 |  35097997.179 |
| COISS_1006 | co-iss-n1360937901 |  35673953.939 |  35673153.317 |
| COISS_1006 | co-iss-n1361226923 |  35959092.187 |  35958289.342 |
| COISS_1006 | co-iss-n1361228653 |  35959334.752 |  35958532.527 |
| COISS_1006 | co-iss-n1361368738 |  36104841.363 |  36104042.417 |
| COISS_1006 | co-iss-n1361655926 |  36389658.751 |  36388856.819 |
| COISS_1006 | co-iss-n1361657689 |  36389937.778 |  36389135.955 |
| COISS_1007 | co-iss-n1364541189 |  39209911.435 |  39209105.791 |
| COISS_1007 | co-iss-n1364541321 |  39210006.646 |  39209200.988 |
| COISS_1007 | co-iss-n1364541420 |  39210071.276 |  39209259.072 |
| COISS_1007 | co-iss-n1364541584 |  39210164.402 |  39209359.088 |
| COISS_1007 | co-iss-n1364541716 |   39210261.13 |  39209455.666 |
| COISS_1007 | co-iss-n1364541749 |  39210285.335 |  39209479.712 |
| COISS_1007 | co-iss-n1364541979 |  39210419.813 |  39209614.705 |
| COISS_1007 | co-iss-n1404856096 |  79539950.668 |  79539318.142 |
| COISS_1008 | co-iss-n1412619196 |  87379169.361 |   87378397.73 |
| COISS_1008 | co-iss-n1412906634 |  87721828.069 |  87721071.006 |
| COISS_1008 | co-iss-n1412908730 |  87722239.197 |  87721495.891 |
| COISS_1008 | co-iss-n1412909266 |  87722377.528 |  87721628.333 |
| COISS_1008 | co-iss-n1412909802 |  87722510.979 |   87721760.81 |
| COISS_1008 | co-iss-n1413902027 |  88583979.532 |  88583249.968 |
| COISS_1008 | co-iss-n1413902105 |  88584085.201 |  88583373.068 |
| COISS_1008 | co-iss-n1421686131 |  96442078.492 |  96441309.157 |
| COISS_1008 | co-iss-n1421838870 |  96548946.531 |  96548179.089 |
| COISS_1008 | co-iss-w1429505174 | 104435821.548 | 104287270.587 |
+------------+--------------------+---------------+---------------+

• In Pds4File/pdsfile.py, convert associated_abspaths function to list all the associated absolute paths of a pdsfile instance.