Create new point showc decimal-komma instead of decimal-point

[gueba]

In gpsprune versions 24.x, creating a new point (Right click on map --> Create new point) and the edit it (Point --> Edit Point) the opened dialouge-window shows the values for latitude and longitude with decimal comma instead of decimal point.

Adding height shows height with decimal point. export (and reloading) works with decimal points as expected.

I often use this to copy and paste the values into files, so this is very disgusting.

Tried under ubuntu 22.04 and windows 10 on java 11 and 17

Thanks in advance

[activityworkshop]

"very disgusting" - what on earth does that mean? :D

If your system uses decimal commas then it's probably not unexpected that values (like numbers of degrees) will be formatted with a decimal comma. When you export to gpx format, then the file format insists on using a decimal point so reloading it will show the value as it was loaded (with a dot). I'm guessing you've chosen "Original" from the coordinate format dropdown.

If you never want to see numbers (like speeds, pace, altitudes, distances) formatted using a decimal comma, then it should be straightforward to start GpsPrune using a US Locale and then all values will be shown with a decimal point.

[gueba]

well, it's not really disgusting - better words are annoying, uncomfortable or troublesome.

It's not a matter with the system, but with version 24 of gpsprune. I have version 21.1 installed from repo in xubuntu 22.04 as well the jarfiles of 23.1, 24.1 and 24.2 and only the 24.x - versions show this behaviour. Chosing other coordinate formats show no changes.

Please see attached screenshots

[activityworkshop]

"annoying, uncomfortable or troublesome" - yes ok, those I can understand.

But I have to repeat my question - do you want to see speeds displayed like "5,53 km/h" or like "5.53 km/h"? Do you want distances to be "1,31 km" or "1.31 km"? Do you expect altitudes like "195,222 m" or "195.222 m"?

Is it just coordinate values in degrees (or coordinate values in any format) which you expect to see displayed with dots instead of commas?

[gueba]

In short: I want the same behaviour I had in version 23.

All values that can be exported in .gpx or kml format should be shown the same style they are exported. So latitude, longitude and height should use decimal points. Creating a new point and editing it shows: Breitengrad: -44,38234020 Längengrad: 171,23855889 Höhe:

getting height from SRTM shows: Höhe: 4.803

export to gpx changes the commas to dots:

    <name>24-wp-komma</name>
    <desc>Export from GpsPrune</desc>
    <wpt lat="-44.38234020" lon="171.23855889">
        <ele>4.803</ele>
        <name>Punkt_24</name>

Editing height manually using the "comma-format"

Höhe: 4,803

is accepted but not changed nor shown nor exported by gpsprune and therefore confusing.

AFAIK the edit-window always shows coordinates in "original" -format and I would like to see (and edit) here what I will get in the exorted file.

Hoping to make it clear now

Thank you for your efforts

[gueba]

Hi, Maybe the following will show the "problem" better: (using version 24.2)

• Create a point or series of points
• Save as text "example.csv"
• Select all
• Delete Range
• Open file "example.csv"
• Next - Next - Finish

Result: No coordinate information found in the file

Example-24.csv

Latitude,Longitude,Segment
48,913475,12,601318,1
48,918890,12,631531,
48,900612,12,637024,

The same procedure works well in version 23.2:

Example-23.csv Latitude,Longitude,Segment

48.88858333333334,12.620722222222224,1
48.89069444444445,12.627583333333334,
48.88713888888889,12.629972222222221,
48.88638888888889,12.61875,

Of course one can chose another delimiter (semicolon) to make the reload work, but even then one (at least me) cannot use the values in the file for other purpose (due to the commas).

[activityworkshop]

"export to gpx changes the commas to dots" - well yes, of course it does. When you export to Gpx, the coordinates must be written in decimal degrees with a decimal dot. That's just what the Gpx file format insists upon. That doesn't necessarily mean that you want to see the coordinates displayed on-screen like that.

"AFAIK the edit-window always shows coordinates in "original" -format" - that's true. And therefore when you load coordinates from a Gpx file and then show them in their original format, then you see decimal degrees with a decimal dot.

