Wikidata:Property proposal/planetary coordinates

planetary coordinates location edit

Originally proposed at Wikidata:Property proposal/Place

   Not done
Descriptioncoordinates of a location on an astronomical body other than Earth: a bot will set the globe based on the value of "located on astronomical location" (P376) statement. For coordinates on Earth, use P625. For celestial coordinates, see the property talk page
Data typeGeographic coordinates
Domainlocations on planets, their satellites, other astronomical bodies
Example 1Mare Tranquillitatis (Q320936) → 8°30'N, 31°24'E, globe: Moon (Q405)
Example 2Cleopatra (Q2545681) → 65°48'0"N, 7°6'0"E, globe: Venus (Q313)
Example 3Ptolemaeus (Q2886300) → 45°52'48"S, 202°24'0"E, globe: Mars (Q111)
Example 4Rimbaud (Q25908367) → 63°36'0"S, 148°49'48"W, globe: Mercury (Q308)
Example 5Aellopus Saxum (Q89208827) → 25°26'24"N, 335°40'12"E, globe: 101955 Bennu (Q11558) [currently appearing as located on Earth]
Example 6Strix Saxum (Q87349551) → 13°24'0"N, 88°15'36"E, globe: 101955 Bennu (Q11558) [currently appearing as located on Earth]
Planned usearrange for conversion of 7233 statements (see below)
See also

Motivation edit

It's still unclear why this should be mixed into WGS84 coordinates from Earth. Avoids users getting random locations when query earth P625 data without checking globe:
7233 of 8,264,173 statements are not about Earth.
Should we use the label "planetary coordinates" even if it's also used for (e.g.) lunar coordinates? (Add your motivation for this property here.) --- Jura 08:56, 10 October 2020 (UTC)[reply]

Some questions from discussion below
  1. what to do with celestial coordinates? (currently covered by separate properties, no development planned to include them in datatype)
  2. change usage of globe parameter (currently generally planet/body)
  3. make separate properties for other astronomical bodies that are frequently used (e.g. Moon)

--- Jura 09:31, 25 October 2020 (UTC)[reply]

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

  Notified participants of WikiProject Astronomy please help complete the proposal --- Jura 08:56, 10 October 2020 (UTC)[reply]

  Notified participants of WikiProject Space --- Jura 06:15, 11 October 2020 (UTC)[reply]

