Geolocation requirements

[mlagally]

Create geolocation requirements for use case: https://github.com/w3c/wot-architecture/blob/master/USE-CASES/govtech-gps-module.md

[egekorkan]

I would give input regarding how to describe sensor properties that are valid also outside of the GPS use case. Maybe a new requirement/use-case on how to describe sensor properties would be interesting. About the different words used such as accuracy, resolution, precision the attached image would be helpful.

[mlagally]

@egekorkan This is very useful. Do you have the image rights so we could use it in a document, if necessary?

[egekorkan]

Yes, you can find the source attached. You need to open it in draw.io after extracting the zip. prec_acc_rs.xml.zip

[mmccool]

Ideally we would not reinvent the wheel here, but would build upon or explictly reference existing standards in the area. I also think we need to align with the geolocation standards in the web browser, so reaching out to the spatial data group makes sense. External groups likely to be aligned with the use of linked data, such as ETSI/NGSI-LD/FiWare, should also be considered.

Regarding the problem of precision/accuracy/resolution, these terms definitely relate to more than just geospatial information. They also easily relate to other measurements, such as temperature. So a general mechanism would be useful. Again, we should investigate whether there are any existing standards in the area we can reference and build upon. Perhaps we should talk to the SOSA/SSN group, since this seems likely to be something that they will have investigated. One special feature of geolocation data however is that it's multidimensional, and so in general when giving variances, etc. you need a multidimensional metric, and perhaps also a way to capture correlations between different dimensions (eg a variance matrix). This may also apply to other measurements, for instance accelerometer data.

[mmccool]

Looking at the SSN standard, there are indeed some definitions (I summarize, but please look at the actual definitions):

• Accuracy - for a sensor, how close an observed value is to the true value; for an actuator, how close an observed value is to an actuation command to change that value (eg a thermometer measurement vs. the thermostat setpoint)
• Precision - for a sensor, closeness of a agreement of repeated observations; for an actuator, measure of the ability to consistently replicate an actuation
• Resolution - for a sensor, the smallest difference in values observed that would result in a perceptible difference; for an actuator, the smallest difference in the value of an actuation command that would result in a value change of the property being acted on.

Some of these definitely need further refinement, especially for data values. For instance, in some cases I would want actual hard bounds as given above, in other cases I might want variances (eg for a probability distribution), and the issue of multidimensional variation and correlation does not seem to have been dealt with. But these are a starting point, I need to read this spec and geolocation specs more closely, and there are probably ways to define more specific concepts.

[mmccool]

SSN also defines some additional concepts like Latency, Drift, Frequency, etc that I hadn't considered but are useful.

[mmccool]

An online search also comes up with this: Basic Geo Vocabulary, defined by Dan Brickley, that defines basic terms for latitude and longitude, etc. It uses WGS84 (the World Geodetic System standard) as a reference. This is the reference coordinate system for GPS.

[mmccool]

The Open Geospatial Consortium (OGC) defines an abstract standard for referring to locations using coordinates. This is related to ISO 19111, Geographic Information - Referencing by coordinates. Upon further searching I found some RDF definitions of the concepts in the ISO 19111 standard, but it's not clear whether any of these have themselves gone through a formal standardization process (the Basic Geo Vocabulary mentioned above is not a W3C standard, just an informative document/set of definitions).

[mmccool]

On balance, the Basic Geo Vocabulary seems like a good place to start for simple applications (although see caveats below); more complex applications can use the ISO 19111/OGS definitions. We will have to do some digging to figure out how to deal with accuracy/precision/resolution in geo and other applications; ideally (if we were starting from scratch...) this issue should be dealt with orthogonally (in a way applicable to any measurement, perhaps following SSN) but for consistency with other geolocation APIs (eg in the browser) and do to the multidimensional nature of geolocation data (which at first glance SSN does not seem to address; need to investigate further) we may need to use specific terms for geolocation.

However, I think the SSN definitions applied to terms in the Basic Geo Vocabulary are probably good enough for most "simple" applications; that is, just worry about the precision/resolution etc. of individual elements (eg longitude. altitude, etc.) without worrying about correlation between multiple measurements.

[mmccool]

Finally, one more reference I stumbled across, using "geolocation ontology" and limiting the time to the last year, for WikiData: P625.

[mmccool]

Looked into the W3C Geolocation API; salient comments below:

• It explicitly references WGS84
• It defines "accuracy" elements for each of latitude and longitude together, as a single number (probably the worst case is meant to be used... it doesn't say), and an altitude "accuracy" separately, as part of the Coordinates Interface.
• There are also speed and heading elements returned as part of this but "accuracy" elements do not seem to be defined for them.
• It defines "accuracy" values as "should correspond to a 95% confidence level." This implies a definition in terms of a probability distribution.

EDIT: I re-read the SSN definitions and it seem the use of accuracy here does align with the use in SSN. The 95% confidence interval should be interpreted as "the probability that the reported value will be within the stated accuracy of the true value". For latitude and longitude, this implies probability of the 2D position being inside a "rectangular" box (distorted though by the mapping onto a spherical coordinate system). There is a slight ambiguity in the spec (I think) about whether the 95% relates to the two coordinates separately or their joint probability of being inside the box (note that 0.95 * 0.95 = 0.9025, and conversely sqrt(0.95) = 0.975).

So: the following comment is NOT correct:

• I'm not sure the use of the term "accuracy" is well-aligned with the SSN definition; it seems closer to the SSN term "precision" (repeated observations drawn from a probability distribution, with 95% probability that they will be within the delta given, plus or minus, centered on the main observation value returned). This is bound to cause problems... maybe we need a separate vocabulary for the Web API that is (behind the scenes) defined in terms of SSN vocabulary.

[mmccool]

The Basic Geo Vocabulary is pretty simple, just "lat", "long", and "alt". There are some caveats:

• It does not define accuracy.
• There is a "lat_long" joint element that is deprecated.
• It defines values as strings, rather than numbers, though, which is a bit odd. This also implies to me that it is defining a data schema rather than just a vocabulary. This might end up conflicting with definitions of data schemas inside TDs that use actual numbers (which, you know, makes sense for a device returning coordinates).

[mmccool]

There is a newer geolocation API being worked on by DAS. The data schema seems similar but all elements are optional, and there is a timestamp: https://w3c.github.io/geolocation-sensor/#geolocationsensor-interface

[mmccool]

So the issue of "time" is another major issue that relates to all kinds of sensors, not just geolocation. In the case of GPS though, the time can come directly from the GPS signal and is highly accurate.

[mmccool]

Here is the timestamp referenced by the DAS spec: https://w3c.github.io/hr-time/#dom-domhighrestimestamp

[mmccool]

This is also interesting: https://www.iso.org/obp/ui/fr/#iso:std:iso:ts:19159:-2:ed-1:v1:en It's about LIDAR and remote sensing, but references various other ISO standards for time, sensor data, etc. etc. Also, we were just talking about a "remote sensing" use case for drones (used for agriculture) in the POC meeting.

[mmccool]

I created a PR to update the geolocation use case to mention some of the above (see the related standards section, mostly): https://github.com/w3c/wot-usecases/pull/27. By the way... should this issue be moved to the Use Cases repo?

[mlagally]

@mmccool Many thanks for your updates. We moved the use cases to the wot-usecases repo, preserved them here to avoid broken links. Please retarget/recreate the MR in the new repo.

[mlagally]

@mmccool Pleasse verify the document content and confirm that there is no further work to be done on this issue.