3.1 API Interface Structure

The database behind EPSG.ORG implements a subset of the data model described by ISO 19111:2019, omitting temporal and parametric CRSs, with some extensions to include metadata. The API interface is divided into individual endpoints based on the types of the data elements contained in the EPSG database. As such the endpoints have been given names that should be easily translated into tables in the data model. The endpoints are listed on the Swagger page for the application programming interface (API).

As such elements of different sub-type but supported by the same database table have been separated. The main reason for this is that we can then guarantee the structure of the returned data from the endpoints and secondly, the data model is splitting the elements even though the database implements collated tables, e.g., the table CoordinateReferenceSystems keeps all CRSs in one table even though the subtypes different attributes. The CoordinateReferenceSystem table implements all the classes shown in Figure 11 from CRS and down. The API in difference, implements the same UML diagram more through separate endpoint for {Geodetic, Projected, Engineering, Derived, Vertical} coordinate reference systems:

The Derived CRS class is handled differently from the ISO model in that the DerivedCoordRefSystem endpoint is representing only the derivedProjectedCRS class.

It should be noted that the endpoint CoordRefSystem is a collective endpoint that serves all coordinate reference systems. This means that a search on CoordRefSystem returns all types of coordinate reference systems and that the export function resides on this endpoint too. It is possible to search on each element type endpoint, but the export function is only present at the intermediate top level CoordRefSystem, representing the CRS class in the UML diagram (see Figure 11). Individual elements need to be retrieved at their respective matching endpoint.