Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

crs or srs field in sensorReport #266

Open
VladimirAlexiev opened this issue Apr 27, 2021 · 25 comments
Open

crs or srs field in sensorReport #266

VladimirAlexiev opened this issue Apr 27, 2021 · 25 comments

Comments

@VladimirAlexiev
Copy link
Contributor

VladimirAlexiev commented Apr 27, 2021

(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 qudt/qudt-public-repo#379, neither QUDT nor CBV should attempt to redo this work.

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

@mgh128
Copy link
Collaborator

mgh128 commented Apr 27, 2021

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
Copy link
Contributor Author

VladimirAlexiev commented Apr 27, 2021

These are folders. Eg see

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

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


@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
Copy link
Collaborator

mgh128 commented May 3, 2021

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
Copy link

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
Copy link
Contributor Author

@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
Copy link

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
Copy link
Contributor Author

VladimirAlexiev commented May 18, 2021

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

@CraigRe CraigRe added agreed and removed needsGroupDiscussion Needs group discussion labels May 18, 2021
@RalphTro
Copy link
Collaborator

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
Copy link
Collaborator

mgh128 commented May 20, 2021

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
Copy link
Contributor Author

VladimirAlexiev commented May 20, 2021

@CraigRe

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"}
]
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"}
]
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
Copy link
Collaborator

RalphTro commented May 21, 2021

@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
Copy link

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
Copy link
Contributor Author

@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?)

Cheers!

@dr-shorthair
Copy link

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 opengeospatial/om-swg#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
Copy link
Collaborator

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
Copy link

dr-shorthair commented May 26, 2021

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
Copy link

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

I'll send you an invoice.

@RalphTro
Copy link
Collaborator

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
Copy link

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

@RalphTro
Copy link
Collaborator

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
Copy link
Member

Waving at @dr-shorthair :-)

@VladimirAlexiev
Copy link
Contributor Author

@RalphTro I edited my example #266 (comment) 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
Copy link
Collaborator

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
Copy link
Contributor Author

VladimirAlexiev commented Jun 17, 2021

Tasks and status as of 21 Sep 2021:

@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)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

7 participants