Whitespace is important for position numbering in tray_maps vs. load_holders

[cmmercer]

Description
When setting up things to use the Loading plugin, I had to create a file in data/.dvc/MetaData/load_holders/ for our sample disk. I discovered that I needed to not have any whitespace after the "circle,3.0" line, otherwise position numbering rendered in the disk map in the Loading GUI would start at 2 or 3 rather than 1. However many blank lines were present equaled the observed offset in hole numbering. Interestingly, when I updated my setupfiles/tray_maps/ file to match my load_holder file, I discovered that requesting position 1 actually got me to position 3, requesting position 2 got me to hole 4, etc. Importantly, the positions were not just offset due to a calibration issue; requesting hole 2 actually navigated me down a row and left to hole 4, not just right along the same row as hole 1. In this case (for the tray_map), missing two lines of whitespace after "circle,3.0" was the issue; adding the lines back in fixed the navigation to the requested hole. So somehow the number of blank lines causes an offset in position numbering that is inconsistent when loaded from tray_maps or load_holders.

Note, using the most recent commit from dev/dc: 078f30b

To Reproduce
Steps to reproduce the behavior will depend on your instrument/extraction device. You may need to restart Pychron after editing files as described below.

1. Edit a tray map in setupfiles/tray_maps/ to have more or fewer lines of whitespace after the shape definition
2. Open FusionsCO2 GUI, or relevant plugin for your extraction device
3. Attempt to navigate to a reference hole
4. Repeat steps 1-3 with a different number of blank lines after shape definition and before the hole locations, observe change in numbering when trying to navigate to reference hole
5. Now edit the corresponding load_holder map in data/.dvc/MetaData/load_holders; adjust the number of lines of whitespace after the shape definition
6. Open the Loading GUI, and select a load that uses the edited load_holder
7. Go to View and make sure "show hold numbers" is checked
8. Observe hole numbering
9. Repeat steps 5-8 with different number of blank lines after shape definition and before hole locations, observe change in numbering when reopening Loading GUI and selecting a load using the edited load_holder

Expected behavior
Blank lines after the shape definition should not cause an offset in position numbering

Screenshots
See attached screenshot, where I added four lines of blank space in my load_holder file then opened the Loading window. I'd attach a video of requesting hole 1 and watching the laser navigate to hole 3 if I could, but that's not really necessary.

[jirhiker]

tray_maps and load_holders should be the same file format but they are not mainly because of backwards compatibility issues.

tray_maps are for the laser and load_holders are for the database.

tray_maps should be

<shape>,<radius>


x1,y1
x2,y2

the same format would work for the corresponding load_holder but not vice versa. Tray_maps can be load holders but load_holders cannot be tray_maps (currently)

For tray maps the first 3 rows are reserved for metadata.
for load_holders only the first line is reserved for metadata (but blank lines are skipped, hence why a tray_map can be parsed as a load_holder, lines 2,3 are simply ignored)

[jirhiker]

tray_maps also support explicit hole labeling

circle,1.0,True


<label1>, <x1>, <y1>
<label2>, <x2>, <y2>

[cmmercer]

I tried that as well, and got a different error message that there are too many values to unpack; I think the boolean on the first line causes an issue. I'll try to reproduce to provide a stack trace...

[cmmercer]

  File "C:\Users\cmmercer\.edm\envs\pychron\lib\site-packages\traits\trait_notifiers.py", line 342, in __call__
    self.handler(*args)
  File "C:\Users\cmmercer\Documents\Mercer\USGS\Pychron\Pychron\pychron\loading\loading_manager.py", line 838, in _selected_instances_changed
    self.load_load_by_name()
  File "C:\Users\cmmercer\Documents\Mercer\USGS\Pychron\Pychron\pychron\loading\loading_manager.py", line 293, in load_load_by_name
    self.canvas = self.make_canvas(load_name)
  File "C:\Users\cmmercer\Documents\Mercer\USGS\Pychron\Pychron\pychron\loading\loading_manager.py", line 377, in make_canvas
    holes = self.dvc.get_load_holder_holes(lt.holderName)
  File "C:\Users\cmmercer\Documents\Mercer\USGS\Pychron\Pychron\pychron\dvc\meta_object.py", line 319, in wrapper
    ret = func(obj, name, *args, **kw)
  File "C:\Users\cmmercer\Documents\Mercer\USGS\Pychron\Pychron\pychron\dvc\meta_repo.py", line 743, in get_load_holder_holes
    holder = LoadGeometry(p)
  File "C:\Users\cmmercer\Documents\Mercer\USGS\Pychron\Pychron\pychron\dvc\meta_object.py", line 40, in __init__
    self._load_hook(path, rfile)
  File "C:\Users\cmmercer\Documents\Mercer\USGS\Pychron\Pychron\pychron\dvc\meta_object.py", line 266, in _load_hook
    _, radius = line.split(",")
ValueError: too many values to unpack (expected 2)```