<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote">On Wed, Jan 7, 2015 at 5:25 PM, Dirk Hohndel <span dir="ltr"><<a href="mailto:dirk@hohndel.org" target="_blank">dirk@hohndel.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><span class="">On Wed, Jan 07, 2015 at 03:01:31PM +0200, Willem Ferguson wrote:<br>
> I have a Subsurface xml file log (7 dives) that I export to CSV, checking<br>
> the option "CSV dive details". Two issues:<br>
><br>
> 1) The Subsurface exported CSV data are comma-delimited, yet the Subsurface<br>
> import panel has a default of tab-delimited. Given the column headings<br>
> provided by the CSV export file, it should be rudimentary to test for the<br>
> delimiter used and set the preference in the import panel accordingly.<br>
<br>
</span>Funny, that's an idea that I had last night. Do trivial, minimal parsing<br>
and at least auto-detect our own format :-)<br>
<span class=""><br>
> 2) This brings up a second issue. The Subsurface export file provides<br>
> headings upon re-import into Subsurface and the  CSV import table shows the<br>
> imported heading in row # 2. So, it's not necessary to supply the headings<br>
> because they were provided by the import file. But now, what should one do<br>
> with the empty first row of the table? See attached screenshot 1.<br>
<br>
</span>That's where the headings need to be dropped. What we need to do is what I<br>
said above - it needs to be pre-populated.<br></blockquote><div><br></div><div>Some other CSV exports have headers as well. I suggest that we display the header line, but allow user to mark it as a header -> grayed out during the configuration and to be dropped on the import. It is useful to see the actual column names when configuring the import (a lot easier to match the correct tags).  <br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> 3) I have dive notes that look something like this:<br>
><br>
> Dive plan:<br>
><br>
> 48m     12 min<br>
><br>
> asc 30m   2 min<br>
><br>
> 30m         1 min (deep stop)<br>
><br>
> asc 15m     2 min; switch EAN50 20m<br>
><br>
> 15m     1 min<br>
><br>
> 12m   2 min<br>
><br>
> 9m    3 min<br>
><br>
> 6m     5 min<br>
><br>
> 4.5m       13 min<br>
><br>
> Total run time: 41 minutes<br>
><br>
> The dive notes are given, 1 line at a time, in the import table (see<br>
> attached screenshot 2). Result is that each dive takes several rows of space<br>
> in the import table: impossible to parse for import.<br>
<br>
</span>That simply is an invalid format.<br></blockquote><div><br></div><div>IIRC the current XSLT attempts to import multi-line notes properly if they are quoted with "". And we do export multiline notes on CSV export.. So we need to either support them reasonably well or discard them on our own export.<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<span class=""><br>
> In hand-prepared CSV imports, the program handled the information much, much<br>
> better.<br>
<br>
</span>Yes - we have no concept of importing such dive/deco plans right now.<br>
Sure, something we could add, but that's a whole new level of interesting<br>
complexity.<br></blockquote><div><br></div><div>The multi-line notes are really complex to parse with XSLT and I am sure there are a lot of errors there. And they are really against the concept of CSV where each line should be one dive. I am totally ready to discard the support for multi-line notes altogether and require one dive to be one line. And on our own export grab only the first line of the notes. Would make everything a lot simpler on the parsing side. And way less bugs in the code.<br><br>miika<br></div></div></div></div>