Terminology alignment
I suggest various changes to the text and API to align with ISO 19111 terminology where possible, even though it is understood that the text has a vintage and is intended for non-specialist. After a quick read the following changes are suggested; which may need to be made also in other parts (e.g., in engine API i/o or help text)
-
It says "Latitude and longitude are measured in plane angles (spherical coordinate system - wiki). Since th… Suggest we avoid links to wikipedia, but more importantly these are not spherical. Geodetic lat and lon are ellipsoidal. Geocentric lat and lon are something too as well as astronomical lat and lon. This would be way too much for first paragraph to get into.
Suggest to replace the link with (unfortunately perhaps still wikipedia:)) https://en.wikipedia.org/wiki/Latitude -
It says "With the introduction of satellites, one world-wide approximation has been defined, which is the World Geodetic System of 1984 (WGS 84). This is the reference used in the Global Positioning System. WGS 84 is still a mathematical approximation. Over time, plate tectonics moves the continents under the ellipsoid. At the moment, the relative shifts are in the order of normal GPS resolution, but will accumulate further over time. Eventually the geospatial references will become time dependent. The current catalog does not contain any time-dependent elements yet." Suggest this should be reviewed. The point is that coordinates are never in "WGS 84" but in a (national) static CRS or potentially offshore in surveyed in a specific dynamic CRS realization such as ITRF2014. This is not solved by adding time-dependent transformations but by storing data in the original CRS (possible a specific dynamic CRS realization and with coordinate epoch) and when transformed to "WGS 84" for analytics or global mapping to keep track of the transformation used or accept 1-2m "fuzz". Since I also do not know good words right now I suggest to add a link to IOGP Guidance Note for further reading: https://www.iogp.org/bookstore/product/geomatics-guidance-note-25-dynamic-versus-static-crss-and-use-of-the-itrf/
-
In various places for historic reason CT is used as Cartographic Transformation. In the ISO 19111 model there are coordinate operations, and one of those when a datum changes is Coordinate Transformation. Suggest to replace all occurrences somehow.
-
There is some text that states that the choice of transformation is the task of geodesist and ordinary people cannot make such decisions. I see a link with early-binding here; where I still advocate a late-binding data model. The difference is not in who makes that choice necessarily, but more in the pre-definition and book keeping. For example the CT to use can be stored as property and instead of the data loader selecting an EB CRS, he or she would select the (LB) CRS and a CT to WGS 84 for ingestion. I don't see the difference for responsibility, except that with the EB CRS we need to maintain an additional layer of geodetic definitions. And when data is transformed not to WGS 84 but to some other CRS, e.g., GDA94 to GDA2020 if not having the notion it must go through WGS 84 then a better transformation can be selected. However, this is just a comment to perhaps rephrase somewhat, again, I do not have the words ready.
In my view (in ISO 19111) a CRS is LB, so there is no need to say that. I can understand that it is specified for full clarity. but in the API and documentation I would expect to get (LB) CRSs back if I get CRSs and BoundCRSs if I ask for BoundCRSs. The current api description seems to have getCRS for all objects and getLBCRS for LB and getEBCRS for EB. I'd argue there would be only 2 functions, one for getCRS (LB by definition) and one for getEBCRS. There could be an issue with that. If WGS 84 based systems are not seen as EB then they would be missed out in a dropdown if EB would be used. But there could be a function to get all projCRS, all geog2DCRSs, and all EB CRS. There is some discussion here needed perhaps but my feeling is not to mix and match EB with LB. Also the EPSG v10 model may have boundCRS as an empty defined type of CRS, which might argue that they should be returned as CRS.
- There are definitions of singleCT and compoundCT which I do not quite understand in detail. However, in ISO 19111 there is a term "concatenated operation". This can be a multi-step transformation path defined with a single code. Hence I first thought it was a mistake like compoundCRS, compoundCT, not realizing it is concatenatedCT. But then I read a little but further and see a policy of 'fallback' and 'concatenated'. I suggest that the usage of compoundCT should be reviewed if appropriate, and since the policy is not clear to me that some example should be given (e.g., it reads as if a list of transformations are given between two datums and they are tried for a point or list of points until an appropriate one is found. In itself that is a method, i.e., if the polygon area of use would be used.)
Suggest a reference to following could be included in the documentation http://docs.opengeospatial.org/as/18-005r4/18-005r4.html
-
lon_min vs. longitudeLeft vs. westboundlongitude, etc a. Suggest the example should use fractional with 2 decimal places (there is an example using “100” for example). EPSG policy has been to use 2 decimal places for BBOX and 5 for polygon nodes though the new system may have some issues still in this regard that are being resolved. b. api shows "lon_min", etc. This has an issue with a bbox spanning the antimeridian in the sense the smaller value longitude in decimal degrees in interval <-180,+180]. On the page is a section “BoundBox” which show “lon_min” which is not aligned. Suggest remove all min/max and replace with "longitudeRight", etc. as used in other parts of the page. c. And although longitudeRight is clear to people I presume, in EPSG this is eastboundlongitude etc. Hence we may want to rather align with "east/west/north/south" rather than "right/left/up/down". Since the referenced CRS is WGS 84 for the BBOX, I do think the bound most on the right is unambiguously for the most east.
-
usage of "Authority" I know in ESRI flavor of WKT v1 this word is used. In ISO WKT I think this is called ID which is the data source and the code, or what we called codespace and code (together making the identifier) in the concept architecture document. I tried to check in the ISO whether this is called issuer or codespace or database (i.e., EPSG is not the authority of a national CRS definition; that would be a national agency, but EPSG database would be the data source, where the national agency is the information source). It seems ISO 19111 used “Identifier” and I always say that as “EPSG::4326” where the empty space between colons is the database version. It refers in section 8 to ISO 19115-1:2014 which I don’t know. Suggest a consistent way of doing this. https://epsg.org/crs/wkt/id/32065 has it as "ID["EPSG",32065]]
-
Essence. I did not understand from the description what essence is or what it is for. I think it is kind of a subset of practical information, but not as "light" as just a name, a code and unit. Is it planned at some point to call the engine with ID only implicitly, or would still always an explicit definition be send to the engine?