Jump to content

Wikifunctions:Type proposals/Position on Earth

From Wikifunctions

Summary

A normalised representation of lat/long for use in geospatial functions.

(This proposal overlaps with WF:Type proposals/Wikidata geocoordinates/phab:T391213, though it seems neither was aware of the other.)

Uses

(Humans and machines both like to know where places are, and using latitude and longitude is a versatile way to communicate location information.) A wide variety of software make use of geospatial co-ordinates directly, or indirectly via some location API/service.
There exists a co-ordinate pair type in Wikidata, and a compatible format is in use on Wikipedias.
While Wikifunctions is not capable of the number-crunching that some GIS software can do, there is value in implementing some simple algorithms using spherical geometry, like Z14446. For another example, a function which returned a list of local languages for the given position might be feasible to implement with some clever partitioning of the continents and a relatively small lookup table.

A reference geoid/ellipsoid would need to be chosenit would be prudent to use the same WGS84 standard as the aforementioned sister projects.
As co-ordinates can vary in their precision, it might be useful to capture a precision value in the representation.

The type could have an altitude component, but it would have to be optional as most applications elide it (because they're only concerned with what's on or very close to the surface). A reference for altitudes would also need to be chosen. [I was going to suggest "QNH" i.e. mean sea level as used in aviation, but a quick search suggests that's actually equivalent to WGS84. Also we probably want it in metres.]

Structure

A simple tuple of latitude, longitude[, altitude], and precision, being encoded with whichever numeric types are best suited for interoperability with Wikidata [not sure if that's floats or ints].

Validator

The validator ensures that:

  • −90° latitude 90°
  • −180° < longitude 180°
  • [limit on altitude]

Identity

Two positions are the same if the difference in lat/long[/alt] is within the larger of their respective precisions. [Assuming precisions are stored. If precisions are erased, simple memberwise equality.]

Converting to code

Python

As list of floats?

JavaScript

As array of Numbers?

Display function

dd.ddddd°N ddd.ddddd°E

(Wikidata displays in sexagesimal, and w:Template:Coord can display in either format. But unless the co-ordinates are stored as integers for degrees, minutes, and seconds, it's simpler to display in decimal degrees. I should also mention enwiki seems to favour sexagesimal for inputs to templates.)

Read function

/^-?\d{1,2}(\.\d{1,5})? -?\d{1,3}(\.\d{1,5})?$/ [require comma before space? introduces the classic decimal separator ambiguity]
OR
/^\d{1,2}(\.\d{1,5})?°?[NS] \d{1,3}(\.\d{1,5})?°?[EW]$/ (per display function)
OR
/^\d{1,2}°(\d\d[′'](\d\d(\.\d)?[″"])?)?[NS] \d{1,3}°(\d\d[′'](\d\d(\.\d)?[″"])?)?[EW]$/

Alternatives

  • In the case that Wikidata interop nudges us towards degrees, minutes, and seconds for the representationdon't do that and instead use decimal degrees, converting on import.
  • Use a pair of strings and push the problem of parsing and representation onto each Z14.
  • Use Wikidata references? [Could you construct a valid object which wasn't pulled from Wikidata? Not everywhere is a somewhere, so that will be necessary]
  • Alternate names for this type:
    • Co-ordinate pair, seems a bit too general
    • Location on Earth, suggests named places could be valid values

Comments