Comma is a common decimal separator in the rest of the world...

[+Odberger]

Can you please fix so that the site can handle comma as decimal separator as many countries in the world uses that rather than a dot...

Example: N59° 29,108 E018° 01,541  (Fake coords)

That one gives "wrong coordinates" when trying them in your checker. That could be ok if you then tell that it's an illigal character that gives the wrong coordinates (you get a false negative when using comma) , but better would be to just accept a comma as decimal separator...

And if those same coordinates are just pasted to update the coordinates you don't even get an error but this result: N 59° 30.800′ E 18° 10.017′ (!?)

That is totally wrong, but also easy to miss as the site just accepts and converts them on it's own initative. Yes, you have to press accept to apply the new coords, but it's really easy to miss that the site totally altered them just because of a comma instead of a dot! It would be better if the site could accept/handle comma as a decimal separator OR really decline and say something like "not valid coordinates", "use of comma not accepted" or similar...

 

 

Edited May 8 by Odberger
don't use real final coodrinates!

[+arisoft]

This is a more important feature than displaying the date numbers in the correct order. And easy to implement after the decision to add this feature is made.

[geoawareUSA9]

Revealing puzzle solutions is against the forum terms of use, even when not identifying the puzzle. Please be more considerate of cache owners in the future.

[+Odberger]

36 minutes ago, geoawareUSA9 said:

Revealing puzzle solutions is against the forum terms of use, even when not identifying the puzzle. Please be more considerate of cache owners in the future.

Sorry! I've changed to fake coords

Edited May 8 by Odberger

[+kunarion]

4 hours ago, Odberger said:

Can you please fix so that the site can handle comma as decimal separator as many countries in the world uses that rather than a dot...

Example: N59° 29,108 E018° 01,541  (Fake coords)

That one gives "wrong coordinates" when trying them in your checker. That could be ok if you then tell that it's an illigal character that gives the wrong coordinates (you get a false negative when using comma) , but better would be to just accept a comma as decimal separator...

And if those same coordinates are just pasted to update the coordinates you don't even get an error but this result: N 59° 30.800′ E 18° 10.017′ (!?)

That is totally wrong, but also easy to miss as the site just accepts and converts them on it's own initative. Yes, you have to press accept to apply the new coords, but it's really easy to miss that the site totally altered them just because of a comma instead of a dot! It would be better if the site could accept/handle comma as a decimal separator OR really decline and say something like "not valid coordinates", "use of comma not accepted" or similar...

 

 

 

Which map service accepts commas a decimals?  Google Maps does not.

 

Or is your suggestion to allow any symbols decimal points within the Geochecker, for convenience of copy/pasting of puzzle answers?

 

Edited May 8 by kunarion

[+Odberger]

16 minutes ago, kunarion said:

 

Which map service accepts commas a decimals?  Google Maps does not.

 

Or is your idea to allow every symbol as a decimal point within the Geochecker, for convenience of copy/pasting of puzzle answers?

Some examples:

https://www.geocachingtoolbox.com/index.php?lang=en&page=coordinateNotation&status=result
https://www.bing.com/
https://www.mapquest.com/

[+Odberger]

20 minutes ago, kunarion said:

 

Which map service accepts commas a decimals?  Google Maps does not.

 

Or is your idea to allow every symbol as a decimal point within the Geochecker, for convenience of copy/pasting of puzzle answers?

What I'm most against is that the site "accepts" and converts the coordinates given with decimal instead of point without much information... E.g. N59° 29,108 E018° 01,541 is converted to N 59° 30.800′ E 18° 10.017′ when pasted into the updated coordinates?!

Edited May 8 by Odberger

[+arisoft]

22 minutes ago, kunarion said:

Which map service accepts commas a decimals?

 

For example https://xiit.dy.fi/gc/ and https://asiointi.maanmittauslaitos.fi/karttapaikka/

 

It is standard. Even Excel is using commas because of the standard and this makes difficult to copy/paste results to the checker. Groudspeak is usually following official standards.

 

Originally, the SI system accepted only the comma as the decimal separator. In 1997, the use of the decimal point was allowed as an alternative in texts that are predominantly in English, and in 2003 the rule was further relaxed to allow the use of the decimal point regardless of language, if this is the custom in some situations. In most European countries, the decimal separator is still the comma. In Finland, the decimal separator is still explicitly a comma according to SFS 4175 standard.

 

Edited May 8 by arisoft

[+arisoft]

1 minute ago, Odberger said:

E.g. N59° 29,108 E018° 01,541 is converted to N 59° 30.800′ E 18° 10.017′ when pasted into the updated coordnates?!

 

I guess that it is trying to use the coordinates as minutes and seconds if there is a comma as a field separator.

[+Odberger]

53 minutes ago, kunarion said:

 

Which map service accepts commas a decimals?  Google Maps does not.

 

Or is your suggestion to allow any symbols decimal points within the Geochecker, for convenience of copy/pasting of puzzle answers?

 

