DMSValueFormatter with ICAO Geodetic Display Format (WGS-84)

[gcng54]

Hi,

I want to suggest about DMSValueFormatter formats. Its effect can be much.
So, after considering by you.
if you approve, I can try some changes.

Best regards.

for toDMSFormat----

format("%d°%d'%s"%c", degrees, minutes, secondsWithRelDigits, directionSymbol);

but in ICAO Geodetic Display Format (WGS-84) Format Specification is

Latitude: DD°MM'SS.S"N or S
Longitude: DDD°MM'SS.S"E or W
as
Latitude: 40°03'45.2"N
Longitude: 032°51'12.7"E

SS.S: Seconds with one decimal place (optional but common)
ICAO Annex 15 recommends at least 0.01 arc seconds precision

Describe the solution you'd like

I suggest you use this standart format.
I think, it needs changing on DMSValueFormatter and ValueFormatter also Test files.

Also, in LatitudeTest for default or zero value, it should not display full second decimal.
String latInDms = latitude.toDMSFormat();
assertThat(latInDms).isEqualTo("52°14'5.123000000003799"N");

Describe alternatives you've considered

public String toDMSFormat() {
    // return DMSValueFormatter.latitudeToDmsFormat(this, -1);
    return DMSValueFormatter.latitudeToDmsFormat(this, 2); 

private static String createDMSNotation(double coordinateInDegrees, char directionSymbol, int relevantDigits) {
   //  String secondsWithRelDigits = relevantDigits > 0
    String secondsWithRelDigits = relevantDigits >= 0

// format("%d°%d'%s"%c", degrees, minutes, secondsWithRelDigits, directionSymbol);
for latitude > format("%02d°%02d'%s"%c", degrees, minutes, secondsWithRelDigits, directionSymbol);
for longitude > format("%03d°%02d'%s"%c", degrees, minutes, secondsWithRelDigits, directionSymbol);

// formatValueToDecimalPlaces shoul have overload for arc second SS.S display
formatString = "#." + "#".repeat(numDecimalPlaces);

Additional context

https://docs.google.com/viewer?url=https%3A%2F%2Fskybrary.aero%2Fbookshelf%2Fbooks%2F5854.pdf

[pjazdzyk]

Hi,

Thanks for pointing this out. So to summarize, the goal would be to:
a) ensure that lat/lon will include trailing zeros
b) seconds by default will be cut to 0.01 precision

I will try to look into this. I think this is good idea to make it fully ICAO compliant, thanks!

[pjazdzyk]

Done, to will be included in next release (3.0.0).

You can check branch: feature/3_0_0_relase_new_quantities if this is what you expected, thanks!

[gcng54]

Congratulations,

You fast.

Distance is perfect.

for "toDMSformat "; degree is ok. but minute and second still can be one digit.

Also Default second decimal digit is still full (-1)
// return DMSValueFormatter.latitudeToDmsFormat(this, -1);
return DMSValueFormatter.latitudeToDmsFormat(this, 2);

Additionally, if you set zero to DMS, its display full
// String secondsWithRelDigits = relevantDigits > 0
String secondsWithRelDigits = relevantDigits >= 0

Best regards.

Nowadays, I am working on your code to UML for learning.

[pjazdzyk]

Thanks I will look into this.

One issue might be especially problematic. Because that relevantDigits concept, is treated in mathematical meaning, so if you will have value of seconds: 0.0000000123456, and you set set significant digits to 2, you will get: 0.000000012, if set to 3, you will get: 0.0000000123.

Now correct me if I'm wrong, but you would expect that this be kind of a "cut off" number, for an example:
-> 1.12345 -> digits set to 2 = 1.12
-> 1.12345 -> digits set to 3 = 1.123
-> 1.12345 -> digits set to 1 = 1.1
-> 1.12345 -> digits set to 0 = 1
Am I correct?

I propose to do like this:

• the default toDMSFormat() (without specifying relevantDigits) -> we can default to precision of 0.01, but in this particular case hardcode cut-off after second digit. And when relevant digit is specified - > then we could use default relevantDigits behaviour as described above.

Alternative I can switch globally for DMS to precision mode, instead of relevant digits. Maybe for this particular usecase it makes more sense. It will be breaking change but it will be part of major release so it is acceptable.

Let me know if this would be OK for your potential applications.

[pjazdzyk]

OK, I have pushed changes, switched to precision for DMS, minutes trailing zeros should be now guaranteed.

[gcng54]

Goodmorning,

My warning about was seconds in DMSFormat.

When use cut of Degrees with zero it works
(35.5656, 0) = 35 but for dms
dms(0) = 35.30.15.1000000012N it should be 35.30.15N also
and dms() = 35.30.15.1000000012N it should be 35.30.15.15N default

I change to these and works
String secondsWithRelDigits = relevantDigits >= 0
return DMSValueFormatter.latitudeToDmsFormat(this, defaulDMSsecondDigit); // defaulDMSsecondDigit=2

Also second has decimal digit problem.
toDMSFormat =35.30.5.123 it should be = 35.30.05.123

In DMSFormat and maybe similar formal, you should not need round. It causes delete zeros and cutoff numbers
dms(15.018) and dms(15.02) both display same "15.02" it should be "15.018 and 15.020" when dms(3)

---

The REASON of all of them is whatever degree of dms for latitude/longitude, the length of dmsformat string should be SAME.
I worked on military project, it was obligatory.

---

I requested but :)) ChatGP have NOT suggest correct degree format for degree with DD, DDM, DMS, DMS_S for each has different fraction length for 1 second accuracy.

public enum Format {DD, DDM, DMS, DMS_S }

DD 35.000000N needs 6,

DDM 035.05.0000N needs 4,
DMS 035.05.35N needs 0,
DMS_S 035.05.35.25N needs 2.

And your mention is about normal degrees. For example, bearing can be 4.
It is a good capability for zero headed numbers for digit request.
I can't say anything for setting significant digits to 2 then getting 0.000000012.
It is very useful especially for compare numbers.

Have a nice Sunday and fun:))

