Merge pull request #157 from agiorguk/nmtoken-patch-1

Update verticalextent.asciidoc

docs/partials/verticalextent.asciidoc

@@ -50,7 +50,7 @@ specified coordinate reference system
 for the vertical extent measurements. This should be recorded as a name
 or as a code, for example as provided in the EPSG Geodetic Parameter
 Registry produced by The International Association of Oil & Gas
-Producers (see http://www.epsg-registry.org/)
+Producers (see https://epsg.org/)
 
 |Comment |This element should be used only where vertical extent is
 significant, e.g. in geology, mining, meteorology etc.
@@ -60,7 +60,7 @@ significant, e.g. in geology, mining, meteorology etc.
 * Maximum value: 0.0
 * Coordinate reference system: height in metres above Newlyn Datum
 
-|Revision date |March 2019
+|Revision date |July 2024
 |===
 
 .Corresponding element in other standards...
@@ -131,7 +131,7 @@ the zero reference) and the units of the coordinate values.
 (Example One) or by value (Example Two). These examples express the same
 information: that the vertical extent coordinates are referenced to
 Ordnance Datum (Newlyn). Codes and GML CRS data are from the
-http://www.epsg-registry.org/[EPSG Registry].
+https://epsg.org/[EPSG Registry].
 . Additionally, the gco:nilReason attribute can be used if the vertical
 CRS is unknown (Example Three) but this renders the vertical extent
 information ambiguous at best. Consequently it would be better to
@@ -178,4 +178,4 @@ include::../snippets/extent-verticalcrs-unknown.xml[]
 [%collapsible]
 ====
 No error information available
-====
+====