Wikidata

Wikidata:Property proposal/Coordinate reference system

< Wikidata:Property proposal

coordinate reference system edit

Originally proposed at Wikidata:Property proposal/Place

   Not done
Descriptioncoordinate (or spatial) reference system used to determine the coordinates of a location on Earth (default: WGS84) or some other globe
Representsspatial reference system (Q161779)
Data typeItem
Domaincoordinates on earth or any planet or natural satellite
Allowed valuesinstances of spatial reference system (Q161779)
Example
Motivation

I thought we had a property for this for use a qualifier with coordinate location (P625), but it seems that we do not. Strictly speaking, coordinates - even on Earth - are meaningless without knowing the coordinates referencing system (CRS, also known as "spatial reference system" or "reference frame", see also geodetic reference system (Q1502887)) used - the usual one for coordinates on Earth is World Geodetic System 1984 (Q11902211) but one or more versions of each of International Terrestrial Reference System (Q74561), North American Datum (Q993433) and European Terrestrial Reference System 1989 (Q1378197) also exist, for example. The importance of specifying the reference system can be seen from [2], which gives several coordinates on the moon, and says "Differing results come from different models with different solutions. Currently, the lunar geoid is being redefined with Clementine data, so the location (latitude, longitude, and elevation) of everything will change again very soon. In short, we know where each of the [Lunar Modules] is located is relation to local landmarks; but assignment of latitude and longitudes to those locations is an evolving process.". Geo URI (Q5533943), for example, incudes a parameter for the CRS, see en:Geo URI scheme#Coordinate reference systems.

It may be assumed that, where not stated, the CRS for coordinates on Earth is WGS84, as that is used by most online mapping systems, GPS devices, and by the various WMF projects' mapping services. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:37, 9 January 2017 (UTC)[reply]

Discussion

Happy to agree to this proposal. I understand that this will provide a link to an existing standard. Well done. Thanks, GerardM (talk) 14:22, 10 January 2017 (UTC)[reply]

I support the proposal and offer Washington Monument (Q178114) as an example. The most accurate value may not be stated in WGS84. The most desirable outcome would be to transform the coordinates into WGS84, or the nearly identical ITRF. The available qualifiers to specify that this was done, and how it was done, are sparse. The determination method property could be used to specify that a transformation was performed, and the proposed property could be used to state what coordinate system the value was transformed into. The untransformed value, of course, would be found in the referenced source. (An editor who won't be bothered referencing the source has no business transforming coordinates.) Jc3s5h (talk) 18:10, 10 January 2017 (UTC)[reply]

On further reflection, I think the user interface should be corrected to permit entry of the globe, and display whatever globe was chosen. Ideally editors would transform the value as necessary to ITRF or WGS84 and specify one of those as the globe, but if the editor didn't now how, they could specify whatever globe was used and leave it for a subsequent editor to do the transformation. It could also allow the entry of coordinates for features on other planets to be made through the user interface. Jc3s5h (talk) 18:29, 10 January 2017 (UTC)[reply]

Is there a Phabricator ticket for this proposed change to the interface? And an ETA for delivery? How does the later compare to the potential for having the proposed proerty in place in seven days or so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:48, 10 January 2017 (UTC)[reply]
If the property is approved, what would your plan be to undo all the non-Earth globe fields that already exist, and remove globe from the data model (which, in the case of JSON, itself requires a Phabricator ticket)? Jc3s5h (talk) 22:09, 10 January 2017 (UTC)[reply]
I would do neither. For several globes, as well as Earth (e.g. Moon, Mars) there is more than one CRS. For each, we can assume or declare a default, but this proposal allows the specification of another. This proposal is not mutually exclusive with yours, and yours is not a reason not to do this. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:14, 10 January 2017 (UTC)[reply]
I have created a Phabricator ticket in line with my response above, but it turns out there was already a Phabricator on the issue. Jc3s5h (talk) 22:30, 10 January 2017 (UTC) updated 11:48 11 January 2017 (UTC)[reply]
Tracked in Phabricator
Task T56097
  •   Comment, not sure if it should be a property or not… Embedding the coordinate system in the coordinnates, like it's done for the globe, would probably be better but as the globe is still not implemented in the interface right now (and it's causing several problems, like people adding earthly coordinate outside of Earth), I'm reluctant and hesitant. Cdlt, VIGNERON (talk) 10:58, 11 January 2017 (UTC)[reply]
  •   Comment The more I think about it, the less happy I am with this proposal. For much of the 20th century, latitudes and longitudes in the UK were stated with reference to OSGB36 -- typically this gives a point on the ground about 100 to 150 metres away from where WGS84 would indicate. I am not at all happy with the thought of OSGB36 coordinates being used with P625, even when marked with a qualifier. I think we should maintain an insistence that all terrestial coordinates are converted to WGS84, so that this is the only scheme for terrestial coordinates that is acceptable as an argument for P625. Otherwise we are demanding that any use of P625 data must check the qualifiers and must be prepared to do coordinate conversions. As well as being a complete millstone, it's simply not realistic to expect this of data users. Most SPARQL searches don't even check qualifiers at all.