[pjazdzyk]

Ok thanks. So it will be far more complex then I have originally thought.
I think the best course of action is to establish a test case, what is given what is expected.
I propose we focus on one format at the beginning to not fall into an endless pit of problems :):):)

Lets take and focus only DMS_S, as it seems to be closest to what we have here so far.

I have generated via AI some expected results which then could be taken as input to a test scenario. If you could just quickly look into this, if this makes sense, if all corner cases are covered, before I start implementation.

EDGE / BOUNDARIES
LAT +90.0 →     90°00'00.00"N
LAT -90.0 →     90°00'00.00"S
LAT 0.0 →       00°00'00.00"N
LON 0.0 →       000°00'00.00"E

LON +180.0 →    180°00'00.00"E
LON -180.0 →    180°00'00.00"W

INTEGER DEGREES
LAT 35.0 →      35°00'00.00"N
LAT 7.0 →       07°00'00.00"N
LON 5.0 →       005°00'00.00"E

MINUTES NONZERO, SECONDS ZERO
LAT 35.083333333333336 →    35°05'00.00"N
LAT 0.125 →                 00°07'30.00"N

SECONDS WHOLE
LAT 35.09305555555555 →     35°05'35.00"N
LAT -12.505277777777778 →   12°30'19.00"S

SECONDS WITH FRACTIONAL
LAT 35.093125 →             35°05'35.25"N
LAT 52.234567 →             52°14'04.44"N

VERY SMALL FRACTIONS
LAT 35.093001 →             35°05'35.00"N
LAT 35.00027777777778 →     35°00'01.00"N

ZERO SECONDS BUT FRACTIONAL MINUTES
LAT 35.00041666666667 →     35°00'01.50"N

MINUTES OR SECONDS <10
LAT 7.051144444444444 →     07°03'04.12"N

TRUNCATION vs ROUNDING
LAT 35.09309163888889 →     35°05'35.12"N

LONGITUDE SPECIFICS
LON 5.0 →                   005°00'00.00"E
LON 32.85352777777778 →     032°51'12.69"E
LON 179.999999 →            179°59'59.99"E

EXAMPLES NEGATIVES
LAT -0.0002777777777777778 →    00°00'01.00"S
LON -121.90277777777777 →       121°54'10.00"W

RANDOM / FUZZ
LAT 0.0002777777777777778 →     00°00'01.00"N
LAT 45.5 →                      45°30'00.00"N
LAT -45.5 →                     45°30'00.00"S
LAT 89.999999 →                 89°59'59.99"N

Additionally, there should be no rounding up, so if we get: 35°05'35.156789"N -> it should be just cut of to: 35°05'35.15"N?

[gcng54]

You are great.
Good works. :))

[pjazdzyk]

Its not done yet :) Just a corner cases for implementation. It will take some more time.

[pjazdzyk]

Ok, I have pushed another commit, with another attempt to be compliant with DMS_s format.

I think most cases are covered with one small issue: ICAO standard in section 2.5.1 clearly distinguish between resolution and precision. Precision they use for reading from real navigational instruments - but term resolution is for calculations. I have changed naming convention from "precision" to "resolution", and applied rounding.

• Using negative value will cause using default (0.01) resolution.

I think most corner cases are covered, and they are provided in this class:
https://github.com/pjazdzyk/unitility/blob/feature/3_0_0_relase_new_quantities/unitility-core/src/test/java/com/synerset/unitility/unitsystem/geographic/DMSCoordinateFormatterTest.java

Please let me know if this is what you have expected.

[gcng54]

It looks good.

Best regards.