Not every symbol, but a COMMA, which is used in a large number of countries (yepp, there ARE other countries than the US... ;-)
https://www.smartick.com/blog/other-contents/curiosities/decimal-separators/
"The majority of European countries use the decimal comma."
"The countries found to the north, like the U.S.A and Canada, use the decimal point, although the comma is used in the Francophone area of Canada as well. "  ;-)
 

[+kunarion]

1 minute ago, Odberger said:

Not every symbol, but a COMMA, which is used in a large number of countries (yepp, there ARE other countries than the US... ;-)
https://www.smartick.com/blog/other-contents/curiosities/decimal-separators/
"The majority of European countries use the decimal comma."
"The countries found to the north, like the U.S.A and Canada, use the decimal point, although the comma is used in the Francophone area of Canada as well. "  ;-)
 

 

Allowing most any such symbol would be more useful than only the comma.  Yes, there are puzzles that produce other symbols.

[+Odberger]

7 minutes ago, kunarion said:

 

Allowing most any such symbol would be more useful than only the comma.  Yes, there are puzzles that produce other symbols.

Other symbols aren't part of any standard anywhere?! Or do you have other information regarding that? And what would those "other symbols" be according to you? !"#¤%&? We have a symbol for degrees "°" - is that an "other symbol"?

Edited May 8 by Odberger
Clarification

[+MtnGoat50]

