On Fri, Sep 5, 2014 at 2:58 PM, Jef Driesen jefdriesen@telenet.be wrote:
I can mind of see the point of doing max depth and time, just to always have those fields in the header data for a dive.
But cylinder pressures etc? Bad idea. They aren't always there anyway, claiming them just because you also have sample data is just wrong, stupid, and print to error (ie the cylinder connected to the pressure sensor may not be the first one, you don't know, stop gues
How can you not have begin/end tank pressure, when the samples contain tank pressure values?
You may not *have* sample pressures, because maybe you don't have a transmitter.
The point I'm making is that the user of libdivecomputer cannot possibly _depend_ on having beginning/ending cylinder pressure data.
So there is no point in trying to make such data up. It doesn't buy the library user anything, and you almost certainly make things *worse*, not better.
In other words: you add no actual information, you add nothing that is valuable, but you *do* add confusion.
If the pressure data is in the samples, then subsurface (or any other user) can - and will - look at the sample data. If you start reporting beginning and ending pressures separately that you just take from the sample data anyway, the *only* thing you do is to make for a more complex download with more room for errors.
Why the f*ck would you want to do that? It's stupid. It's wrong. It doesn't _help_. It only hurts.
Now, if the dive computer *separately* reports data like that, in addition to the data in the samples, then by all means, pass that kind of information through. But don't make it up based on other data.
An example of that is "maxdepth", where many dive computers (all?) report maxdepth as a separate thing from the depth data in the profiles. And it doesn't always match - the dive computer may save sample data at some particular frequency that is almost certainly separate from the actual internal sampling frequency. So in this case, maxdepth may actually have a *separate* value from the maximum depth found in the samples. THEN it is real data.
But if it's just something you figured out from the samples, you SHOULD NOT LIE to the application and tell it that the dive computer reported it.
Get it? You'd be *lying* about the dive computer. You'd be making shit up. And you'd almost certainly be *worse* at it, than we are. You only look at one dive computer at a time, subsurface will not. You don't have any way to match pressure sensors to particular cylinders, but subsurface might (ok, we don't, but at least we track it and there's a chance we might allow user editing etc). The moment you say "let me make things up based on other things", you're basically just making it harder to use the library sanely, because at that point we can no longer trust the data you give us to be what the dive computer reports. See?
I'd much rather *not* get begin/end pressure data, and know that that means "the dice computer does not save that separately" than get made-up pressure data that I then don't know if it's the dive computer that has such things, or just Jef that is making shit up again. See the difference between the two cases?
(And this is not just about pressure data. This is about temperature, about depth, about anything. Give us what the dive computer reports, not some "sanitized view" that means that we don't know what is dive computer and what is some random library version.
Linus