Wikidata:Property proposal/Astronomical coordinates

From Wikidata
Jump to navigation Jump to search

Astronomical coordinates[edit]

right ascension[edit]

Originally proposed at Wikidata:Property proposal/Natural science

DescriptionRight ascension
Representsright ascension (Q13442): astronomical equivalent of longitude
Data typeQuantity
Example 1Andromeda (Q2469) → 10.684793 degree (Q28390)
Example 23C 273 (Q229318) → 187.277915 degree (Q28390)
Example 3Orion Nebula (Q13903) → 83.818662 degree (Q28390)
Planned useIn infobox templates on enwp and commons
Expected completenessalways incomplete (Q21873886)

declination[edit]

   Done: declination (P6258) (Talk and documentation)
Descriptiondeclination of an astronomical object
Representsdeclination (Q76287): astronomical coordinate
Data typeQuantity
Example 1Andromeda (Q2469) → 41.269065 degree (Q28390)
Example 23C 273 (Q229318) → 2.052388 degree (Q28390)
Example 3Orion Nebula (Q13903) → -5.389679 degree (Q28390)

epoch[edit]

   Done: epoch (P6259) (Talk and documentation)
Descriptionepoch of an astronomical object coordinate
Representsepoch (Q2703): moment in time used as a reference point for some time-varying astronomical quantity
Data typeItem
Example 1Andromeda (Q2469)J2000.0 (Q1264450)
Example 23C 273 (Q229318)J2000.0 (Q1264450)
Example 3Orion Nebula (Q13903)J2000.0 (Q1264450)

galactic longitude[edit]

DescriptionGalactic longitude of an astronomical object
Representsgalactic longitude (Q3836656): no description
Data typeQuantity
Example 1SN 1987A (Q584905) → 279.7 degree (Q28390)
Example 2Crab Pulsar (Q1044623) → 276.366786 degree (Q28390)
Example 3Orion Nebula (Q13903) → 209.010797 degree (Q28390)

galactic latitude[edit]

DescriptionGalactic latitude of an astronomical object
Representsgalactic latitude (Q2839478): no description
Data typeQuantity
Example 1SN 1987A (Q584905) → -31.9 degree (Q28390)
Example 2Crab Pulsar (Q1044623) → 22.8683 degree (Q28390)
Example 3Orion Nebula (Q13903) → -19.383934 degree (Q28390)

Motivation[edit]

We need to store astronomical coordinates to provide the location on the sky for astronomical objects (and to display those coordinates in astronomical infoboxes). This is a long-running issue, the earliest record I can spot of this date back to 2013. It's tracked by phab:T127950. The ideal solution is to store the coordinates in the same way that we do for those on Earth, through a property like coordinate location (P625).

However that does not look likely to happen in the near future. The interim alternative is to have 5 properties that hold the basic information - either the RA, Dec and epoch, or the Galactic longitude and latitude. These can be automatically moved over to a better solution in the future when it's available in the software.

Something similar to this was proposed at Wikidata:Property_proposal/Archive/46#Right_Ascension_/_Declination_/_Distance - the distance was later added as distance from Earth (P2583), but the RA/dec aren't yet available. The arguments for being able to input this as hours/minutes/seconds and degrees/minutes/seconds are valid, but that functionality isn't yet available, and we can reformat the units from degrees to hms/dms in code for now in order to display them in the infoboxes.

Thanks. Mike Peel (talk) 22:52, 1 December 2018 (UTC)[reply]

Discussion[edit]

Arlo Barnes Athulvis Buller1 cdo256 Cekli829 Harlock81 Jc3s5h JenlovesbigD J. N. Squire Jura1 Kepler-1229b LiMr Manlleus Meodudlye, with only limited amount of time to spend in the foreseable future. Mike Peel mu301 (mikeu) Paperoastro Path slopu Ptolusque Romuald 2 Sarilho1 Sherman Alexander Shisma Simon Villeneuve SM5POR Tom.Reding VIGNERON Wallacegromit1 - generally like to add ground and space observatory instrument data Ysogo Jck1337

Notified participants of WikiProject Astronomy Thanks. Mike Peel (talk) 12:12, 3 December 2018 (UTC)[reply]