Speaking as an American, I would agree that most people here (who haven't traveled) don't know, and would be surprised to learn, that a comma is used as a decimal separator in many parts of the world. However, at least from my experience travelling, people living in Europe and other areas that use a comma do understand that both are used.

When I first travelled in Europe in 1973 I remember being surprised to see commas as a decimal but after a few moments of contusion I had no trouble adapting to the local custom. I think if you go back to your example cache page and look at posted coordinates they use a dot for the decimal, the example coordinates provided in the checker also use a dot, so doesn't it make sense to use a dot when you enter your solved coordinates?  For me at least, this seems like a situation where it's better for the user to adapt rather than the site spending engineering time fixing what (IMHO) is a minor problem. (YMMV)

[+arisoft]

3 hours ago, HHL said:

The false negative is correct as coordinates always uses a decimal point. This is to avoid confusion with coordinates in CSV files (where the comma is a data seperator).

 

Wrong, in Finland CSV separator is a semicolon. And it does not matter if the data in a file is binary, hexadecimal or ASCII, because the problem is in the user interface which tries to understand many formats automatically.

[+arisoft]

On 5/8/2024 at 9:16 PM, MtnGoat50 said:

For me at least, this seems like a situation where it's better for the user to adapt rather than the site spending engineering time fixing what (IMHO) is a minor problem. (YMMV)

 

In this case, the time it takes an engineer to fix this is less than the time European geocachers waste turning commas into dots millions of times.

Edited May 9 by arisoft

[+Odberger]

11 hours ago, MtnGoat50 said:

Speaking as an American, I would agree that most people here (who haven't traveled) don't know, and would be surprised to learn, that a comma is used as a decimal separator in many parts of the world. However, at least from my experience travelling, people living in Europe and other areas that use a comma do understand that both are used.

When I first travelled in Europe in 1973 I remember being surprised to see commas as a decimal but after a few moments of contusion I had no trouble adapting to the local custom. I think if you go back to your example cache page and look at posted coordinates they use a dot for the decimal, the example coordinates provided in the checker also use a dot, so doesn't it make sense to use a dot when you enter your solved coordinates?  For me at least, this seems like a situation where it's better for the user to adapt rather than the site spending engineering time fixing what (IMHO) is a minor problem. (YMMV)

Well, you have kind of a point. However, the problem is that the system accepts comma as separator, but then it also alter the coordinates without informing the user about that. I prefer if the system could accept comma as separator. Not such a biggie for a programmer to fix the code for that... But if it can't be fixed that way, then it should at least warn about that and reject those coordinates. Not as it's now when it accepts them and alters them to some arbitrary coordinates!

[+Odberger]

1 minute ago, HHL said:

From Google help:

 

From Wikipedia:

 

This type of standardization also applies to other applications (as in Geocaching coordinates).

Well, not sure if you even read my posts? Please do so before answering... I'm saying that it's ok if the system doesn't accept comma as separator but then it should give an error! Now it accepts comma as a separator with the twist that it alters the coordinates without informing about that...

[+Odberger]

6 minutes ago, HHL said:

From Google help:

 

From Wikipedia:

 

This type of standardization also applies to other applications (as in Geocaching coordinates).

"Both a comma and a period (or full-stop) are generally accepted decimal separators for international use."
https://en.wikipedia.org/wiki/Decimal_separator

[geoawareUSA9]

Now that we've had a nice discussion about how there is no universal standard for coordinates, and that commas and periods are both accepted outside of geocaching, I'd like to point out that Groundspeak is pretty up front about which coordinates to use for geocaching.

 

Coordinate formats: all examples use periods

How to get accurate coordinates: all examples use periods

 

When hiding a cache, there is a dialog on acceptable formats:

 

 

And, of course, the coordinates for all geocaches on the site are displayed with decimal separators, not commas.

 

However, I fully agree it would be a helpful feature to either reject commas entirely or forcibly convert comma separators to periods. In any case, it is not helpful that the website currently accepts commas and then converts them into incorrect coordinates. So I will leave this up for potential Groundpeak comment or action as far as it is a bug report/feature suggestion.

Edited May 9 by geoawareUSA9

[+thebruce0]

Yes I think it should be emphasized that the point of the post was not about which standard to use to employ or accept, but rather than coordinates are 'converted' and altered given a hidden starting assumption into a result that is incorrect yet without any indication that something has been dramatically changed. A human looking at a standard format coordinate string yet with comma in place of period would understand the commas to be in place of decimals, and handle conversion properly. But the conversion process treats the commas as part of a very different coordinate format.

 

So instead of assuming the converted coordinates are correct, there could be a couple of options:

1. Provide a before and after if conversion takes place, to verify the resulting coordinates according to the human viewing, to confirm before applying them.

2. If coordinates seem to match one format and could be converted but a character is different (or even just a check for comma instead of decimal), then alert the user to enter proper format coordinates (eg: If I accept "##,##,###" for DMS format, I won't assume that "##,###" entered was supposed to be DMS and convert it silently, but rather alert that it appears the numbers were entered incorrectly)

It's one thing to provide a flexible input where the format of entry can be determined by the input value, but it shouldn't make assumptions to what it thinks is the 'nearest match', or there could be some big mixups, especially if the user isn't alerted to the fact that a specific format wasn't determined from the input and one was assumed and math performed to make the adjustment.

 

As another example, a phone number input could accept both "##########" (10 digits) and "###-###-####" then format the result as (###) ###-####. But if someone enters 8 digits, it shouldn't assume the last two missing digits are 0's, for example. At least without informing the user.

Or perhaps closer to the OP - if a form requests a country code with phone # while accepting input worldwide, it shouldn't assume +1 (Canada/US) if the user is in Germany and doesn't provide theirs... at least without indicating the assumed default.

[+MtnGoat50]

11 hours ago, Odberger said:

Well, you have kind of a point. However, the problem is that the system accepts comma as separator, but then it also alter the coordinates without informing the user about that. I prefer if the system could accept comma as separator. <snip> But if it can't be fixed that way, then it should at least warn about that and reject those coordinates. Not as it's now when it accepts them and alters them to some arbitrary coordinates!

My post was responding specifically to your example in the OP where the puzzle coordinate checker rejected the coordinates. You say, "as it's now when it accepts them and alters them to some arbitrary coordinates!"  Can you provide a current example? I believe the latest release (from last Tuesday) corrected that problem, at least I can't duplicate it anymore.

[+Odberger]

13 hours ago, MtnGoat50 said:

My post was responding specifically to your example in the OP where the puzzle coordinate checker rejected the coordinates. You say, "as it's now when it accepts them and alters them to some arbitrary coordinates!"  Can you provide a current example? I believe the latest release (from last Tuesday) corrected that problem, at least I can't duplicate it anymore.

Same bogus coordinates as in the first post used on a random cache and those coordinates are the posted coordinates.

N59° 29,108 E018° 01,541 is converted to N 59° 30.800 E 018° 10.017

[+Odberger]

A bit OT, but a feature I would also like to have is that you get a warning if you try to update the coordinates for a myst/unknown to something more than 3.2km from original coordinates. Then the example above would have been flagged and a warning would have come up. This feature wouldn't flag all of these conversions as some might be smaller and wouldn't exceed 3.2km though. It should be just a warning, as the cache can't be placed further away according to the guidelines (not true for really old caches), but you should still be able to alter coordinates to something further away than 3.2km.

[+MartyBartfast]

I 100% agree with the OP, if the site doesn't process co-ords with a comma properly then it should reject them as invalid.

I just did some testing of this myself and found that if you only replace one . with a , E.G. N51 01.234 W000 05,678 it is rejected with:

 

so it's obviously doing some parsing for the correct format and that parsing should be extended to reject if both separators are a , or alternatively do it right and accept a , and process it correctly.

 

 

[+arisoft]

It changes commas to spaces before parsing. Try with spaces and you may get the same result.

[+MtnGoat50]

5 hours ago, MartyBartfast said:

I 100% agree with the OP, if the site doesn't process co-ords with a comma properly then it should reject them as invalid

Exactly! I totally agree too.

 

7 hours ago, Odberger said:

Same bogus coordinates as in the first post used on a random cache and those coordinates are the posted coordinates.

Thanks for the example.

 

2 hours ago, arisoft said:

It changes commas to spaces before parsing. Try with spaces and you may get the same result.

Yes, I see what’s happening. It’s treating the number after the comma as seconds instead of decimal minutes. Rather than throwing an error, since the value is greater than 60, it tries to convert it,108/60 = 1.800’ and 541/60=9.017’ . This is clearly a bug that should be fixed.