Discussion edit

  •   Comment see previous numerous discussions, in particular: Wikidata_talk:WikiProject_Astronomy#coordinate_locations_other_than_Earth (and also on Property_talk:P625). There is a lot of serious questions and problems to be solved before being able to create a new property so   Oppose for now. Cheers, VIGNERON (talk) 09:31, 10 October 2020 (UTC)[reply]
    • To speed it up, can you list the ones that still need to be addressed? --- Jura 09:37, 10 October 2020 (UTC)[reply]
      • Sure. Amongst many other point already raised (see the links): Why do we even need a new property? The current model doesn't seems broken (and if it ain’t broke, don’t fix it). What would be the the default globe for this property? (is it even possible to have a default globe other than Earth? and is there any chance that phab:T56097 would be solved soon? @Lydia Pintscher (WMDE): for these two points). Should we prefer planetocentric or planetographic coordinates? (difficult but probably worth to have one system only) What about celestial coordinates? Why planetary and not astronomical in the label? Any suggestions on constraints? Cheers, VIGNERON (talk) 10:06, 10 October 2020 (UTC)[reply]
        • I unfortunately don't know enough about the subject area to confidently spec out how the current datatype should be extended (or not depending on a few factors). If someone has time to sit down with me and talk it through for 30 mins we could make progress. Since I am not entirely sure how the end result should look like I can't yet tell how hard it would be.
        • I would also be interested in understanding roughly how many statements we're talking about that this would cover. --Lydia Pintscher (WMDE) (talk) 16:19, 13 October 2020 (UTC)[reply]
      • Ok, thanks for detailing the "lot of serious questions and problems". --- Jura 10:09, 10 October 2020 (UTC)[reply]
        • "Planeary" suggests coordinates with an origin at (or close to) the center of mass of the planet, and which move and rotate with the planet. "Celestial coordinates" would be the location of the planet in space, and the origin of such a system would usually be the center of mass of the solar system, or the center of mass of the Earth. "Astronomical" has a meaning when expressing latitude and longitude on Earth that might not apply to other bodies. Jc3s5h (talk) 13:58, 10 October 2020 (UTC)[reply]
  •   Question for the last step above ("notify users of Earth coordinates that they can simplify their queries/code"), do we have samples of uses that can be simplified, or all they all just hoping not to get locations on Mars, i.e. incorrectly not checking globe for Q2 or the absence of P376? --- Jura 10:07, 10 October 2020 (UTC)[reply]
  •   Question To make sure this covers all non-Earth current usecases of P625, please mention any samples this may have difficulties to cover (not sure if there could be any). Obviously, it doesn't aim to cover anything we can't currently do with P625. --- Jura 10:34, 10 October 2020 (UTC)[reply]
  • I think I might be more comfortable with a specific property for each "planet" we need them for. Maybe a generic property will eventually prove necessary, but there's only a handful right now that I think are relevant, right? There's no meaning to such coordinates on any of the gas giant planets (or the Sun, for instance). So - Mercury, Venus, Moon, Mars, maybe some moons of Jupiter and Saturn, and Pluto for now? No more than a dozen of them I expect. And the vast majority of interest at the moment I suspect are either Moon or Mars, so how about just 2 properties for those two to start with? ArthurPSmith (talk) 15:21, 12 October 2020 (UTC)[reply]
    • That could be an (additional) option. Currently that are just 40 globes, but most are from three (Moon, Mars, Venus). I added som stats above.
      If we leave in the others, the problem would still be that we have random non-Earth coordinates mixed into Earth ones. --- Jura 19:29, 12 October 2020 (UTC)[reply]
    • I suppose the underlying reasoning for having one property per planet is that rendering on maps is likely on a per planet basis too. --- Jura 19:42, 12 October 2020 (UTC)[reply]
  •   Oppose Unless we start having disputes about meridian lines again, I think coordinate location (P625) presents a reasonable solution for all planets at the moment, and creating new properties wouldn't improve the situation. I've been bold and changed phab:T56097 to 'high' priority, since being able to specify the planet in the UI seems rather important! Thanks. Mike Peel (talk)
    • Maybe in another 8 years, we can merge the properties back together. More seriously, I don't think the ticket solves much in relation to this proposal. --- Jura 19:32, 12 October 2020 (UTC)[reply]
  •   Comment maybe a question to ask would be if there is any advantage of including 8 non-Earth coordinates in 8000 Earth coordinates with the same property. --- Jura 11:30, 13 October 2020 (UTC)[reply]
  •   Support I didn't think of the asteroids we have geographic details for now too - Ceres, Eros, etc. Ok, I think that's a sufficient quantity that at least a temporary dedicated property for this is a good idea. How about calling it "off-Earth coordinate location" with a usage instruction that makes it clear the API needs to be queried to set and see the globe involved. ArthurPSmith (talk) 19:29, 13 October 2020 (UTC)[reply]
  •   Oppose hesitantly. The motivation as it stands is too weak. I doubt it will give structural clarity, and I think improving documentation is a better first step. "getting random locations" is merely a misunderstanding. IMHO the way of Wikidata is to have general properties and the combination of qualifiers and subject needs to be observed. I tried to come up with an equivalent example by saying "when getting a list of date of birth (P569) the results are not what I want. Some people are dead and there are horses in the list, I also didn't expect the Gregorian Calendar." The birthday example actually was brought up in 2013 together with coordinates. I don't think consensus changed for any of them. why this should be mixed Is the fact there are only a few horses a reason to de-generalize the property? this makes sense seems to be the implicit argument for the change. Assuming this to simplify queries is short-sighted. The bigger problem I see is if data is incorrectly entered into the database. Making a new property does not guarantee that there will be no instances where the coordinate location (P625) is mistakenly used for the wrong Globe (set or not set). Changing the way it has been defined for many years is more likely not changing the use unless it's strongly enforced. what are the ideas there? notify users of Earth coordinates I don't see the reason for them to change anything if it's working. But if you have a way to detect usage, why not contact those who query the property incorrectly? Jagulin (talk) 06:10, 14 October 2020 (UTC)[reply]
    • @Jagulin: I think people end up hard coding exceptions in all sorts of code to exclude non-Earth coordinates. P625 broke at WMF sites not too long ago, see phab:T210617 and if even WMF can't handle it correctly .. If we have a coordinates datatype for properties, this is to actually create several properties with the same datatype. The question is still if there are any cases where it's an advantage to have WGS84 and (e.g.) lunar coordinates in the same property. BTW, we also have birthday (P3150). --- Jura 06:23, 14 October 2020 (UTC)[reply]
  • I think that P625 shoud have a reference frame Q184876 which would be more useful than "globe" in that it specifies the definition of an origin that is used. See the reports of the IAU working group for an authoritative view on extraterrestrial body coordinates.[1] --Mu301 (talk) 13:29, 14 October 2020 (UTC)[reply]
  •   Comment I expanded the description of the property above. --- Jura 06:27, 15 October 2020 (UTC)[reply]
  •   Comment I don't understand the opposition here. This proposed property would be immediately used thousands of times - much more than many other properties we've created. And it would alleviate an obvious source of confusion with the existing property. As only roughly 1/3 or less of the usage would refer to any single celestial globe, it would be very different from the current property where 99.9% of usage is for Earth. Reuse would be easier; constraints would be simpler, etc. ArthurPSmith (talk) 16:35, 15 October 2020 (UTC)[reply]
  •   Oppose I prefer the uniform way in which coordinates on any body (and potentially in any coordinate system on any body) can be expressed with one property. See how the "coordinate system" / "body" is embedded in the value, with the default being a particular system on Earth:
  • select * where {
      values ?item { wd:Q1726 wd:Q487895 }
      ?item wdt:P625 ?coords .
    }
    
    Try it!
  • I'd be confused as user and tool writer if I had to remember to use a different property when switching from Earth to another object (or to another reference system on Earth). Toni 001 (talk) 17:23, 19 October 2020 (UTC)[reply]
    • Oddly, we couldn't yet identify such a tool on WMF sites, but see above for several cases of the opposite (tool writers assume all coordinates are on Earth). Besides, you already have to (see celestial coordinates mentioned above). --- Jura 09:21, 20 October 2020 (UTC)/09:31, 25 October 2020 (UTC)[reply]
  • I'm not an expert, but I just read chapter 10, "Physical Ephemerides of Solar System Bodies" in Explanatory Supplement to the Astronomical Almanac 3rd ed. (Q20668025). This gives detailed information on the coordinate systems for the Sun, all the planets, Ceres, and Pluto. I don't know how one goes about defining the prime meridian for a body like the Sun or Neptune, but astronomers do. For most dwarf planets, asteroids, and natural satellites, the radii are listed but other information that would be needed for a coordinate system is omitted (and is probably undefined for all but the largest asteroids), so for our purposes I think we can ignore most dwarf planets, natural satellites, and asteroids.
