Bug 124807 - Cell formatting and calculations of Sexagesimal (base 60) angular measurement, aka DMS
Summary: Cell formatting and calculations of Sexagesimal (base 60) angular measurement...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Calc (show other bugs)
Version:
(earliest affected)
unspecified
Hardware: All All
: medium enhancement
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: needsDevEval
Depends on:
Blocks: Number-Format Calc-Enhancements
  Show dependency treegraph
 
Reported: 2019-04-18 01:48 UTC by Joseph Conner
Modified: 2021-10-16 16:06 UTC (History)
6 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Joseph Conner 2019-04-18 01:48:31 UTC
Calc cell FORMATTING does not seem to provide for formatting in angular measurement. I would like to be able to format as DDD.MM.SS.SSS, or as DDD.dddddd or in grads depending upon my specific requirements at the time.

The closest seems to be time functions, but I would prefer to also have trigonometric functions available in degrees, etc.

Perhaps this is a feature request rather than a bug of omission.
Comment 1 V Stuart Foote 2019-04-18 06:01:47 UTC
Strange that this has not come up before in the LibreOffice era. But see also OOo issue 58369 had opened a requirement.

LibreOffice (as OOo before) and MS Excel already work internally in Radians--see the DEGREES function for conversion from Radians. From those, cell calculations and conversion formulas for any Spherical trig angular measurements can already be achieved. Conversions to Degrees is into decimal degrees.

So, lacking is native handling of DMS Sexagesimal notation formatting (or any of its derivatives) for angular measurement. It would be nice to be able to directly input, calculate and format results of angular measurements in DMS. Maybe needing a new Cell format category.
Comment 2 Winfried Donkers 2019-04-18 06:30:54 UTC
(In reply to V Stuart Foote from comment #1)
> So, lacking is native handling of DMS Sexagesimal notation formatting (or
> any of its derivatives) for angular measurement. It would be nice to be able
> to directly input, calculate and format results of angular measurements in
> DMS. Maybe needing a new Cell format category.

Apart from DDD.dddddd, DDD MM SS.sss and grads, output format DDD MM.mmmm is also desired (as mentioned in the OOo issue). 
This format is used for navigational purposes (e.g. GPS position) and I use it almost weekly in Calc for conversions and/or calculations.

I can and want to work on the functions/calculations to be added to Calc, but for adding a new cell format category (including its ODF formatting) I would need help.
Comment 3 Laurent Balland 2019-08-16 15:30:01 UTC
To add this new format, we would need:
1. Define in which category we should implement it: time or number? or create a new category?
2. Choose a symbol for degree which will be unambiguous. The best would be internationally unambiguous. It could only be uppercase, and 'D' is already for DAY, as well as E, G and R for different formatting of era.
Check this page for already used codes:
https://help.libreoffice.org/Common/Number_Format_Codes
If you reduced to symbols never used, I see: B, C, F, I, L and Z
If we choose B for degree, such format
BB"° "MM"' "SS.000"''"
will give for 3.14159265...
03° 08' 29.734'' 

Another solution would be to used notation of calendars, and create a new "calendar", such as
[~sexagesimal]00"° "MM"' "SS.000"''"
It would then be classified as a date.

Or defined a new keyword:
[SEXAGESIMAL]00"° "MM"' "SS.000"''"

Formats without second must be carefully considered to avoid confusion between minute and month for M.

Maybe Eike has a better idea.
Comment 4 robert 2021-10-16 10:08:24 UTC
It's being two years now since the opening of this issue. Has this been solved? I cannot find a way to format a number to DDD.MM.SS. Thanks.
Comment 5 Wolfgang Jäger 2021-10-16 16:05:40 UTC
See tdf#141870   

A sufficiently general implementation of the feature I requested there would include the enhancement requested here as a use-case. 
 
This way we wouldn't need a new formatting feature here and, one there, and probably...