ON COORDINATES: a) what you describe is more specific than a geolocation (which may be expressed by other means than coordinates). I suggest to give the data type the more specific name: geocoordinates b) with respect to precision: I don't understand the reasoning to stick this to degrees. Since we are describing locations on an ellipsoid, the longitude to distance and latitude to distance conversions are different, and they are different for different points on earth. See example on en.wikipedia, a minute at equator is 1843 versus 1855 m. In practice the potential location error will be given in a distance measure. You want to convert it to degrees in a highly complex conversion. Why? The back conversion will usually be non-ambiguous (since the backconversion will always describe an ellipsis rather than a circle). c) Furthermore, as before, I believe that precision and accuracy will usually both contribute to the error your are interested in and which is typically described in geolocations having a +/- addition. I suggest to replace precision with errorradius or uncertaintyradius or uncertaintyInMeters which would be the great circle distance. To somewhat simplify, the unit could be fixed to m. Here is some work done in our area (biodiversity): http://code.google.com/p/darwincore/wiki/Location The term there is http://terms.gbif.org/wiki/dwc:coordinateUncertaintyInMeters d) the correct name for "globe" is "Geodetic datum" or "geodetic system" (which is more than the globe). See http://en.wikipedia.org/wiki/Geodetic_system or http://terms.gbif.org/wiki/dwc:geodeticDatum. WGS 84 (as a wikidata item) is a valid geodetic datum or system. Both terms are equally correct. "Globe" is not correct. Gregor

yes, probably better without a "geo" if it shall work for moon or mars as well. However, http://en.wikipedia.org/wiki/Coordinate_system is far broader term. But I cannot find a correct superclass term for Geographic/Selenographic/Martiographic(?) coordinates. http://en.wikipedia.org/wiki/Spherical_coordinate_system may be close, but its beyond my competence to decide. Coordinates should be pragmatic enough. Or LocationCoordinates. you try to solve the problem of reproducing the precision of the number as entered. However, the proposed mechanism is a mechanism of uncertainty, which is far more general, able to express the uncertainty radius that is due to e.g. specific GPS technologies. When reading the proposal, I did not even understand your narrower intention in your proposal. I believe it does not work to simple use a an equator based distance-in-m to degree conversion. See http://commons.wikimedia.org/wiki/Commons:Geocoding#Precision for examples how this changes in moderate latitudes, not to speak of being near the pole. My Conclusions: a) the model may be able to express the number of digits in degree-minute-second, decimal degrees, and degree-decimal-minutes. I believe, however, that it is yet underdefined. The value in precision necessary to specify whether a decimal-degree-stored-value is to be reproduced as 44°15', 44°15'15'', 44°15'15'.15', 44°15'15'.15', 44°15.1515, or , 44.151515 ° (which are different example values of course, not just different precision) is unclear to me. Latitude and longitude to 4-5 significant digits mean different precision in meters, but it is customary to give the same precision. b) the model may unduly suggests it can be used for arbitrary reasons of precision. However, it can not ALSO capture imprecision or uncertainty expressed as 00°15′00″S 78°35′00″W +/- 300 m, since this requires a conversion which is different for longitude and latitude and longitudes at different latitudes. That is an geocoordinate with an explicit "+/- xx m" uncertainty cannot be entered in wikidata. This is an acceptable limitation, but it should be understood and clearly stated. In a later mail Denny writes "I still would prefer "Arcdegree of the equator of the given globe" over "Meter", as it allows to measure any globe without having too much details about the globe. but otherwise it seems like the same things. (And they can be transformed from one to the other using a simple factor)." I think this is not correct. There is no general and simple convertibility between error radius as distance and number of significant digits in degrees. c) if the goal is to store the number of significant digits/figures, I suggest to store this more directly, although I admit that in the presence of different representations (decimal degrees, DMS, etc.) this is not trivial. If it shall be applicable outside earth, geodetic datum/system may actually be too narrow, I did not think of that. I don't know the correct superterm then. Maybe just call it "system", and explain, that "for earth it defines the geodetic or similar datum or system, for other celestial bodys their analogues". I am rather certain that Wikidata does not need to add a further parameter for earth, moon, etc. as Jeroen suggests. I suggest to add to the documentation: "The Geodetic or Spatial reference system must be chosen in such a way that it automatically implies the celestial body to which the coordinates apply (Earth, Moon, Mars, Venus, Sun, etc.)". I almost believe that this will always be the case, since these system must define the shape of the ellipsoid, which is different for different celestial bodies. Gregor

For every globe we would always need a geodesic system. Even if it is the Mars, we need to know where are the poles, where is the 0 Meridian, etc. Refering to these seems to make most sense. Which does not mean that we should let the user decide if they want WGS84 or Ares Prime 0, or Selenographic system etc. -- the editor should merely choose "Earth", "Mars", or "Moon" respectively. (Names are made up, I could actually not figure out what the usual geodesic systems are). Cheers, Denny 2013/1/8 Jeroen De Dauw <jeroendedauw(a)gmail.com> -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.

On 08.01.2013 14:02, Katie Filbert wrote: In this context we should keep in mind that MaxSem and Tomasz are considering re-using Wikibase code for that extension, especially for storing the data. They would probably also be happy about a common code base for parsing, normalizing and rendering coordinates. We should cut them in on this discussion, I think. -- daniel -- Daniel Kinzler, Softwarearchitekt Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e. V.

I'd prefer to use a radius here, for simplicity reason. The system is complex enough as it is. 2013/1/8 Nikola Smolenski <smolensk(a)eunet.rs> -- Project director Wikidata Wikimedia Deutschland e.V. | Obentrautstr. 72 | 10963 Berlin Tel. +49-30-219 158 26-0 | http://wikimedia.de Wikimedia Deutschland - Gesellschaft zur Förderung Freien Wissens e.V. Eingetragen im Vereinsregister des Amtsgerichts Berlin-Charlottenburg unter der Nummer 23855 B. Als gemeinnützig anerkannt durch das Finanzamt für Körperschaften I Berlin, Steuernummer 27/681/51985.