degrees and decimal mins to sexagesimal

It's not real code, just pseudo-code to represent how to do it by hand. In real code of navigation devices I have worked on the internal representation of coordinates is in double precision floating point numbers with a single number in D.d format.

That appears to be the ISO recommendation too: store as degrees, format as necessary.
 
Tillergirl gets my vote as being the most acute.

So apologies for wasting peoples time,

It's never a waste of time to ponder on detail of our hobby from time to time. By coincidence a lack of clarity on this point was entirely relevant on a recent local east coast notice to mariners about a mooring barge sunk on its mooring on the edge of the fairway in the Crouch. The notice gave the position as: 51 38.05N 000 40.25E. That is how it was written. I assumed this meant 51 38'.05N 000 40'.25E but it turned out it meant 51 38'05"N 001 40'25"E which of course in decimal/tenths is 51 38'.10N 001 40'.50E (approximately). That put the sunken mooring in a completely different trot and further east. Did cause some concern at the time. The issue of course is being clear about the annotation.
 
You are still saying things I don't understand, what is this about?

Ye Olde System was to express angles in degrees, minutes (sixtieths of degrees), seconds (sixtieths of minutes), thirds or tierces (sixtieths of seconds), fourths (sixtieths of thirds) and so on. The units are indicated by superscript roman numerals: 0 for degrees (I thought the romans didn't have zero), I for minutes, II for seconds, III for thirds etc etc.

1 radian = 57.2957795131 ... o = 570 17I 44II 48III 22IV 29V ...

The "Duckland" bit seems to reflect some personal grudge which I neither understand nor particularly care about.
 
That appears to be the ISO recommendation too: store as degrees, format as necessary.

Certainly from a data management point of view that is the only way that makes sense. I have had to cope with systems where Degrees, Minutes and Seconds were stored separately, but it is clumsy and error-prone (especially when the data were stored in eXcel, with no validation possible!). There isn't an ISO representation for internal storage of angles; the ISO 19000 series of standards (which cover all geographic matters, and incorporate older standards like 6709) are purely about the exchange and specification of data, not internal representation. And the standards have to cover other types of measurement system; for example, Grads (a hundredth of a right angle) are still in widespread use in France; the surveying conventions for bearings have to be covered, and so on.

BTW, I can't recall the exact technique, but eXcel does have a rather neat way of switching between DMS and DD using Date functions! It's not what the functions are meant for, but it works.
 
..for example, Grads (a hundredth of a right angle) are still in widespread use in France...

At the risk of thread drift, interesting! Do you happen to know when Grads were introduced? I'm just wondering if it a relic of the French Revolutionary decimalisation?

We're told that "the revolutionary system was designed in part to remove all religious and royalist influences from the calendar, and was part of a larger attempt at decimalisation in France (which also included decimal time of day, decimalisation of currency, and metrication)"

Well, two hundred years later, two out of three ain’t bad?

It puzzles me why, if they had managed to decimalise the number of degrees in a right-angle (100 instead of 90), what did they do with longitude and latitude?

As for the number of days in a year, that couldn't (it seems) be decimalised, but the calendar could be. e.g. the French Republican Calendar: http://en.wikipedia.org/wiki/French_Republican_Calendar
 
At the risk of thread drift, interesting! Do you happen to know when Grads were introduced? I'm just wondering if it a relic of the French Revolutionary decimalisation?

We're told that "the revolutionary system was designed in part to remove all religious and royalist influences from the calendar, and was part of a larger attempt at decimalisation in France (which also included decimal time of day, decimalisation of currency, and metrication)"

Well, two hundred years later, two out of three ain’t bad?

It puzzles me why, if they had managed to decimalise the number of degrees in a right-angle (100 instead of 90), what did they do with longitude and latitude?

As for the number of days in a year, that couldn't (it seems) be decimalised, but the calendar could be. e.g. the French Republican Calendar: http://en.wikipedia.org/wiki/French_Republican_Calendar

Yes, it is indeed a relic of the Revolutionary revision of units of measure. It would also be convenient for navigation, because the original definition of the metre was a 10 millionth of the distance from the equator to the pole; a grad would therefore be equivalent to 100 km, in the same way that a minute of arc is 1 nautical mile. This foundered on the realization that the length of a meridian changed from the equator to the pole, because of the ellipticity of the Earth, but it was a nice idea! As far as I know, the grad is slowly dying out, but I think it still is used in surveying in France. If you want a rational measure of angle, the radian makes far more sense mathematically (there are pi radians in a circle, so a radian is 57.29......... degrees (like pi, it is an irrational number)). But radians aren't very convenient for everyday use!
 
If you want a rational measure of angle, the radian makes far more sense mathematically (there are pi radians in a circle, so a radian is 57.29......... degrees (like pi, it is an irrational number)). But radians aren't very convenient for everyday use!

I remember from cadets that the Army uses "mils" for angles, and a quick check of Wikipedia tells me that it's based on milliradians but approximated to a slightly easier number. It's all optimised for working out rifle and artillery ranges easily.

Pete
 
Certainly from a data management point of view that is the only way that makes sense. I have had to cope with systems where Degrees, Minutes and Seconds were stored separately, but it is clumsy and error-prone (especially when the data were stored in eXcel, with no validation possible!). There isn't an ISO representation for internal storage of angles; the ISO 19000 series of standards (which cover all geographic matters, and incorporate older standards like 6709) are purely about the exchange and specification of data, not internal representation.

How about the great 12o34'.56 vs 12o34.56' debate ... does ISO take a view on that?
 
There is no debate, the first is correct.

But says whom? All Wikipedia has to say on ISO 6709 (which it seems has been superseded) is

Representation at the human interface (Annex D)

When there is no guideline given from the user community, the following styles are suggested:

  • Coordinate values (latitude, longitude, and altitude) should be delimited by spaces.
  • The decimal point is a part of the value, thus must usually be configured by the operating system.[1]
  • Multiple points should be represented by multiple lines.
  • Latitude and longitude should be displayed by sexagesimal fractions (i.e. minutes and seconds).
  • When minutes and seconds are less than ten, leading zeroes should be shown.
  • Degree, minutes and seconds should be followed by the symbols ° (U+00B0), ' (U+0027), and " (U+0022), without spaces between the number and symbol
  • [...]


and the two red bits taken together suggest to me that 12o34.56' is correct. Apart from resistors I can't think of any other case where a unit is written inside the number and in this case it can lead to precisely the ambiguity which VicS pointed out.
 
How about the great 12o34'.56 vs 12o34.56' debate ... does ISO take a view on that?

Both are equally incorrect, as they are ambiguous and could be garbled in transmission. The first is definitely wrong because of the complete uncertainty about what exactly the ' sign refers to; the second because of the use of characters that can't be transmitted under some circumstances.

If you want unambiguous forms, then

DDD.DDDD
DDD MM.MMMM
DDD MM SS.SSSS
(the number of significant figures after the decimal point can be as many as you like)

with an appropriate sign convention are completely unambiguous in a data context. Adding degrees, minutes and seconds signs (which do not work in some contexts, such as baudot) is not necessary.

You shouldn't use °, ' or " because they can be garbled in transmission - indeed, someone viewing from an Apple machine will probably NOT see what I just typed, and vice-versa. Some types of transmission with a low number of bits (e.g. a 7-bit + parity RS232 line, or teleprinter Baudot (5 bits)) will also not correctly transmit these characters

To be absolutely compliant with ISO (ultimately with the Bureau International des Poids et Mesures, the governing body for SI units), the point should be a comma (which is the internationally agreed character for delimiting decimals), but because of the conventional use of a point in most English speaking countries, point is an allowed alternative. I had a long argument about that one once, when a purist tried to insist it had to be a comma! Unfortunately, in English the use of a comma for the decimal point can introduce its own set of ambiguities

Unlike dates, ISO only specifies a sexagesimal format for data transmission; it isn't meant to be used for human readable information, as it omits whitespace and any non-numeric characters. So, to answer your question, ISO remains silent on the issue! However, the forms I've suggested are robust and in widespread use.
 
To be absolutely compliant with ISO (ultimately with the Bureau International des Poids et Mesures, the governing body for SI units), the point should be a comma (which is the internationally agreed character for delimiting decimals), but because of the conventional use of a point in most English speaking countries, point is an allowed alternative. I had a long argument about that one once, when a purist tried to insist it had to be a comma! Unfortunately, in English the use of a comma for the decimal point can introduce its own set of ambiguities

Should your DDD.DDDD have been DDD.DDD D? I gave a talk recently after which a generally friendly member of the audience approached me to say that I really shouldn't have used "10,000,000,000,000" because the official form is "10 000 000 000 000". This sort of thing happens when your audience is all engineers!
 
But says whom? All Wikipedia has to say on ISO 6709 (which it seems has been superseded) is
Representation at the human interface (Annex D)

When there is no guideline given from the user community, the following styles are suggested:

  • Coordinate values (latitude, longitude, and altitude) should be delimited by spaces.
  • The decimal point is a part of the value, thus must usually be configured by the operating system.[1]
  • Multiple points should be represented by multiple lines.
  • Latitude and longitude should be displayed by sexagesimal fractions (i.e. minutes and seconds).
  • When minutes and seconds are less than ten, leading zeroes should be shown.
  • Degree, minutes and seconds should be followed by the symbols ° (U+00B0), ' (U+0027), and " (U+0022), without spaces between the number and symbol
  • [...]


and the two red bits taken together suggest to me that 12o34.56' is correct. Apart from resistors I can't think of any other case where a unit is written inside the number and in this case it can lead to precisely the ambiguity which VicS pointed out.

I'm a bit out of touch with the latest version, but please note that all of this is a recommendation only, and is not a normative (i.e. mandatory) part of the standard. However, what you typed is also incorrect because the essential point (the first above!) is that degrees, minutes and seconds are separated by spaces; it should be 12o 34.56'. The space is the essential part of the formatting; the degrees, minutes and seconds symbols are merely conveniences for human readability, and may be omitted as long as it is otherwise clear that the string represents an angular measurement.

I am sure that a browse through the "Instructions for Authors" of a few geographically alert scientific publications would be interesting!
 
Should your DDD.DDDD have been DDD.DDD D? I gave a talk recently after which a generally friendly member of the audience approached me to say that I really shouldn't have used "10,000,000,000,000" because the official form is "10 000 000 000 000". This sort of thing happens when your audience is all engineers!

In this case, I doubt it, because the use of space would make it ambiguous again (the space is the necessary separator between degrees, minutes and seconds). Commas (or spaces) to delimit thousands are not (AFAIK) a part of the BIPM number specification, and are deprecated, precisely because of ambiguities like this (comma would not work where comma is being used as the decimal separator; space doesn't work where space separates independent values). It's also an Anglophone/Francophone divide!
 
I'm a bit out of touch with the latest version, but please note that all of this is a recommendation only, and is not a normative (i.e. mandatory) part of the standard. However, what you typed is also incorrect because the essential point (the first above!) is that degrees, minutes and seconds are separated by spaces; it should be 12o 34.56'. The space is the essential part of the formatting; the degrees, minutes and seconds symbols are merely conveniences for human readability, and may be omitted as long as it is otherwise clear that the string represents an angular measurement.

The first one only says that coordinate values (latitude, longitude, and altitude) should be delimited by spaces. It doesn't say that spaces are needed within these, and although I agree it can help legibility, the symbols do delimit. That's in print ... I completely agree that one has to be very careful about using anything !isalnum() when doing things digitally

I am sure that a browse through the "Instructions for Authors" of a few geographically alert scientific publications would be interesting!

That's a good idea. This is an odd case because, thanks to SI, we generally only have one unit for each quantity (10kN, 15mm, 8T - or possibly 10 kN, 15 mm, 8 T) rather than the mix the imperialist have to put up with: stones and pounds, feet and inches.
 
In this case, I doubt it, because the use of space would make it ambiguous again (the space is the necessary separator between degrees, minutes and seconds). Commas (or spaces) to delimit thousands are not (AFAIK) a part of the BIPM number specification, and are deprecated, precisely because of ambiguities like this (comma would not work where comma is being used as the decimal separator; space doesn't work where space separates independent values). It's also an Anglophone/Francophone divide!

The Germans write 1.234.567.891,0111.213 which can be jolly confusing, particularly since a German 1 looks very much like our 7.
 
Top