latitude and longitude are strings, probably to allow use of annotations like "N" and "E". I recommend we just use negative numbers (and these should really BE numbers, but oh, well).
let's use units of "m" for elevation
a way to state accuracy would be useful. SSN provides some definitions that are useful, but we need to figure out how to use them, eg we have to related them to "location" as a feature of interest. We may need to come up with our own definitions. Note that location is included in the web geolocation API and we should align with that... a radius (in m, on the surface of the earth, eg. spherical arc distance) for lat/long and another value for elevation uncertainty. Note that this gives a cylinder as the volume of uncertainty (if you ignore the spherical arc, anyway...)
no definition for "depth". If we DID define this, we could consider it an offset against the elevation (which could also be provided; if not given, it would need to be found from another source, which we probably should define...)
link relation types? How to link dynamic property values of this or other things?
eg. for dynamic location, use a special link relation type, e.g. "locationOf", that MIGHT refer to a property, in another or even the same TD (eg using absolute or relative JSON Pointers)
To test spatial queries with directory services, need to annotate TDs with geolocation. See https://github.com/w3c/wot-thing-description/issues/941 Let's use this one (just for the purposes of the plugfest): https://github.com/w3c/wot-thing-description/issues/941#issuecomment-672928550 from schema.org