"I would like to see (and edit) here what I will get in the exorted file." - at that time there simply isn't an exported file. So the edit dialog shows what was loaded (or created).

"48,913475,12,601318,1" - yes, I think it should be obvious that you can't use a comma delimiter when your coordinates contain decimal commas. As you say, just choose a different delimiter.

I understand that you want to see most values (like distances, average speeds, vertical speeds, gradients) formatted with commas, but you expect a different formatting for latitude and longitude because they "can be exported in gpx or kml format". I find that logic a bit difficult, because (for example) once the speed value of a point or the heart rate can be exported in gpx format, suddenly you'll expect those to be formatted with a decimal dot as well.

I think a much better solution would be to have an extra row in the "View full details" dialog, inside the Point tab. As well as showing the coordinates formatted the way you have specified (with commas), we can simply have an extra entry where the same coordinate values are formatted with decimal dots. Of course this row would only be shown if the user hasn't told their system to format all decimal numbers with dots, because otherwise the two rows would be identical.

If absolutely necessary then the same could be done for the altitude value too, so you'd get the altitude of the point formatted as you've chosen (in your case, with commas) and another row showing the same value formatted with a decimal dot. Although given the accuracy of most altitude measurements from GPS units, probably the millimetres and micrometres are not very significant anyway and you can just copy/paste the whole number of metres.

About your point of manually editing the altitude value with fractional metres and a decimal comma, yes you're right this looks like a bug. It should recognise the comma (for you, anyway, not for me!) but appears to only accept a decimal dot in this case. I'll make sure this is fixed. Until then, you can either enter values with a decimal dot or just enter whole numbers.

Apart from being inconsistent (which I agree, it is), I think the main reason this is so inconvenient to you is that you're trying to copy the values from GpsPrune's display (not its exported file) and expecting them to be pasteable into a file. I'm not sure why you're choosing a workflow like that but personally I'd prefer to shuffle the points around and combine them in a program like GpsPrune and then export the file, without ever using a text editor. Then it doesn't matter how I've configured the display of the values.

[gueba]

"export to gpx changes the commas to dots" - well yes, of course it does. When you export to Gpx, the coordinates must be written in decimal degrees with a decimal dot. That's just what the Gpx file format insists upon. That doesn't necessarily mean that you want to see the coordinates displayed on-screen like that.

Why would anyone want that? What’s the benefit of seeing values written in an incorrect way? Besides, it makes a difference if these values are only shown on screen and can not be manipulated or if they can be used and stored in an incorrect way. Why not forget these IMO totally useless commas and force all values that must use decimal dots to be generated, edited, shown in GUI, exported and stored in files with decimal dots, as it is partwise done in former versions?

"AFAIK the edit-window always shows coordinates in "original" -format" - that's true. And therefore when you load coordinates from a Gpx file and then show them in their original format, then you see decimal degrees with a decimal dot.

And when I add some points and save to text, there will be 123.456 for the old values and 123,456 for the newly created. Does this make any sense?

"I would like to see (and edit) here what I will get in the exorted file." - at that time there simply isn't an exported file. So the edit dialog shows what was loaded (or created).

Again, what’s the benefit of creating or loading in a format, which nowhere else can be used?

"48,913475,12,601318,1" - yes, I think it should be obvious that you can't use a comma delimiter when your coordinates contain decimal commas. As you say, just choose a different delimiter.

But the comma delimiter is pre-checked and this doesn’t make things easier.

I understand that you want to see most values (like distances, average speeds, vertical speeds, gradients) formatted with commas, but you expect a different formatting for latitude and longitude because they "can be exported in gpx or kml format". I find that logic a bit difficult, because (for example) once the speed value of a point or the heart rate can be exported in gpx format, suddenly you'll expect those to be formatted with a decimal dot as well.

No, you misunderstood or I explained bad. I want all values handled with decimal dots. As you say, gpx and kml insist on decimal dots, every application or web service I know insist on decimal dots, so I can see absolutely no reason for using or even allowing decimal commas. I think this logic is pretty straightforward.

As long as I can’t see any benefit in using decimal commas over decimal points, the simplest and best solution IMO would be to get rid of all these „comma-things“ and use dots only – everywhere – independent of system settings.

