example: GPS location as `geo:` URI in `readPoint`

[VladimirAlexiev]

Our partner NGS in project PLANET puts sensors on trucks that measure GPS position and props like humidity, weight, illuminance, etc.

291 shows how they represent the Geo location using https://en.wikipedia.org/wiki/Geo_URI_scheme:

     "readPoint": { "id": "geo:4.278756,51.288163" },

I think that's legit.

Compare to the lot more verbose:

            "sensorReport": [
              {"type": "Angle", "value":  4.278756, "uom": "DD", "component": "Latitude"},
              {"type": "Angle", "value": 51.288163, "uom": "DD", "component": "Longitude"},

If legit, we should show both of these examples of representing Geo location.

[jmcanterafonseca-iota]

yes, nothing should prevent you from using a Geo URI but ... probably better for the bizLocation rather than the readPoint, as the readPoint is a door, a conveyor-belt, etc. i.e. probably something indoors so probably Geo Location is not the best way to encode it.

On the other hand, I think sensorReport does not have the same semantics as readPoint nor bizLocation. A sensorReport is intended to capture measurements made from sensors that are associated to an item in the supply chain, for instance to guarantee cold chain requirements. Under some situations an ObservationEvent with a sensorReport will not include any readPoint nor bizLocation, for instance when the item is in transit. If the item is at a warehouse there can be a sensorReport but it may not include a bizLocation as you already know, until further notice, where the item is.

[VladimirAlexiev]

readPoint is probably something indoors

Nothing says readPoint is indoors. The spec says "the most specific place at which an EPCIS event took place", whereas bizLocation is "place where an object is assumed to be following an EPCIS event". So I think readPoint better matches the momentary GPS location.

sensorReport (may) not include any readPoint nor bizLocation, for instance when the item is in transit.

Yes. But we're discussing how to represent the GPS position, if the sensors include GPS.

I think both variants above are legit, and I can prepare 2 examples to showcase and compare them.

@mgh128, @CraigRe, @RalphTro can geo: URI be used for readPoint?

[CraigRe]

@VladimirAlexiev , geo URIs are allowed for location (i.e., readPoint and businessLocation) identification in EPCIS events, though the CBV ( §8.4.5) recommends SGLN EPC (i.e., or GS1 Digital Link URI encoding of GLN + its optional Extension), "unless a geographic location URI is the only feasible alternative. "

[RalphTro]

Dear @VladimirAlexiev and @jmcanterafonseca-iota , I agree with @VladimirAlexiev : readPoint is not necessarily identifiying an internal location - many EPCIS implementations actually identify e.g. a manufacturing plant/a DC if this level of granularity is sufficient for their purposes. In this regard, when conveying geoURIs, I think that readPoint is IMHO the most appropriate field as it best reflects where an EPCIS event took place (e.g. the geographic position of a train or ship). Hope this helps. Kind regards, @RalphTro

[jmcanterafonseca-iota]

@RalphTro makes sense to use the readPoint to convey the geographic location of a sensor report while in transit

thanks for these clarifications, they are pretty useful.

[CraigRe]

@jmcanterafonseca-iota , the readPoint / businessLocation difference is retrospective vs prospective, regardless of whether indoors or out at sea (or on a stretch of road or railroad, or in vineyards, orchards, etc...)

[VladimirAlexiev]

Ok @CraigRe, set it to agreed, assign to me, and I'll make an example with the two alternatives to express GPS location.

[VladimirAlexiev]

Sorry about posting this because it's actually a stupid question: CBV sec 8.4.5 "Geographic Location URIs for Location identifiers" specifically allows it: "MAY use a geographic location URI as specified in RFC5870 to populate the readPoint and bizLocation fields".

• However, contrasting these two examples (long and short) will be useful.
• CBV refers to RFC5870 https://datatracker.ietf.org/doc/html/rfc5870.
• Why would people use the long way to express location rather than the short way? Here's one reason: as per https://datatracker.ietf.org/doc/html/rfc5870#section-8.3 and https://www.iana.org/assignments/geo-uri-parameters/geo-uri-parameters.xhtml, a geo: URI can use only these two CRS:
  • EPSG::4326, which is WGS84 (2D)
  • EPSG::4979, which is WGS84 with altitude (3D)
• Whereas the approach with component and coordinateReferenceSystem is more generic and can use any EPSG or OGC coordinate system
• @mkotoff list both the RDC link and https://en.wikipedia.org/wiki/Geo_URI_scheme in the README entry for this example, and add the previous 2 bullets

[VladimirAlexiev]

@mkotoff Have you made this example, and added the explanations above to the README?

[VladimirAlexiev]

Added JSON-simple-context\WithSensorData\SensorDataExample16.jsonld (PR is upcoming)