GeoJSON

Hey all,

One of the topics we’ve been talking about for location is the inclusion of a field to capture GeoJSON (http://geojson.org/) content. If you’re not familiar, GeoJSON is an RFC to capture geographic data structures (points, lines, multipoints, multilines, polygons, collections) in JSON.

Allan Thomson has suggested that we include GeoJSON on the location object. We discussed it a bit on the working call today, though, and it seemed like nobody had a real need for it…people pretty much just wanted the attributes from maxmind (region, country, administrative_area, city, street_address, latitude, longitude) and felt that GeoJSON was too much at this point. But obviously the TC is bigger than the working call.

To outline the options:

Option 1: Include GeoJSON as an optional property alongside the other MaxMind-style attributes, including latitude and longitude. This creates a bit of “two ways of doing things”, because then you can either use GeoJSON to represent a point or you can just use the lat/long fields in the core location object.

Option 2: Defer GeoJSON for now, mark it as a reserved word. This means that we have one very straightforward way of representing both addresses and lat/lng, but do not have a way to draw other geometries (multiple points, lines, bounding boxes, etc).

Which do people prefer? Do you have a use case for the more feature-rich capabilities that GeoJSON provides, or is it sufficient to just stick with the MaxMind attributes? If you think we should go with Option 1, do you have use cases for the more complicated data structures that you can share?

Consensus from the working call (about 12 people on the call) is that we should go with Option 2 and not include GeoJSON at this time.

Thanks,

John

cti-stix message