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

...

geocoordinates

Yep, agreed. Or just coordinates.

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.

In practice the value will be given as 44°15'. Then we know it is by the minute - and not that it is given by a nautical mile. I am not making a highly complex conversion -- I am just looking at the number and saying "oh yeah, this seems to be given by the minute, and not by the second or by the degree".

The reason why I prefer degrees on a given equator to meters is that it makes more sense on varying globes, like the Earth, Moon, Sun, Jupiter, and Phobos. What we need is the possibility to understand that 44°15' should not be displayed as 44°15'00.001" the next time the value is displayed. And by saying it is correct by the minute allows us to do so. Making the statement in meters would actually require us to make that complex calculation which would be based on the given geodetic system -- which is much more complicated than the current suggestion.

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.

...

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.

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@gmail.com

Hey,

Why use Q2 ("earth") as the glob, and not Q215848 ("WSG84")? That would be a lot clearer, I think.

Since WGS84 implies Earth, this works for Earth. Is such an implication always present though? What if I want to describe a location on some random planet - I suspect you'd have to specify some system and the globe. If this is the case, we should not omit the globe.

Cheers

-- Jeroen De Dauw http://www.bn2vs.com Don't panic. Don't be evil. --

---

Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/wikidata-l

On 08.01.2013 14:02, Katie Filbert wrote:

I think it's worth taking a look at what MaxSem has done with the GeoData extension, which is used for mobile apps, etc.:

https://www.mediawiki.org/wiki/Extension:GeoData

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

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@eunet.rs

On 08/01/13 12:36, Denny Vrandečić wrote:

...

Location: <https://meta.wikimedia.org/**wiki/Wikidata/Development/** Representing_values#**Geolocationhttps://meta.wikimedia.org/wiki/Wikidata/Development/Representing_values#Geolocation

...

I'm not sure if we should be going that far, but there may be cases where longitude and latitude are known with different degree of accuracy, so multiple precisions might be needed.

______________________________**_________________ Wikidata-l mailing list Wikidata-l@lists.wikimedia.org https://lists.wikimedia.org/**mailman/listinfo/wikidata-lhttps://lists.wikimedia.org/mailman/listinfo/wikidata-l