Instead I could see value in a qualifying the data with a qualifier "originally stated as" + a qualifier "original coordinate system", if we want to record how the data may have been originally presented in a given source. Jheald (talk) 21:56, 22 January 2017 (UTC)[reply]
  •   Support This would help phab:T162331 a lot too. --Liuxinyu970226 (talk) 14:49, 11 May 2017 (UTC)[reply]
    • I object to taking such devices for map censorship (GCJ02 (Q29043602), BD09 (Q29043632)) seriously and making them acceptable for P625. These things are designed out of bad faith (creating drifts) and not numbered by ESGI; GCJ-02 in particular has the laughable error of using SK-42 ellipsoid for drifting WGS-84 input. They should be shot – rectified, I mean – on sight (um, input?). It's terrible to think about complicating queries for just these two bad things. --Artoria2e5 (talk) 18:08, 25 August 2017 (UTC)[reply]
  •   Oppose Better to fix the bug Liuxinyu brought up on our end than to force others who use Wikidata to account for differing Earth geo-coordinates on their end. Mahir256 (talk) 20:49, 25 August 2017 (UTC)[reply]
    • Given that the proposal includes examples of lunar and Martian coordinates, your comment, and its basis in "differing Earth geo-coordinates", gives me concern that you may not have read it. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:36, 26 August 2017 (UTC)[reply]
      • @Mahir256: This proposal per se is about easily inputting some older geodata not yet transformed to WGS84, not the terrible screw-ups Liu brought up. On another thought though, if this property is made to "rectify to WGS84 immediately by a patrolling bot", it may ease the workload on human users. Just don't keep data marked with it for long-term use… --Artoria2e5 (talk) 15:02, 26 August 2017 (UTC)[reply]
      • @Pigsonthewing: The general concern in the comment that I had was one of lack of standardization. You can replace Earth in that comment with any other celestial body; we should be assuming a standard coordinate system for each celestial body just as we do with WGS84 for Earth on Wikidata. (In fact, I'm sure the appropriate coordinate system can be readily assumed depending on the item in question.) There is no benefit to having multiple versions of the same coordinates for the Moon, or Mars, or any other such body (except in the random case where a location can't be expressed in one system but can in another), just as we don't need WGS84, GCJ-02, and BD-09 coordinates for locations on Earth in the same item. Instead there should be conversion tools for these as discussed (for Earth) in the ticket Liuxinyu linked to. Mahir256 (talk) 20:56, 26 August 2017 (UTC)[reply]

I've marked this as ready, on the basis that one objector has not responded to a request for clarification, and the other appears to heve misread this as being only about coordinates on Earth. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:46, 4 October 2017 (UTC)[reply]

  Notified participants of WikiProject Space ChristianKl (✉) 18:10, 26 November 2017 (UTC)[reply]

Marking this as not done as no consensus was reached. − Pintoch (talk) 12:51, 8 February 2018 (UTC)[reply]
Retrieved from "https://www.wikidata.org/w/index.php?title=Wikidata:Property_proposal/Coordinate_reference_system&oldid=628499982"