[Kst] Re: branches/work/kst/portto4/kst/src/datasources/ascii

[Peter Kümmel]

On 05.02.2011 23:29, Nicolas Brisset wrote:
>> If I were asked how to put units in an ascii file, I'd have them
>> under the column headings (labels) and within square brakets.  That is how
>> I have seen units in several different ascii files before.  I think
>> that both makes it somewhat obvious that it's meant to be a unit (and not
>> just an additional label (or even continuation) and also solves the
>> space problem.  Just my 2¢.
>>
>> On Sat, Feb 05, 2011 at 03:39:22PM -0500, Barth Netterfield wrote:
>>> How do you handle spaces?
> I'm not sure I understand the question. Is it at least clear the the basic principle is to have units in a line of the ASCII file, just as we can have field names? Like this for instance:
>
> First test - low speed
> Pitch input
> Time         CStk         PStk         RStk         YPdl         Phi          Theta        Psi
> s            %            %            %            %            deg          deg          deg
> 0.04         48.50        42.13        53.53        30.62        0.07         7.30         141.31
> 0.06         48.42        42.09        53.53        30.69        0.07         7.30         141.31
>
> Now if the issue is: how do we make sure that units don't mismatch because some are missing (replaced by "whitespace"), then here is my answer:
> 1) if you use delimiters (say: ";"), then no unit would be ";;" and as long as we don't discard the empty unit it does not introduce an offset. That's the point I mentioned earlier, because I fear right now we do do discard empty elements. But it's easy enough to change.
> 2) if you use fixed-width columns, the same applies: we just have to generate empty strings for the units metadata string. It is handled gracefully by the label generator
> 3) it you use space/tab delimited and some units are missing, you'll get into trouble indeed. But then, you don't have to use units and you can also fix your file if it's like that - which for me is clearly a situation that should not occur, or where the user should at least understand that kst can't get it right
>
> Maybe the "each column has a constant width" option allows to get it right even when using the "space/tab delimited" option (I haven't tested), but in any case I think we do a good enough job of handling units with the current principle. We can try to be smart, but we don't have to / can't cover all corner cases. Going in that direction, there are already cases we don't cover: missing or duplicate field names. But we have to trust the user at some point to not produce too much bogus, or at least be able to fix it if he runs into issues!

Each constant width is calculated when the data is read, but this s too late for reading the units.

>
> Is it clear now? Otherwise, I'd recommend you make some tests with the TWIN* samples in sample_data in the svn source tree to get to grips with the idea.
>
> So, to sum up: for me, the current handling is good enough as soon as:
> 1) someone has looked at the code I produced to make sure it is not completely broken
> 2) we ensure that in the first 2 cases above we don't discard empty units but put an empty string in the "units" metastring of the corresponding vectors
> 3) we avoid adding square brackets around the unit name if it already has them, as Matthew seems to say he has seen - I'll take care of that one

Sounds like we will not have much trouble with this new feature, good job!

Peter