Pressure HighChart

[Stigian]

With the migration from Linux to Windows, I have a weird problem with the axes of the air pressure graph

It seems to have to do with a decimal or dot seperator. Which makes its translation wrong. The rest of the graphs are correct though. I can't put my finger on exactly what the problem is and where it goes wrong. In CMX, the values and therefore the graphs are correct.

2024-01-25 18_56_34-De Griftsemolen - Vaassen (NL) - CumulusUtils – Mozilla Firefox.png

[HansR]

The pressure axis scale is determined by the all-time pressure record high and low.
Now I don't know what happend with the transfer or what you did but apparently those values have been set to somewhere around 10k.
Just check and edit those values.

[SamiS]

When moving data between separate installations, it is extremely important, that all the locale-related settings remain the same. If time format, date format or decimal separator changes, there will be major issues with data usability and correctness. This applies on all cases regardless of moving from windows to windows, windows to linux or linux to windows.

[HansR]

When moving data between separate installations, it is extremely important, that all the locale-related settings remain the same. If time format, date format or decimal separator changes, there will be major issues with data usability and correctness. This applies on all cases regardless of moving from windows to windows, windows to linux or linux to windows.

Correct, but that is not an issue with CUtils as that uses a display locale separate from CMX. So if you use Finnish for CMX you could have the CUtils site in French. And it definitely has nothing to do with the axis scaling which is internal to CUtils. What could happen (but I don't think that would lead to 10K value of pressure) is that a unit change would have taken place.

@Paul: has this been solved?

[mcrossley]

Looks like it is reading eg 1012,9 as 10 129 for some reason?

[Stigian]

When moving data between separate installations, it is extremely important, that all the locale-related settings remain the same. If time format, date format or decimal separator changes, there will be major issues with data usability and correctness. This applies on all cases regardless of moving from windows to windows, windows to linux or linux to windows.

Correct, but that is not an issue with CUtils as that uses a display locale separate from CMX. So if you use Finnish for CMX you could have the CUtils site in French. And it definitely has nothing to do with the axis scaling which is internal to CUtils. What could happen (but I don't think that would lead to 10K value of pressure) is that a unit change would have taken place.

@Paul: has this been solved?

Yes it is Hans. Still didn't understand why it went wrong. I suspect Windows environment variables. At least now it's going well.

[HansR]

Looks like it is reading eg 1012,9 as 10 129 for some reason?

Ah... Good point, I did not think in that direction as a wrong decimal point usually gives other errors

[Stigian]

Looks like it is reading eg 1012,9 as 10 129 for some reason?

Ah... Good point, I did not think in that direction as a wrong decimal point usually gives other errors

With the change of day, I saw a sharply decreasing line in the graph to a normal value. The new record in the dayfile had a "," separator. The rest still had a "." from the previous (Linux) environment. There was an error on field 5 after the thrifty website option. Then I just decided to change the environment variables from Windows to English (United Kingdom). Then performed new installation and transferred the data from Linux. Then it went fine. Long story but still got it right

[SamiS]

When moving data between separate installations, it is extremely important, that all the locale-related settings remain the same. If time format, date format or decimal separator changes, there will be major issues with data usability and correctness. This applies on all cases regardless of moving from windows to windows, windows to linux or linux to windows.

Correct, but that is not an issue with CUtils as that uses a display locale separate from CMX. So if you use Finnish for CMX you could have the CUtils site in French. And it definitely has nothing to do with the axis scaling which is internal to CUtils. What could happen (but I don't think that would lead to 10K value of pressure) is that a unit change would have taken place.

I think it is an issue to everyone if the data files are corrupt due to a locale change. I haven't unfortunately familiarized myself with CUtils, but I would bet that CUtils will not cope if CMX data would have mixed MM/DD/YY and YY/MM/DD dates or something similar, as it also seemingly didn’t cope with descimal separator changing from dot to comma between data lines. Understandably you cannot write your code to expect and cope with all the unexpected scenarios that can happen in real world.

[HansR]

I think it is an issue to everyone if the data files are corrupt due to a locale change. I haven't unfortunately familiarized myself with CUtils, but I would bet that CUtils will not cope if CMX data would have mixed MM/DD/YY and YY/MM/DD dates or something similar, as it also seemingly didn’t cope with descimal separator changing from dot to comma between data lines. Understandably you cannot write your code to expect and cope with all the unexpected scenarios that can happen in real world.

It is true that, if you are moving data from machine to another it is compulsory to use the same locale for CMX. IF that cannot be enforced on the machine you always have the commandline of CMX.

And you are right: CUtils does not read mixed format datafiles. It determines the format (it does not use the locale for that) and assumes all datafiles use the same format. That - so far - has never posed an issue and data problems always have been detected (and warnings issued).

[SamiS]

It is true that, if you are moving data from machine to another it is compulsory to use the same locale for CMX. IF that cannot be enforced on the machine you always have the commandline of CMX.

When using Windows, there were also differences between versions. For example in Win7 Finnish locale used hh:mm:ss, but beginning fron Win10 Microsoft started to use the official format of hh.mm.ss. This bit me with Cumulus 1 ages ago. Also if I remember correctly, on some locales Mono uses different separators than Windows. Basically only way to be sure is to check the settings on both source and destination computer when transferring data.

[HansR]

@samis: yes. And it led me to ask Mark (about 5 years ago) to not use the locale format for storage/data files. I believe we are moving in that direction now, but a lot of water still has to go to the sea (backward compatibility, installed base and more of that type of difficulty )

[HansR]

With the migration from Linux to Windows, I have a weird problem with the axes of the air pressure graph

It seems to have to do with a decimal or dot seperator. Which makes its translation wrong. The rest of the graphs are correct though. I can't put my finger on exactly what the problem is and where it goes wrong. In CMX, the values and therefore the graphs are correct.


2024-01-25 18_56_34-De Griftsemolen - Vaassen (NL) - CumulusUtils – Mozilla Firefox.png

It was not a problem in your data or chart. It was caused by some quirck in HighCharts where the primary axis needs to start at zero and did not respond to the set values of max/min.

Solved in 7.0.0

[Stigian]

It was not a problem in your data or chart. It was caused by some quirck in HighCharts where the primary axis needs to start at zero and did not respond to the set values of max/min.

Solved in 7.0.0

Thank you for the explanation.