APRS-IS "include packets from location" filter: unknown format for lat/lon

Issue #69 resolved
Joerg Schultze-Lutter created an issue

I intend to use a “x km away from my location” filter. QTH tells me to provide the lat/lon coordinates:

Following the given format description, I provide my lat/lon coordinates:

However, the format is deemed invalid:

What kind of format is supposed to be used?

Comments (5)

  1. Weston Bustraan repo owner

    Hi Jörg!

    I am wondering if you use a different number separator on your computer? I am using the built-in NumberFormatter to parse numbers and it is Locale aware. I know that in French, they use commas as the decimal place. Is that the case in Germany as well?

    I typed the same numbers as you did in the screenshot and it accepted the lat/lon, so that leads me to think that maybe there is something different between about the OS.

  2. Joerg Schultze-Lutter reporter

    Hi Wes - please see my separate posting on Google groups. I doubt that this is related to my computer’s settings (but I’m ready to get convinced :-)) Try the Install-MacOS-form-scratch solution and check your app on that one. I am pretty certain that it will experience the same issues as on my computer.



  3. Weston Bustraan repo owner

    So, I installed Big Sur on an external drive and set the Locale settings exactly like you had them, i.e. English language but Germany region.

    I got the same error you did. However, when I changed Language and Region > Advanced > Decimal from a comma to a period, it worked.

    With Decimal set to comma, it should hypothetically work to enter coordinates as “51,845, 8,299”. However, because I’m using the comma as a separator between lat and lon, it splits the string at the first comma it finds and fails to parse the rest.

    So, this is where I ask you, as a German, what you would want to enter in? Do Germans format their numbers according to your settings, and lat/lon differently?

  4. Joerg Schultze-Lutter reporter

    The answer is “it depends”. Let me explain:

    Europeans use the comma as separator between the a value’s pre-decimal and post decimal places. Dependent on the context, they may use additional separator dots for better legibility. Example: 1.234,56 EUR equals one thousand two hundred thirty four Euros and 56 cents.

    We’re not going to deal with those additional separators when it comes to latitude and longitude. Therefore, the general recommendation would lean towards “use a comma” - see also https://de.wikipedia.org/wiki/Geographische_Länge where there are a few examples on the native format that we use over here.

    However … you might be stuck with a user who tweaked a few of those MacOS locale settings. I applied some of these changes to my Mac - even though I mainly use the U.S. Mac user profile, some of the settings relate to German settings.

    Additionally: even if a user has not tweaked his Mac’s settings, that user may copy-paste e.g. a Google Maps coordinate setting from a different locale with deviating formats - and you’d face the same issue. Ultimately, this may end in a battle that you cannot win.

    During the design phase of my APRS daemon, I went for the pragmatic approach, meaning that I tell the user what the valid/permitted formats are - which I think is the main obstacle here. For the QTH “location” input window, It is obvious that I am to supposed to enter coordinates - but I don’t know anything about the valid formats (UTM, DMS, LatLon, …). Add a brief help text and advise on the supported format(s) - even if this means that you are going to ignore the user’s native format. But the one that you define is the one that has to work.

    You might also want to think about whether it makes sense to permit the user to use DMS coordinates as input data. Even though it does look nicer, there may be so many different variants when it comes to international formats of DMS coordinates (Google copy-paste, rogue users reconfiguring their Macs et al)

    Apart from accepting other coordinates such as grid locator or address data, I decided only to accept numeric lat/lon values for my APRS daemon. My regex does however support both decimal point and decimal comma - give this one a try on e.g. https://regex101.com/:


    Hope this helps - and: welcome to software internationalization. It is fun, isn’t it …? 😇

  5. Weston Bustraan repo owner

    As of v0.1.4, the parsing should accept more variations in the format. I don’t have support for the cardinal directions (NSEW) in other languages, yet; that will come with localization

  6. Log in to comment