@Mike Peel: I indeed remember (vaguely) some discussions about simply using coordinate location (P625), but why has it been dismissed? Why do you say « that does not look likely to happen in the near future »? I'm not sure to understand what prevent you to using it right now? (sure changing the globe is not easy - you need to use raw tools like the API or CLI - but we manage to do it already, see all features on Mars for instance). VIGNERON (talk) 12:55, 3 December 2018 (UTC)[reply]
@VIGNERON: I can't see that coordinate location (P625) supports which globe it is specified on, e.g. at Olympus Mons (Q520)? It also needs to support different coordinate systems, both for different en:Equinox (celestial coordinates) and for different rotations, e.g. see galactic coordinate system (Q385487), which doesn't seem to be possible? Nothing seems to have happened on the Phabricator ticket in over 18 months (maybe @Lydia Pintscher (WMDE): can comment on this?). Thanks. Mike Peel (talk) 13:38, 3 December 2018 (UTC)[reply]
Yeah unfortunately I don't have anyone who can put time into improving/enhancing that currently :( --Lydia Pintscher (WMDE) (talk) 20:17, 5 December 2018 (UTC)[reply]
@Mike Peel: you can't see it in the interface (which is a problem) but it's definitely there, see it many way, the link is pointing to https://tools.wmflabs.org/geohack/geohack.php?params=18.65_N_226.2_E_globe:mars&language=fr or see this query for instance.
Do you really need a new datatype? (which is a big deal and could take months if not years) ascension is longitude and declination is latitude. I may be mistaken but every other formats can then be calculated, no need to store more than necessary in Wikidata.
Cheers, VIGNERON (talk) 14:05, 3 December 2018 (UTC)[reply]
@VIGNERON: The ideal is recording the coordinate data in the original format it was published in, and then doing conversions later. If we had to stick with just J2000.0 and convert from B1950 etc. then that might work, though. Using J2000.0 vs. Galactic coordinates is more complex, as that systematically differs whether it's a Galactic or extragalactic source that's being talked about. In this proposal, I'm not suggesting a new datatype, but that would probably be preferable in the long run. If what I'm proposing can already be done with coordinate location (P625), can you go ahead and demo that at Andromeda (Q2469) with the values given above, or those at [1]? Thanks. Mike Peel (talk) 15:34, 3 December 2018 (UTC)[reply]
@Mike Peel: the ideal is to allow to enter in the original format, I see no reason to record it in this format (obviously, considering that the transformation from one format to an other is possible and lossless).
For M31, you have 3 formats : ICRS, FK4, Gal that are exactly equivalent (I used this Javascript Astronomical Coordinate Converter to verify]). The last one is in degree which is what is expected by coordinate location (P625) (and epoch could be put as qualifier, probably with a new specific property or simply with determination method (P459)). Is there something wrong with my reasoning? (if not, I'll try to add with CLI in the next days).
Cheers, VIGNERON (talk) 17:39, 3 December 2018 (UTC)[reply]
degrees can't be >180. There is a bug report about this but apparently it's not something WMDE will be doing. --- Jura 17:45, 3 December 2018 (UTC)[reply]
@Jura1: are you sure ? See Q520#P625 (18° N 226° E) or test on Wikidata Sandbox 2 (Q13406268), degrees can be > 180°. Cheers, VIGNERON (talk) 07:47, 4 December 2018 (UTC)[reply]
Good point. https://phabricator.wikimedia.org/T127950 actually mentions another problem. The questions is if the entire output (rdf/sparql) is consistent for the above. --- Jura 05:39, 7 December 2018 (UTC)[reply]
@ArthurPSmith, Paperoastro, Manlleus, Jura1: « this can't be done » but what is wrong with what I've done on Andromeda (Q2469) Special:Diff/804683526? Cheers, VIGNERON (talk) 08:02, 4 December 2018 (UTC)[reply]
@VIGNERON: Look at the item in the Wikidata UI, there's no indication that "celestial sphere" is the reference for the coordinates, and J2000.0 as "determination method" raises a constraint violation flag. ArthurPSmith (talk) 18:43, 4 December 2018 (UTC)[reply]
@ArthurPSmith: yes, it's already established that the UI is crap for this, there is always a globe but there is never the indication of the globe (same goes for the thousands of extraterrestrial features, again qv. Olympus Mons (Q520) or the 1975 items on Venus (Q313), the 1961 on Moon (Q405) or the 1937 on Mars (Q111), and technically same goes for Earth, in the absolute there is no reason to be geocentric). But that doesn't mean that the globe is not stored nor accessible (for an infobox for instance), and the context is pretty obvious too: nobody will seriously think that a galaxy is located on Earth, like nobody thinks that Olympus Mons (Q520) is on Earth even if the globe is not displayed. If it works for celestial bodies, why not for the celestial sphere?
Anyway, my point is a proof of concept : it's technically possible. Now the next question is: is it desirable? Should we create new separate properties (and the structure to go with it) or use an existing property and improve the UI (which seems easier to me in the long run).
PS: for determination method (P459) as qual, yes an epoch qual could be useful (see my vote infra).
Cheers, VIGNERON (talk) 18:56, 4 December 2018 (UTC)[reply]
@VIGNERON: This approach could work. Is it possible to set globe=celestial sphere (Q12134)? It seems that I can set the globe using pywikibot, but while it works for Mars (Q111) it doesn't seem to for celestial sphere (Q12134). Thanks. Mike Peel (talk) 20:18, 4 December 2018 (UTC)[reply]
@Mike Peel: I don't know for pywikibot but it worked with wikidata-cli, as you can see on the summary of this diff Special:Diff/804683526, the globe is clearly indicated (the UI is not totally useless ;) ). Cheers, VIGNERON (talk) 21:16, 4 December 2018 (UTC)[reply]
Aah, I see. I was looking at the geohack URL, which shows up as https://tools.wmflabs.org/geohack/geohack.php?params=21.174322_N_-21.573311_E_globe:undefined&language=en - but I guess that's a bug with the geohack link rather than Wikidata. Thanks. Mike Peel (talk) 21:25, 4 December 2018 (UTC)[reply]
Using globe=celestial sphere (Q12134), could be work: declination is as latitude; right ascension is as longitude with Lon = RA*15. This could be solve the quiestion... --Paperoastro (talk) 22:49, 5 December 2018 (UTC)[reply]
There is (or was a) bot that sets the globe if located on astronomical body (P376) is present. Maybe it just needs to be expanded. --- Jura 05:39, 7 December 2018 (UTC)[reply]
If there is, that sounds useful (if not, it should be straightforward for me to write one).
Overall, this looks like a workable system. My main worry now (apart from the globe not displaying) is how to deal with Galactic coordinates. Those are a bit different as they are always displayed in degrees (never hours/minutes/seconds). So maybe they still need new properties, along with epoch, and I can just withdraw the RA/Dec property proposals. Thoughts @VIGNERON and all? Thanks. Mike Peel (talk) 09:57, 7 December 2018 (UTC)[reply]
@Mike Peel: the bot is LocatorBot by Laboramus and is still active (see this diff Special:Diff/803717877 5 days ago).
Yes, P625 seems workable or at the very least, the coordinates datatype seems workable. Maybe we could have a unique property Astronomical coordinates with the globe set to celestial sphere (Q12134) by default (@Lydia Pintscher (WMDE): would it be possible?) as a workaround the UI not being able to select the globe.
Cdlt, VIGNERON (talk) 11:30, 7 December 2018 (UTC)[reply]
@VIGNERON: I just found a new problem: astronomical coordinates always use the convention of longitude then latitude, but coordinate location (P625) assumes latitude and then longitude. Going for separate properties might be the easiest option for now, until all of this can be sorted out. Thanks. Mike Peel (talk) 22:39, 10 December 2018 (UTC)[reply]

@J. N. Squire, ArthurPSmith, Mike Peel, Paperoastro, Jc86035, RexxS: @Pintoch, VIGNERON, Lydia Pintscher (WMDE), Manlleus, Jura1: ✓ Done: right ascension (P6257). − Pintoch (talk) 20:46, 16 December 2018 (UTC)[reply]

Thanks. I modified the example of Andromeda (Q2469) using epoch (P6259) as qualifier. --Paperoastro (talk) 21:30, 16 December 2018 (UTC)[reply]