Feature request: geographic location

[kengruven]

A big part of the spec is devoted to Temporal Types, yet there aren't any corresponding Spatial Types.

It would be great to have a Location type -- essentially, ISO-6709 for CE. Everybody's carrying a GPS-enabled and internet-connected device, and location data is supported by most popular databases (PostGIS, MySQL spatial types, etc). It's a natural data type to store and transmit.

Today, we're mostly using standards like ISO-6709 and GeoJSON, and spending tens or hundreds of bytes per location. CBE, if it had knowledge of the structure of a Location, could encode them much more efficiently.

I see there's the possibility of Custom types in CE (which I haven't really explored yet), so if this doesn't qualify for the core spec, perhaps it could be the start of a Library of types. It would be a shame if everyone using CE had to work out how to save geographic locations in their own way.

There is actually a latitude/longitude feature in CE already, but only as a method of specifying a time zone. If you're OK with 0.01° precision (roughly 1km), you can encode a location in only about 8 bytes!

[kstenerud]

Hmm good idea!

I've taken a quick look at what the standards are. It looks like there's consensus on latitude/longitude, but differing standards on height, with CRS showing which one is in use. The SRID info seems pretty complicated, and it looks like they apply scaling factors as well?

So it'll be a matter of figuring out which one is the most common internationally and go with that for units and origin points... unless there are other concerns? I suppose it's also important to consider what's being proposed for other planets such as Mars?

[kengruven]

Disclaimer: I'm not an expert at this, either.

Coordinate systems can get complex, but SRID is (I think) basically just a tag to tell applications how to interpret the data. WGS 84 (aka SRID 4326) is the most common, and many systems (GeoJSON, Apple's CoreLocation, Android Location, etc.) only support that.

CE is an encoding format, not a query language, so even if you choose to support arbitrary coordinate systems, it won't need to deal with conversions.

Personally, I'd be fine with declaring that a location is a structure with:

• latitude: decimal float (degrees)
• longitude: decimal float (degrees)
• (optional) altitude: decimal float (meters)

and it's always in WGS 84. The one system I've used that supports other SRIDs (PostGIS) also supports transforming points between systems, so it's no big deal there.

(I'm sure some GIS nerd will drop by and tell us we're missing a crucial feature, but then, hey, we'll have a GIS nerd here to tell us what to do.)

It looks like there are already Martian SRIDs, so if you want to support Mars, it might be as easy as adding SRID as a 4th element to the structure.

[kengruven]

I guess another option is just to avoid the SRID question entirely. Define "Location" as a structure with latitude/longitude/altitude, and say it's up to users to declare (out-of-band) what SRID their data uses, especially if it's anything other than WGS 84 (like "Mars").