For my workflow: I often use pre-defined templates, where I fill only the coordinates. Adding or editing single values is comfortable by copy&paste directly from the edit-window or from a csv -file. This worked fine in version 23. Now I have to create a point, export to gpx or kml, reload it and then copy the values or save to csv or changing commas to dots manually.

[activityworkshop]

Why not forget these IMO totally useless commas I want all values handled with decimal dots. I can see absolutely no reason for using or even allowing decimal commas. I can’t see any benefit in using decimal commas over decimal points get rid of all these „comma-things“ and use dots only – everywhere – independent of system settings.

Ok, I think I understand now. In that case we're back to the very first comment I made in answer to your original question:

If you never want to see numbers (like speeds, pace, altitudes, distances) formatted using a decimal comma, then it should be straightforward to start GpsPrune using a US Locale and then all values will be shown with a decimal point.

That's it. Have you tried this already?

There are at least a couple of ways to do this, either at the shell level or at the java level. For example, if I start GpsPrune like this, I get commas (this is what you don't want):

java -Duser.language=de -Duser.region=DE -jar gpsprune_24.2.jar --lang=DE
Breitengrad: -42,570292
Längengrad: 171,679788
Koordinaten: -42,570292, 171,679788

Or I can start GpsPrune like this, and get decimal dots (I think this is what you want):

java -Duser.language=en -Duser.country=GB -jar gpsprune_24.2.jar --lang=DE
Breitengrad: -42.570536
Längengrad: 171.680743
Koordinaten: -42.570536, 171.680743

No code changes necessary.

Again, what’s the benefit of creating or loading in a format, which nowhere else can be used?

I wouldn't say "nowhere". I can copy/paste values into a spreadsheet, or into an email, I can keep a text file or a csv, I can paste them into a Wikipedia page I'm editing, I can do lots of things. Some people expect commas and that's why they configure their systems like that. GpsPrune just tries to honour what the user has selected/configured.

[gueba]

There are at least a couple of ways to do this, either at the shell level or at the java level.

changing sytem is no option. I want to solve "my" issue, not my environment.

Or I can start GpsPrune like this, and get decimal dots (I think this is what you want):

java -Duser.language=en -Duser.country=GB -jar gpsprune_24.2.jar --lang=DE

As far I can see now, this will suit my needs. I didn't think of that, because it worked pretty well in the older versions without this. Thank you for the hint.

No code changes necessary I'm curious. What did the code change from 23 to 24 make nesessary? Maybe the new behaviour should be noted in README or CHANGELOG?

I wouldn't say "nowhere". Well, I do, but arguing this point will lead nowhere...

I'm happy and thankful, that you offered me this acceptable solution. I'm hoping I didn't offend you, gpsprune is a very useful tool for me. Thank's for your work and patience.

[activityworkshop]

There are at least a couple of ways to do this, either at the shell level or at the java level.

changing sytem is no option. I want to solve "my" issue, not my environment.

I understand that. And that is precisely why I did not suggest that you change your system. You configured your system to use a decimal comma. My suggestion was that either you launch GpsPrune with a locale override in your shell (which does not change your system), or you launch with parameters for the java runtime to override which locale the JVM uses. That command with the "-D" parameters is the second of these two options, and it does not change your system.

As far I can see now, this will suit my needs.

Great.

Maybe the new behaviour should be noted in README or CHANGELOG?

It's noted briefly here: https://gpsprune.activityworkshop.net/whats_new.html but obviously the bit about "the effects should be invisible" didn't turn out to be 100% accurate. For users who configured their systems to use decimal dots, there is no real change. For users who configured their systems to use commas and want to see commas, it could be seen as a minor improvement. But the testing for this was incomplete, as can be seen from the SRTM bug fixed by 24.1 and the Exiftool bug fixed by 24.2. That's unfortunate of course, but it happens.

I'm happy and thankful, that you offered me this acceptable solution.

Great, I'm glad to hear it.

I'm hoping I didn't offend you, gpsprune is a very useful tool for me. Thank's for your work and patience.

No problem. I'm glad you got a solution. If you're happy, I'll close this issue.