Allow base geodetic coordinate entry in DD-MMM-SS.ssssss Format

[tonycanike]

Subject of the issue

Allow geodetic coordinates to be entered in DD-MMM-SS.sssss format as it is commonly used by surveyors. Currently only DD.dddddddd format is supported, requiring conversion from DD-MMM-SS.sssss to DD.ddddddddd. Allowing the entry in DD-MM-SS.sssss format would eliminate the usually-manual conversion step, saving time and eliminating a potential source of error.

I suggest allowing both formats (DD.ddddddddd and DD-MM-SS.sssss) in the WiFi and Serial Geodetic Base Coordinate entry. I suggest leaving the format as DD.dddddddddd in any settings or coordinate files the Firmware reads and writes. I didn't count the current number of decimal places in the decimal degrees (ddddddddd), so do what you do today. OPUS returns positions as DD-MMM-SS.sssss (5 decimals on the seconds, with spaces instead of hyphens) so that would be sufficient.

Sometimes the longitude is DDD-MM-SS.sssss and sometimes it's DD-MM-SS.sssss , recognize both please.

Don't worry about N&S or W&E, the current convention of N&E being positive and S&W being negative is fine.

DD MM SS.sssss format (without the hyphens) is a viable alternative if there are difficulties in parsing DD-MM-SS.sssss format.

Bonus for displaying the base settings in both formats in the configuration so the user can double-check.

Here's a (pruned and obfuscated) example of a DD-MM-SS.sssss position returned by OPUS. If I can directly use those numbers by inserting hyphens between the DD-MM-SS.sssss and negative signs for S&W coordinates, much fumbling and time would be saved.

       LAT:       38 59 59.38040     
     W LON:       79 59 59.11482   
    EL HGT:          610.878(m)

Your workbench

Facet running v3.3-Mar 11 2023

Thank you!

[tonycanike]

As an aside, if you ever get geodetic coordinates from a surveyor, they may be in DD.MMSSsssss format, which is hard if not impossible to distinguish from DD.dddddddd format. So keep your eyes open!

[tonycanike]

The number of different ways people represent latitude and longitude is quite boggling. There is an ISO standard (6709) but it seems to be largely ignored, at least by many user communities and software developers. A significant downside of some of the ISO6709 formats is shared with the DD.dddddddd format in that there can be long strings of digits unseparated by white space or punctuation, making it difficult to spot transposed digits.

The goal here is to allow users to accurately enter coordinates and then double-check their entry, often in the field under challenging conditions of rain, snow, sunglare, distracting bystanders, head-butting goats, etc. Typically the surveyor is standing, holding their table and phone in one hand. Perhaps the rover pole is leaning against their chest to keep the Sparkfun RTK product out of the mud. Converting from DD MM SS.sssss format to DD.dddddddd format is best not done in these distracting situations. While the conversion itself is trivial at a calm desktop while seated, it can become challenging in real-world field conditions. Long strings of unseparated adds to this challenge.

[amlago]

I totally agree. It would be very interesting to be able to define in which format you want to work.

[nseidle]

I think this is do-able. We should be able to auto detect the difference between DD-MM-SS.sssss, DD MM SS.sssss, and DD.dddddd.

However, showing the position in the WiFi config page it will show as DD.dddddd. For example:

• User enters DD MM SS.ssss and presses save
• Box repopulates to DD.ddddddd format

Is that ok? If not, we'll need to additionally store the format.... Ok that's not that bad. I'll see what I can do.

[tonycanike]

Thanks! It would be most useful to display it in the format it was entered, so the user can check their entry and that the entry was accepted.

[amlago]

It would be good to be able to choose the angle input format and that the input and presentation of the angles be based on that choice.

If I change the format of angles, it should automatically change the presentation of these values.

Of course, internally the calculations are made with values DD.dddddddd. This means that if data is entered in the DD MM SS.ssss format, it must be transformed to DD.ddddddddd for internal calculations.

[amlago]

I don't know if it is possible to store the values in DD.ddddddddd and create a routine that transforms them for display according to the choice of angle format.

It would be the solution to avoid having to store angles in various types of format.

[nseidle]

Progress! We now auto-detect 7 different formats and convert between them:

• DD.ddddddddd
• DDMM.mmmmmmm
• DD MM.mmmmmmm
• DD-MM.mmmmmmm
• DDMMSS.ssssss
• DD MM SS.ssssss
• DD-MM-SS.ssssss

Internally, everything is DD.ddddddddd but in the places where we show coordinates to users, we show coordinates in the format that was auto-detected. There's also a serial (only) menu to change the format if desired.

Tony - in your original request you mentioned "DD-MMM-SS.sssss". Please let me know if this was a typo. I don't believe MMM is a valid value for minutes.

We attempted to detect DD°MM'SS.ssssss" but ultimately gave up because the degree symbol is not easily parsed and I don't think users will be copy/pasting that into the Config page. Let me know if I'm wrong.

[nseidle]

This was implemented in v3.3 of the RTK firmware. Please let us know if you see any problems.

[nseidle]

Docs added.