Wikidata:Property proposal/Astronomical coordinates
Astronomical coordinates
[edit]right ascension
[edit]Originally proposed at Wikidata:Property proposal/Natural science
Description | Right ascension |
---|---|
Represents | right ascension (Q13442): astronomical equivalent of longitude |
Data type | Quantity |
Example 1 | Andromeda Galaxy (Q2469) → 10.684793 degree (Q28390) |
Example 2 | 3C 273 (Q229318) → 187.277915 degree (Q28390) |
Example 3 | Orion Nebula (Q13903) → 83.818662 degree (Q28390) |
Planned use | In infobox templates on enwp and commons |
Expected completeness | always incomplete (Q21873886) |
declination
[edit]Description | declination of an astronomical object |
---|---|
Represents | declination (Q76287): astronomical coordinate |
Data type | Quantity |
Example 1 | Andromeda Galaxy (Q2469) → 41.269065 degree (Q28390) |
Example 2 | 3C 273 (Q229318) → 2.052388 degree (Q28390) |
Example 3 | Orion Nebula (Q13903) → -5.389679 degree (Q28390) |
epoch
[edit]Description | epoch of an astronomical object coordinate |
---|---|
Represents | epoch (Q2703): moment in time used as a reference point for some time-varying astronomical quantity |
Data type | Item |
Example 1 | Andromeda Galaxy (Q2469) → J2000.0 (Q1264450) |
Example 2 | 3C 273 (Q229318) → J2000.0 (Q1264450) |
Example 3 | Orion Nebula (Q13903) → J2000.0 (Q1264450) |
galactic longitude
[edit]Description | Galactic longitude of an astronomical object |
---|---|
Represents | galactic longitude (Q3836656): no description |
Data type | Quantity |
Example 1 | SN 1987A (Q584905) → 279.7 degree (Q28390) |
Example 2 | Crab Pulsar (Q1044623) → 276.366786 degree (Q28390) |
Example 3 | Orion Nebula (Q13903) → 209.010797 degree (Q28390) |
galactic latitude
[edit]Description | Galactic latitude of an astronomical object |
---|---|
Represents | galactic latitude (Q2839478): no description |
Data type | Quantity |
Example 1 | SN 1987A (Q584905) → -31.9 degree (Q28390) |
Example 2 | Crab Pulsar (Q1044623) → 22.8683 degree (Q28390) |
Example 3 | Orion 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)
Discussion
[edit]Notified participants of WikiProject Astronomy Thanks. Mike Peel (talk) 12:12, 3 December 2018 (UTC)
- @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)
- @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)
- 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)
- @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)
- @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 Galaxy (Q2469) with the values given above, or those at [1]? Thanks. Mike Peel (talk) 15:34, 3 December 2018 (UTC)
- @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 or standard (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)
- 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)
- @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)
- 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)
- @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)
- 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)
- @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 Galaxy (Q2469) with the values given above, or those at [1]? Thanks. Mike Peel (talk) 15:34, 3 December 2018 (UTC)
- As this can't be done with coordinates-datatype, the above seems to be a possible approach. --- Jura 15:56, 3 December 2018 (UTC)
- @ArthurPSmith, Paperoastro, Manlleus, Jura1: « this can't be done » but what is wrong with what I've done on Andromeda Galaxy (Q2469) Special:Diff/804683526? Cheers, VIGNERON (talk) 08:02, 4 December 2018 (UTC)
- @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)
- @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 or standard (P459) as qual, yes an epoch qual could be useful (see my vote infra).
- Cheers, VIGNERON (talk) 18:56, 4 December 2018 (UTC)
- @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)
- @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)
- 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)
- 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)
- @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)
- 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)
- 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)
- @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)
- @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)
- @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)
- @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)
- Probably Support for Epoch as this is not really a part of the coordinates, it would be useful whatever the solution chosen. Cdlt, VIGNERON (talk) 17:43, 3 December 2018 (UTC)
- Support all until we have celestial coordinates or a more general coordinate datatype supported in Wikidata. @Mike Peel: note that Wikidata property labels in English are generally lower-case unless they correspond to a proper name. ArthurPSmith (talk) 19:16, 3 December 2018 (UTC)
- Support It is a very old question: see also [2]. Epoch can be a qualifier. --Paperoastro (talk) 22:38, 3 December 2018 (UTC)
- Support to all. We need celestial coordinates but what we have can do the work for now.--Manlleus (talk) 00:01, 4 December 2018 (UTC)
- Comment is there a way to group them? It would be good if we had just one statement for coordinates that uses the above as qualifiers. It could be (e.g) "has quality: astronomical coordinates" or a statement with a more specific property. Even one coordinate as qualifier, the other as main value could work. --- Jura 05:40, 4 December 2018 (UTC)
- Comment Just to briefly note that in Lua it's quite straightforward to return the globe's value or entity-id from coordinate location (P625) (see en:Module:wikidataIB getGlobe). It would obviously be helpful if the interface here allowed that value to be edited, but that's not a prerequisite for making use of the globe in infoboxes, for example. --RexxS (talk) 03:05, 5 December 2018 (UTC)
- Support, since the software solution is evidently not going to happen for quite a while. Jc86035 (talk) 10:18, 5 December 2018 (UTC)
- Support Since developers are not interested by working on software implementation of celestial coordinate systems for now. J. N. Squire (talk) 16:06, 5 December 2018 (UTC)
- @Mike Peel: To get these properties created, both labels and descriptions should be provided for all properties. I will not create these properties until these conditions are met. − Pintoch (talk) 08:36, 16 December 2018 (UTC)
- @Pintoch: Is this better now? If not, please advise / point to an example and I can make more changes as needed. Thanks. Mike Peel (talk) 17:58, 16 December 2018 (UTC)
@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)
- Thanks. I modified the example of Andromeda Galaxy (Q2469) using epoch (P6259) as qualifier. --Paperoastro (talk) 21:30, 16 December 2018 (UTC)