2.1 Resolving Dependencies
Previous | Table of Content | Next |
2.1 Resolving Dependencies
As mentioned in the previous section, the data set structure is that described by ISO 19111:2019. What this means is that elements are divided into its describing sub-parts and the server will only resolve the top-level elements. Where a top-level element contains sub-level elements, links to resolve these are given by the system.
As an example, the Datum data returned for ED50 (6230), see Figure 3, contains sub elements "Ellipsoid" and "PrimeMeridian". Names and codes are given but further attributes of the sub-elements needs to be data mined using the links highlighted in Figure 2.
"Ellipsoid": { "Code": 7022, "Name": "International 1924", "href": "https://apps.epsg.org/api/v1/Ellipsoid/7022" }, "PrimeMeridian": { "Code": 8901, "Name": "Greenwich", "href": "https://apps.epsg.org/api/v1/PrimeMeridian/8901" }, |
Figure 2 - Sub-elements to ED50 datum.
Retrieving the data for the Ellipsoid, see Figure 4, shows that the Ellipsoid contains a further sub element, the Unit as seen below in Figure 5.
"Unit": { "Code": 9001, "Name": "metre", "href": "https://apps.epsg.org/api/v1/Unit/9001" }, |
Figure 5 – Unit sub-element. |
Therefore, fully resolving a top-level element such as a projected CRS, a transformation or a concatenated operation can result in multiple calls and thus because of latency take quite a long time. It is also then using resources from the registry server unnecessary as caching the data returned would speed up the operation considerably. Caching is recommended as the dataset is very static and will only ever change when the IOGP makes a new registry release.
It is therefore considered good practise to cache locally and only retrieve that which is absolutely needed.
Previous | Table of Content | Next |