`crs` or `srs` field in sensorReport

VladimirAlexiev commented 3 years ago

(As suggested at today's call):

Related to #264 "if we have Latitude, Longitude (in decimal degrees), maybe we should also have Easting, Northing (in meters, often used by UK Ordnance Survey)".

But it's not enough to just say "decimal degrees or meters".

These also depend on the adopted origin, the geographic projection, axis orientation, etc. OGC has done a lot of work on Coordinate Reference Systems.
As per https://github.com/qudt/qudt-public-repo/issues/379, neither QUDT nor CBV should attempt to redo this work.

So maybe we need yet another sensorReport field, crs or srs

there are several hundreds or thousands defined by OGC at http://www.opengis.net/def/crs, with algorithms to convert between them. They are adopted in GeoSPARQL and other OGC standards
I think OGC uses both "CRS" and "SRS" in some contexts
"crs" on wikipedia redirects to https://en.wikipedia.org/wiki/Spatial_reference_system

mgh128 commented 3 years ago

Yes, we should not redo existing work. At present, the GLN data modelling work group / sub-group is proposing to add gs1:geodeticSystem within gs1:GeoCoordinates, expecting a value from a code list, which would include WGS84 and the others that Philip mentioned on the call today, NAD 83, NAD 27, ED 50, SAD 69 and others from http://www.opengis.net/def/crs (though I only see four entries there, rather than hundreds or thousands).

VladimirAlexiev commented 3 years ago

These are folders. Eg see

http://www.opengis.net/def/crs/EPSG, and then
http://www.opengis.net/def/crs/EPSG/8.5 (nearly 6k)

A search and conversion tool is at https://epsg.io/.

https://en.wikipedia.org/wiki/EPSG_Geodetic_Parameter_Dataset "is a public registry of geodetic datums, spatial reference systems, Earth ellipsoids, coordinate transformations and related units of measurement. Each entity is assigned an EPSG code between 1024-32767, along with a standard machine-readable well-known text representation."
Eg https://epsg.io/?q=bulgaria are 70 CRS applicable to Bulgaria alone, eg
```
Pulkovo 1942(83)
EPSG:4178 with transformation: 15998
Area of use: Onshore Bulgaria, Czechia, Germany (former DDR), Hungary and Slovakia. (accuracy: 5.0)
```
I already hear tanks rumbling (Pulkovo is the Russian observatory, and I guess this CRS is a military one from the Cold War era)
I cannot find "NAD 27" there

https://epsg.org/ seems to be the official register of EPSG geodetic dataset

https://epsg.org/search/by-name/?query=NAD+27 finds 225 CRS
- one geographic 2D "North America - NAD27"
- a bunch of "projected" ones, for various areas of the USA
EPSG is huge, but OGC CRS (http://www.opengis.net/def/crs) incorporates it, plus more.

@mgh128

are CRS, SRS, and geodeticSystem the same thing?
Can you ping Philip to comment here?

BTW searched schema.org, there's nothing about CRS, SRS, geodetic

mgh128 commented 3 years ago

According to https://en.wikipedia.org/wiki/Spatial_reference_system it appears that Spatial Reference System and Coordinate Reference System can be used interchangeably and that a geodetic datum such as WGS84 is an instance of a spatial reference system or coordinate reference system.

dr-shorthair commented 3 years ago

Spatial references include place-names (gazetteers) and spatial indexes, such as DGGS, as well as coordinates. Coordinate references are essentially geometric references, usually expressed as a group of 1-4 real numbers, representing a position vector in 1-4 cartesian dimensions.

So SRS is the more general term, while CRS is reserved for coordinates.

VladimirAlexiev commented 3 years ago

@mgh128:

At present, the GLN data modelling work group / sub-group is proposing to add gs1:geodeticSystem within gs1:GeoCoordinates

@dr-shorthair, would gs1:coordinateReferenceSystem (or gs1:coordinateSystem for short) be a better name for that property?

dr-shorthair commented 3 years ago

In ISO 19111 (and the EPSG database model) a coordinate-system is a set of axes, directions and scales. A coordinate-reference-system is a coordinate-system which is also anchored to a (usually geodetic) datum. So it would not be appropriate to use the former as a shorthand for the latter.

A geodetic system is tied to the Earth, rather than another planet. If GS1 is OK being tied to one planet, then probably OK.

VladimirAlexiev commented 3 years ago

Today at the meeting agreed:

SensorReport will use prop epcis:coordinateReferenceSystem
The ontology will state epcis:coordinateReferenceSystem owl:equivalentProperty gs1:coordinateReferenceSystem (or skos:exactMatch)
We prefer the long name gs1:coordinateReferenceSystem instead of abbreviation gs1:crs
EPCIS will recommend using http://www.opengis.net/def/crs/ URLs
we'll also make a table of a few important CRS for reference:

CRS	OGC URL to use
WGS 84	http://www.opengis.net/def/crs/OGC/1.3/CRS84
NAD 27
ED 50
SAD 69

RalphTro commented 3 years ago

Dear @VladimirAlexiev: I just reread/reflected on this issue once again and think that (at least :-)) I need your help to fully grasp the impact of this suggestion.

First, I was wondering why we don’t define which system must be used or at least specify a default? For instance, IETF RFC 5870 (defining the Geo URI scheme) does the latter, see https://datatracker.ietf.org/doc/html/rfc5870#section-3.4.1 ("A URI instance uses the default WGS-84 CRS if the 'crs' parameter is either missing or contains the value of 'wgs84'.") Wouldn't that be an easier/less complex approach?

Second, would you mind to insert one or two illustrative example(s) of how a sensorReport with this property would actually look like? That would be really helpful.

Thanks for your support!

mgh128 commented 3 years ago

Dear @RalphTro There was discussion on one of our recent calls in which Philip Heggelund mentioned some of the other coordinate reference systems that are in use in the oil and gas industry. Not sure if you missed that discussion. If a sensor is capable of producing geocoordinates using a coordinate reference system other than WGS84 then we should have a way to explicitly state which coordinate reference system is being used. It is not trivial nor desirable for EPCIS implementations to have the burden of converting all these other coordinate reference systems to/from WGS84 but at least if we ensure that the coordinate reference system can be stated explicitly, an application consuming EPCIS data can perform that conversion. Yes, it does mean that if the data and query both specify coordinate reference system but do not use the same coordinate reference system, then they will not match, even if they refer to the same terrestrial position.

VladimirAlexiev commented 3 years ago

@CraigRe

Yes, coordinateReferenceSystem should be optional, and the default will be WGS 84, which has the URL http://www.opengis.net/def/crs/OGC/1.3/CRS84 (OGC's GeoSPARQL does the same)
We won't use strings like wgs84 but URLs from the http://www.opengis.net/def/crs namespace.

Here's an example:

Coordinates of a readPoint in Sofia, Bulgaria

sensorElement: [
"sensorMetadata": {"time": "2021-05-20T12:23:34+00:00"},
"sensorReport": {"type": "Angle", "component": "Latitude",  "value": 42.698334, "uom": "DD"},
"sensorReport": {"type": "Angle", "component": "Longitude", "value": 23.319941, "uom": "DD"}
]

WGS84 is default and its URL is http://www.opengis.net/def/crs/OGC/1.3/CRS84, so this means the same as:

sensorElement: [
"sensorMetadata": {"time": "2021-05-20T12:23:34+00:00"},
"sensorReport": {"type": "Angle", "component": "Latitude",  "value": 42.698334, "uom": "DD",
"coordinateReferenceSystem": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"},
"sensorReport": {"type": "Angle", "component": "Longitude", "value": 23.319941, "uom": "DD",
"coordinateReferenceSystem": "http://www.opengis.net/def/crs/OGC/1.3/CRS84"}
]

We could also express this as Easting, Northing in a CRS that uses these coordinate components: https://epsg.io/27700: EPSG:27700 OSGB 1936 / British National Grid (Ordnance Survey of Great Britain). You can see the conversion at https://epsg.io/transform#s_srs=4326&t_srs=27700&x=23.3199410&y=42.6983340, and browse for the OGC EPSG URL at http://www.opengis.net/def/crs/EPSG/0/ (where /0/ indicates the "latest version" or version-independent URL of that CRS
- (That CRS is intended for an area of the UK, so the easting/northing coordinates may not be very precise for Sofia)
```
sensorElement: [
"sensorMetadata": {"time": "2021-05-20T12:23:34+00:00"},
"sensorReport": {"type": "Length", "component": "Northing", "value": -477979.89, "uom": "MTR",
"coordinateReferenceSystem": "http://www.opengis.net/def/crs/EPSG/0/27700"},
"sensorReport": {"type": "Length", "component": "Easting",  "value": 2477583.57, "uom": "MTR",
"coordinateReferenceSystem": "http://www.opengis.net/def/crs/EPSG/0/27700"}
]
```
  TODO:
turn into SensorDataExample14, 15, 16
Move the bulleted explanations into WithSensorData/README.md
wrap in Document and ObjectEvent; the nesting structure may be a bit wrong
DONE: checked the UOMs

BTW, typing "type": "Angle", "uom": "DEG" quickly gets boring, so can we assume that "component": "Latitude" implies these two?

RalphTro commented 3 years ago

@VladimirAlexiev and @mgh128 - thanks so much for your additions/explanations! Much clearer to me now. As to your last point, @VladimirAlexiev : as we agreed that either type or exception needs to be present, I think we have to live with the boring approach for the time being. :-) I took a note to my ToDoList to add an example to GitHub illustrating the usage of coordinateReferenceSystem ((a) without it, i.e. meaning the default, (b) with explicitly referring to it, and (c) referring to another system then WGS84) as you suggested.

DuckScapePhilip commented 3 years ago

Unfortunately, I was not able to meet with my contact in the petroleum industry this week. I will try to follow up with him today.

VladimirAlexiev commented 3 years ago

@DuckScapePhilip EPSG comes from the petroleum industry, so hopefully https://epsg.org and https://epsg.io already give us all the info we need.

@RalphTro it would be nice if you browse around some more, and include some text to let EPCIS users know where to find coordinateReferenceSystem URLs to use.

I have no idea about the following (@dr-shorthair could you provide some advice on these points?)

what 8.5 in http://www.opengis.net/def/crs/EPSG/8.5/27700 means
how populated the other branches of http://www.opengis.net/def/crs/ are
how to find the "right" URLs for NAD 27, ED 50, SAD 69. As I mentioned, the first name finds maybe 50 CRSes at https://epsg.org ...

Cheers!

dr-shorthair commented 3 years ago

8.5 is the EPSG release. Actually this 'version' field in the URI is a hang-over from an older identifier model, and it is not good practice to include a version number in an identifier if the definition is not intended to change across releases. In OGC-land you can put /0/ instead, and this refers to 'the current or un-versioned definition'.

There is some discussion about updating the OGC naming rules to simplify the URIs - see https://github.com/opengeospatial/om-swg/issues/136

In the OGC definitions service, it is very sparsely populated away from the /EPSG/ branch. There really are only a few that matter

The multiplicity of NAD CRSs is probably because they are defined for states or regions.

RalphTro commented 3 years ago

Dear @dr-shorthair, Thanks! From your point of view, which of these URIs could or should we include as a (non-normative) note in the CBV standard? Ideally, the CBV should point to the most common/relevant ones. In this context: would these URIs be stable/persistent enough so that we are comfortable to include them in the first place?

In light of what @VladimirAlexiev suggested, I made a quick research on other relevant systems, and found e.g. the following: On https://www.w3.org/2015/spatial/wiki/Coordinate_Reference_Systems, it is said that "...using WGS84 explicitly or implicitly is just the easiest way because it is the favoured CRS in many specifications. (...) Because WGS84 is unsuitable in Europe, European guidelines (like INSPIRE) recommend using ETRS89." But I was not able to find ETRS89 on OGC's platform.

The EPSG registry (http://www.epsg-registry.org/) as "...the traditional source of CRS definitions in GIS (...)", uses EPSG codes (e.g. EPSG::4258) to refer to CRS definitions, i.e. no URIs. Are you aware of 'official'/well-established URIs we can recommend with good conscience?

Thanks a lot in advance for your help/support in this, @dr-shorthair !

dr-shorthair commented 3 years ago

ETRS89 == epsg:4258 == http://www.opengis.net/def/crs/EPSG/0/4258

In general the EPSG identifiers are the most widely known and used and likely to be persistent. There is an ISO register here https://geodetic.isotc211.org/register/geodetic/GeodeticCRS, but it is very unclear if this would supplant the EPSG list in practice. The http://www.opengis.net/def/crs/EPSG/0/ versions are the official OGC URIs for the EPSG-definitions.

The /OGC/ entities listed above represent a set of 'gaps' in the EPSG dataset, as of the time they were coined. The primary tension is that historical practice in Geography is to give global coordinates in the order (latitude, longitude) - i.e. (y,x). This contrasts with most projected systems which are usually (easting, northing) - i.e. (x,y) - and also surprises most non-geographers, including web developers. Hence http://www.opengis.net/def/crs/OGC/1.3/CRS84 is identical to http://www.opengis.net/def/crs/EPSG/0/4326 except for the axis order.

The other significant issue is that many web-mapping systems assume that the earth is a sphere, whereas the geodetic systems are based on ellipsoids.

epsg:3785 is an attempt to define the typical web-mapping projection ("Web mercator") as a formal CRS.

dr-shorthair commented 3 years ago

Thanks a lot in advance for your help/support in this, @dr-shorthair !

I'll send you an invoice.

RalphTro commented 3 years ago

Thanks a lot for your quick answer, @dr-shorthair! Really glad that you have joined this discussion.

My last remaining question at this moment in time is: which CRS URIs would you recommend the group to include in the standard (as non-normative examples to help/assist our users)?

dr-shorthair commented 3 years ago

2D systems -

dr-shorthair commented 3 years ago

Give my regards to @philarcher (at GS1) if you know him

RalphTro commented 3 years ago

GREAT - we will use your suggestion as a basis for decision in our next group call. A bit anxious about the prospect of getting your invoice now though...;-)

philarcher commented 3 years ago

Waving at @dr-shorthair :-)

