Yep, there are many reasons why geographic coordinates should be
reified, largely because some people need more information than others.
Today all the people who got into geography in the last few years use
WGS84 as a datum so it's fashionable to not specify any datum. That goes
back to the bad old days when visual surveying was the only game in town so
you could specify locations on an island relative to each other quite
accurately but need to get a fix against the stars to know where the island
as a whole was.
Even neogeography projects, however, sometimes need to specify a
datum. A while back I was collecting a data set on the Hollywood Walk of
Fame and the requirements there were: (i) stars get located on the right
side of the street, (ii) stars get located in the right order, and (iii)
stars get located on the right block. WGS84 (a standard GPS unit) isn't
quite good enough to do these three things, particularly close to the
Hollywood and Vine intersection where there are some big buildings with
metal in them and probably some QRM too. Satisfying those three
requirements is a matter of creating your own datum which you could with
some kind of DGPS or in my case merging ground observations with published
data.
There also are things that have two coordinates, different levels of
accuracy, altitude or not altiitude, etc and just bundling the properties
together in an object future proofs you for all that.
-----Original Message-----
From: Andreas Schultz
Sent: Wednesday, October 17, 2012 7:20 AM
To: wikidata-l(a)lists.wikimedia.org
Subject: [Wikidata-l] JSON representation
Hi all,
I have a question or rather proposal regarding the JSON representation [1].
The "Geo" example on the JSON page[1] implies that there won't be a
fixed representation for data types. Instead of the "value" key that
all the other examples use, the Geo example uses "longitude" and
"latitude". Wouldn't a representation like the following be more
appropriate?
"value": {
"latitude" : 32.233,
"longitude" : -2.233,
}
That is, if "snaktype": "value", then there has to be a
"value" key
with a data type specific value object.
Something that imho would also be useful, is a way to specify the data
type - this could be optional. For the Geo example something like the
following would make sense:
"datatype": "geo"
Without such a definition, a consumer would have to derive the data
type from the keys and/or the lexical representation of the values,
which would usually be a tough task.
Cheers,
Andreas
1.
https://meta.wikimedia.org/wiki/Wikidata/Development/Phase_2_JSON
--
Telefon/Phone +49 6441 87087-32 · Telefax/Fax +49 6441 87087-17
E-Mail a.schultz(a)mes-semantics.com · Web
http://mes-semantics.com
________________________________________________________________
MediaEvent Services GmbH & Co. KG
Berlin Office: Stendaler Straße 4 · 10559 Berlin · Germany
Wetzlar Office: Charlotte-Bamberg-Str. 6 · 35578 Wetzlar · Germany
Handelsregister/Commercial Register: Amtsgericht Wetzlar HRA 4015
USt-IdNr./VAT Reg.No. DE206509024
Komplementärin: MediaEvent Services Verwaltungs GmbH
Handelsregister/Commercial Register: Amtsgericht Wetzlar HRB 5079
Geschäftsführer/Managing Director: Tim Ebert
________________________________________________________________
_______________________________________________
Wikidata-l mailing list
Wikidata-l(a)lists.wikimedia.org
https://lists.wikimedia.org/mailman/listinfo/wikidata-l