A JSON protocol for sharing and storing real-time data streams. Common use would be for sharing location data.

json format for geo data

Common minimal format for sending just lat/long data
[
	{
		uuid: "550e8400-e29b-41d4-a716-446655440000",
		date: "2010-04-30T16:50:00Z",
		location: {
			position: { 
				latitude: 45.5118,
				longitude: -122.6433
			}
		},
		client: {
			name: "Geoloqi",
			version: "0.1",
			platform: "iPhone OS 4"
		}
	},
	{
		uuid: "550e8400-e29b-41d4-a716-446655440001",
		date: "2010-04-30T16:50:00Z",
		location: {
			position: { 
				latitude: 45.5128,
				longitude: -122.6435
			}
		},
		client: {
			name: "Geoloqi",
			version: "0.1",
			platform: "iPhone OS 4"
		}
	}
]

Full data format allowing custom information to be included based on source of location data
[{
	uuid: "550e8400-e29b-41d4-a716-446655440000",
	date: "2010-04-30T16:50:00Z", (iso8601 format)
	location: {
		position: {
			latitude: 45.5118,
			longitude: -122.6433,
			geojson: {
				type: "Polygon",
				coordinates: [[-122.643, 45.512], [-122.650, 45.512], [-122.643, 45.533], [-122.650, 45.533]]
			},
			altitude: null,
			heading: 190,
			speed: 56,
			horizontal_accuracy: 6.0,
			vertical_accuracy: 8.0 (in meters)
		}
		source: "hardware_gps,wifi,street_address,agps,twitter,foursquare,geomena"
		type: "latlng,address,neighborhood,city",
		raw: (from hardware gps device) {
			dop_h: 2.7,
			dop_v: 2.1,
			satellites: []
		},
		raw: (from wifi positioning) {
			aps: []
		}
		raw: (from twitter) {
			id: "103994853",
			created_at: "Tue Apr 07 22:52:51 +0000 2009",
			text: "At least I can get your humor through tweets. RT @abdur: I don't mean this in a bad way, but genetically speaking your a cul-de-sac.",
			source: "<a href="http://www.tweetdeck.com/">TweetDeck</a>",
			....etc....
		}
	},
	client: {
		name: "Geoloqi",
		version: "0.1",
		platform: "iPhone OS 4",
		other: "whatever"
	},
	environment: {
		air_temperature: {
			celsius: 20.3
		},
		humidity: {
			percent: 80
		},
		sound_pressure_level: {
			pascals: 10
		}
	},
	body: {
		heart_rate: {
			bpm: 100
		},
		core_temperature: {
			celsius: 25
		}
	}
}]


Format for querying positions of multiple users:
[{
	user: {
		id: "http://aaron.pk",
		display_name: "aaronpk",
		url: "http://aaronparecki.com",
		image_url: "http://aaron.pk/pic.jpg"
	},
	data: []
},
{
	user: {
		id: "@caseorganic",
		display_name: "caseorganic",
		url: "http://oakhazelnut.com",
		image_url: "http://a1.twimg.com/profile_images/116264220/kk-caseorganic-48px.jpg"
	},
	data: []
}]

Another consideration, not sure where to add this, but would be interesting to be able to log what mode of transportation is used for each point logged as well. If I'm driving, all the points for that trip should have the "driving" attribute, and similarly if I was walking, busing, etc.

I'm loving this idea- Just a couple of quick questions:

1. How do you add other types of data to the spec? (e.g. Mood, Purchase info, etc.)

2. Is some of this stuff optional? (I'm thinking it would be pretty hard right now to include some of that body stuff with every update)

The idea behind this protocol is that various data can be stored along with a timestamp.

In some cases this may be just location data, and the location data may include more or less than what is shown here. Other examples include environment and body. These examples shown are thought out less than the location block, with the hopes that someone who has more experience logging this type of data can flush out the spec following the same structure as we have here.

In "location," the "raw" field gives each service a place to embed any relevant meta-data, such as the user's original tweet if the location data was pulled in via Twitter, or the list of visible wifi access points that contributed to geo-locating the user. The "geo_json" block would define the area of the location update if a specific point is not defined, such as when logging a neighborhood or city.

Consideration: How do you log a point with no center point, such as a city. If I want to log the fact that I'm in Portland, but without marking a specific point on the map. Maybe omitting "position" in favor of "geo_json," or maybe making the "position" element a geo_json block instead?

it would make a lot of developers happier if you represent all geometries in geojson, as it would be pretty pointless to re-implement a json representation of geo data

example: http://data.pdxapi.com:5984/bicycle_parking/f0f6b0d5927d01880f3824585b161ace

aaronpk and I talked some about geojson. at minimum a position is a lat/long/accuracy, which is also a circle. geojson does polygons, which means to do a radius is estimating a circle with X points. very verbose way to draw a circle. also going from a geojson polygon to a lat/long/accuracy value would be difficult at best.

That being said, a geoJson polygon for position would be very useful for non-GPS style checkins. If I am checking into a park, having the outline of the park be my 'position' would work well. since lat/long/acc are required, the client would take a best guess at the centerpoint in addition to the geoJson data.

I wonder if a collection of checkins could be of use in implementing a sort of differential correction. Location accuracy might be able to be increased by comparing some aspect of the user's perspective to the same aspect of nearby checkins.

For example, if nearby checkins included a photograph of some fixture in the users' environment (like a building with distinctive lines, a rock formation, a fiducial marker) along with camera inclination and heading, it might be possible to narrow down the user's current position.

Could a checkin leave behind some kind of breadcrumb (like correction data) that improves future checkin accuracy?