For each body, there are two kinds of coordinate systems, planetocentric coordinates and planetographic coordinates. Only for planetographic, a reference ellipsoid is defined to approximate the surface of the body. Both systems use the same north pole, equator, and prime meridian, but differ in how latitude is defined. In planetocentric, latitude is the equatorial plane and a line segment from the center of mass to the position of interest. For planetographic coordinates, latitude is the angle between the equatorial plane and a line segment that begins where the line segment passes through the equatorial plane, is normal to the ellipsoid, and ends where the line segment passes through the point of interest.
Planetocentric coordinates are used for general purposes. Planetographic coordinates are used for cartographic (that is, mapping) purposes. If I understand correctly, on Earth planetocentric coordinates are called astronomical, geographic, or terrestrial coordinates while planetographic coordinates are called geodetic coordinates. (See p. 22 and glossary of Explanatory Supplement to the Astronomical Almanac 3rd ed. Jc3s5h (talk) 15:19, 24 October 2020 (UTC)[reply]
  •   Comment Query Service supports globe for distance calculations. Supposedly it has some assumption about which type of coordinates is being used by default.
    Beyond that, we could try to use a better "globe" than the planet/astronomical body. --- Jura 09:31, 25 October 2020 (UTC)[reply]
So even WQS doesn't support the globe parameter very well and including random non-Earth coordinates in P625 isn't really an advantage. --- Jura 07:45, 5 November 2020 (UTC)[reply]
I would prefer different properties for each globe, to simplify queries and constraints. If we want to use P625, is it possible to add a qualifier to distinguish different globes? --Paperoastro (talk) 17:10, 10 November 2020 (UTC)[reply]