#758 strptime more amenable for celestial coordinates
Celestial coordinates have string representations similar to time variables. Thus with some tweaking it is possible to use strptime for making numerical values from string-formated coordinates. It is sort-of cumbersome with the current implementation of gstrptime though; that should not be a surprise, since gstrptime is aimed at regular date/time processing.
A patch with an altered gstrptime is attached. This allows +- signs in the strings and the hour part (that can play a role of angles) can be with up to 3 decimals (ecliptic/galactic longitudes are 0 to 360, or -180 to 180). Plus fractional parts for upper (hour/min) items are allowed too; the parser (have not altered it) stops on such upper fractional parts (that is not an issue for common situations) though.
My feeling is that this is a hack and some regular data types for celestial coordinates would be a more clean solution. Still this makes the current form more easily usable for the string-wise to numerical conversion regarding celestial angles.
I need help understanding what the target capabilities are. Is this to allow reading data in existing files? Is it for labeling graphs generated by gnuplot? Both? Can you give pointers to example data or example graphical output?
gnuplot's polar coordinate mode was extended in version 5.2 to handle one use of celestial coordinates. Is this a related use? I don't get where "hours" come in.
It sounds like what you want may be closer to the format options provided by the existing
"set tics geographic"
than it is to normal time/date formating. That mode does degrees/minutes/seconds with fractions allowed at any level.
So it may be that gnuplot can already do most or even all of what you want, but the terms used in the documentation may not be the terms you are used to so you don't find them.
Last edit: Ethan Merritt 2017-09-01
I've tried to look at the 5.2 manual, though still not sure whether the geo-related stuff does it. Generally it should not matter whether longitude/latitude data are related to the Earth surface or to something celestial.
The attachment shows at what the hour-like transformations are aimed.
I will look at this harder after 5.2 goes out. I think I'm still going to need some help understanding what is needed. The current geographic coordinates system was designed for lsbeling 2D maps. I'm not clear on what axis labeling is needed for 3D celestial coordinates.
Is "hour" in this system the same as "15 degrees", or is there more to it than that?
It is (mostly) just that. Notice that when the circumference is taken as having 360 degrees (instead of 24 hours), then unit of the upmost part is just "1 degree".
Here is a patch that implements something a bit different. I think it is useful in its own right but I am uncertain whether or not it provides what you need.
Gnuplot already supports relative time formats for ouput (axis labels, gprintf(), labels).
See "help time_spec examples".
The format specifiers %tH %tM %tS convert floating point seconds to hours/minutes/seconds. Negative values are preserved, and you can output fractional values instead of continuing the expansion. That is "%.3tH" will print the number of hours as a floating point number with the minutes+seconds contributing to the decimal part. These are processed similarly to geographic coordinates for axis labels ("help geographic") but are handled by the generic internal routine gstrftime() rather than the special-purpose routine gstrdms(). It might make sense to refactor the code so that the same routine is used for both purposes but let's set that aside for the moment.
Both the relative time formats and the geographic coordinate system are currently only implemented for output. This patch adds these same relative time formats to strptime(), making the input and output formats consistent. See example in comments at head of patch.
Where I get lost is that these relative time format specs can just as well handle degrees/minutes/seconds, by interpreting "%H" as the degree component. But you want "hour" to mean 15 degrees, not 1 degree, so maybe this conflicts with your intended use? I'm afraid the example you attached (celes.gnuplot) doesn't enlighten me because I don't know what the encoded number strings are intended to represent. Are these coordinates hours+minutes+seconds (where minute = 1/60 of an hour) or degrees+minutes+seconds (where minute = 1/60 or a degree) or some hybrid convention (hour = 15 degrees, minute = 1/60 degree)?
Last edit: Ethan Merritt 2017-09-05
Just've used your patch and it does what I want it to do. Thanks a lot.
I've updated the celes script for using these changes on rel-time strptime (see the "celes_new" attachment here).
If I encounter an issue (hoping that not) on this, I'll file a new ticket.
If I get it correctly, it is the opposite way (numerical to string) from what I am asking for (string to numerical).
Cool, that is exactly what I mean. I haven't yet used your patch; I'll let you know whether it provides the facilities in question once I set it in.
regarding DMS: 1D=1degree, 1M=1minute, 1S=1second
regarding HMS: 1H=15degrees, 1M=15minutes, 1S=15second
Thus going between their numerical values (the outputs here) is just multiplying/dividing by 15; see e.g. respective notices in WP: Notes, Symbols.
I've added this patch to 5.3 and queued it for inclusion 5.2 after it's had a trial.
I remain bemused by the ambiguity in "minutes" and "seconds". This must bedevil the field (or at least newcomers to it). Do you see value in teaching gnuplot about the conversion between the units of a 360° circle and a 24h circle? Where would this best be done? We currently have a command "set angle {degree|radians}". Would it make sense to add a third setting or is this better done at the input/output stage somehow. For that matter, is it a problem that the base units returned by the time formats are "seconds" rather than degrees so that it is always necessary to multiply by 3600.?
Regarding minutes/seconds: it is not specific to celestial coordinates.
(1) Consider the Earth and the common -180° to 180° denoting of longitude coordinates: here each degree has 60 minutes, thus 1 minute is 1/(360x60) of the whole circle. You can take these minutes/seconds as angle-wise.
(2) Then consider (proper) timezones that split the Earth onto 24 zones (when using 1-hour spacing). And if you want to make a finer-grained timezones, you can split each 1-hour timezone into 60 1-minute timezones. Since each hour has 60 minutes, you end up with 24x60 1-minute-based timezones overall for the Earth: thus corresponding angular size is 1/(24x60)-part of the whole circle for each minute here. These minutes are (originally) time-wise, but since they go around the Earth, they become angle-wise specifications too.
(3) If this is not enough, consider common watches/clocks where the whole circle is split into just 12 hours; here angular size of one minute is 1/(12x60)-part of the whole circle. That is even twice greater size than in the case based on finer-grained timezones!
In all the cases above, one minute is 1/60 of the respective top-level unit. Forcing all those ways for minutes to represent the same angular sizes would require to change the amount of minutes within one hour and/or within one degree. And it still would not be enough when considering hours over the Earth vs. on watches.
This brings us to the notion of time, and how it is taken in gnuplot: is it just 60 sec in 1 min and 60 min in 1 hour? No dealing with leap seconds? And if it considers the variation of rotation of the Earth and related time counting, do we deal with UTC, TAI, TT? Probably not going into Julian days, epochs, equinoxes, etc. here.
The main thing is that if the time-dealing in gnuplot should start to consider the departures from the simple 24x60x60 counting we would need to distinguish the dealing with coordinates from it. Well, they are related (meaning the directions of the Earth at particular times, and resulting variations in the transformations of coordinate systems related to Earth vs. related e.g. to Galaxy), but the relationship is involved by itself.
As for me, my current needs for coordinates within gnuplot are satisfied by the last patch you did. I am not sure what I'll ask for next time; besides having HMS/DMS not affected by leap seconds, obviously. May be that you should ask at a greater community (than one-guy community), e.g. at the Astropy community. I can imagine that questions on Mollweide and other projections could come out.