It needs to be decided if this will actually be implemented with three separate fields for each angle (degrees, arcminutes, and arcseconds of declination and hours, time minutes, and time seconds of right ascension) or if a single decimal number will be used for each angle. I suggest it should not be a goal of this support to allow a round-trip conversion, but rather, to approximate the precision of the source in the manner usually followed by engineers and scientists. For example, if a source gave a R.A. as 3h 10m, but the implementors decided to store it as decimal hours, it should be stored as 3.17 h to reflect the precision of the source, not as 3.16666666666667 h or the like. If a data consumer were to convert 3.17 h back to h m s, he/she would get 3 h 10 m 12 s, and the responsibility would be on the data consumer to realize that the value was only given to three significant figures and so 3 h 10 m 12 s should be rounded to 3 h 10 m.

If we are storing decimal numbers, we should use significant figures and rounding in the manner customary among scientists and engineers. If our goal were to perfectly represent the source, we would keep it as an arbitrary string, but then we wouldn't be able to do computation with it.

This was created after a question at https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2016/02#Celestial_coordinates
I also just came across https://www.wikidata.org/wiki/Wikidata:Contact_the_development_team/Archive/2013/09#Celestial_coordinate_system and found a mention of celestial coordinates on T56097.

Regarding Lydia's question on the first link. I think it can't be done satisfactorily by simply using the existing coordinates implementation with a different globe because of the different expectations for inputting/outputting values, but it seems like it could probably be done by extending the existing coordinates support. The things I can see that are clearly missing are:

• support for inputting values in the expected format
• support for outputting values in the expected format
• support for changing the globe (T56097)
• an agreement on what to use as a globe

I'm not an expert on the subject though, so maybe I'm missing something. :)

On a related note, https://en.wikipedia.org/wiki/Template:Infobox_supernova includes Galactic coordinates (e.g. https://en.wikipedia.org/wiki/SN_1885A). As I understand it, those use a system with 0° to 360° for longitude and 90° to -90° for latitude - closer to geographic coordinates but still with different expectations for input/output.

I have edited the description. It is not useful to record the positions of objects within the solar system (Moon, Saturn, etc.) in WikiData because they change too rapidly. The kind of objects which would have position information stored in WikiData would be stars, quasars, pulsars, galaxies, and the like. The kind of objects and the kind of data available for them can be explored at the US Naval Observatory's NOMAD catalog.

Modern star catalogs use the International Celestial Reference System. Except for the most accurate data, this is equivalent to a system centered on either the barycenter of the solar system or the center of the Sun, using the equator and equinox of J2000.0 (a date close to the beginning of the year 2000).

Maybe this can also help users from Mainland China a lot, as their map service sites are generally using GCJ-02/BD-09 rather than WGS-84

Probably should have posted this here rather than there:

In T56097#3158347, @Mike_Peel wrote:

@Lydia_Pintscher Looking through this after our discussion today, @bzimport's comment above about the needs for astronomy looks good. RA, dec and epoch, e.g. see the values in the infobox at https://en.wikipedia.org/wiki/SN_1987A . Support for other astronomical coordinate systems (such as Galactic coordinates) would also be good, but that can be done later (and possibly by auto-converting them) - for now, just supporting equatorial coordinates would be incredibly useful for the work I'm doing with astronomical infoboxes.

Regarding precision, I think Wikidata is already doing some such recording for Earth geographic coordinates. That should be applicable to celestial coordinates.

In T127950#3123960, @Liuxinyu970226 wrote:

Maybe this can also help users from Mainland China a lot, as their map service sites are generally using GCJ-02/BD-09 rather than WGS-84

No matter how much GCJ-02 and BD-09 obfuscates on WGS84, they still refer to the Earth, not the Heavens. (We do refer to scribbled unrecognizable stuff as "heavenly text" (天书) in Chinese though. Ha!) If anything were to be done for these things, these obfuscated stuff should become temporary (say, normalized immediately after submission by bot) for input and auto-generated for output. They hold little value as internal representations.

For the record, last December after https://www.wikidata.org/wiki/Wikidata:Property_proposal/Astronomical_coordinates, I added celestial coordinates on M31: https://www.wikidata.org/wiki/Q2469#P625 (2 months later nobody seems to complain)

So, I'm not sure we need a new datatype, but even with the existing coord datatype the interface definitely need some work (as well as Geohack), at the very least the possibility to select the globe and formatting.

This task was mentioned in the Bug Triage Hour at the Wikidata Data Quality Days 2022.