VladimirAlexiev commented 3 years ago

@RalphTro I edited my example https://github.com/gs1/EPCIS/issues/266#issuecomment-844997138 to use /0/ and the correct unit DD for decimal degrees.

I think CBV should recommend the OGC URLs because they incorporate all of EPSG, and are used in GeoSPARQL.

RalphTro commented 3 years ago

Thanks, @VladimirAlexiev ! Just added two corresponding xml events to https://github.com/gs1/EPCIS/blob/master/XSD/SensorDataExamples.xml If you agree content-wise, I can also add the corresponding JSON/JSON-LD files.

VladimirAlexiev commented 3 years ago

Tasks and status as of 21 Sep 2021:

[x] 1. Add coordinateReferenceSystem:{@type:@id} to JSONLD-Context-simple
[ ] 1. Add coordinateReferenceSystem:{@type:@id} to JSONLD-Context: @jmcanterafonseca-iota
[x] 2. Add coordinateReferenceSystem to Ontology
[ ] 3. Add coordinateReferenceSystem to SHACL shape
[x] 4. Made 4 examples of equivalent location: WithSensorData 14,15,16,17 (lat/long, easting/northing, geo:) as per https://github.com/gs1/EPCIS/issues/266#issuecomment-844997138, and described them in README
[x] 5. Made example 17 using geo: (readPoint being a geo: URI) as per #292

@CraigRe I think you should provide in CBV guidance on how to express geographic coordinates:

[ ] 10. which coordinateReferenceSystem URLs to use
[ ] 11. links to the 2 EPSG sites and to OGC URL patterns, so people can know how to find them
[ ] 12. the URLs of 3-4 important coordinate systems
[ ] 13. Mention there are 4 examples of equivalent location expressed in different ways (see 4,5 above)

gs1 / EPCIS

`crs` or `srs` field in sensorReport #266