chapter 14 updated

core/standard/annex_ogc_wms.adoc

@@ -168,7 +168,7 @@ The new OGC API Standards emerged in a completely different context where most w
 
 Implementers of map clients are encouraged to implement support for OGC API Standards in addition to _OGC API - Maps_ to provide a functionality similar to _GetFeatureInfo_. Instead of building a request to a map point in map coordinates (I, J), implementers should use point narrow bounding boxes in CRS coordinates. For example:
 
-  * In _OGC API - Features_, map coordinates should be transformed to Lon,Lat WGS84 in the client side and implement a HTTP GET request to `/collections/{collectionId}/items?bbox=Lon,Lat,Lon,Lat`.
+  * In _OGC API - Features_, map coordinates should be transformed to Lon,Lat WGS84 in the client side and implement an HTTP GET request to `/collections/{collectionId}/items?bbox=Lon,Lat,Lon,Lat`.
   * In _OGC API - Coverages_, map coordinates should be transformed to native coordinates and use `/collections/{collectionId}/coverage?bbox=x,y,x,y` or the equivalent "subset" query.
   * In _OGC API - EDR_, map coordinates should be transformed to a CRS coordinates and use `/collections/{collectionId}/position?coords=POINT(x y)` or by adding a radius query `/collections/{collectionId}/radius?coords=POINT(x y)&within=20&within-units=km`.
 

core/standard/clause_13_map_paramSpatialSubsetting.adoc

@@ -117,7 +117,7 @@ and the same CRS unit to pixel unit scale regardless of the subset being request
 
 For implementations implementing both "Scaling" and "Spatial Subsetting" requirements classes, the scaling and subsetting parameters interact somewhat intricately.
 Guidance for implementers is provided in a <<overview-subsetting-and-scaling,section of the overview>> on these interactions,
-including the specific combinations of parameters that can be provided based on which requirements classes are implemented, and which parameter assume default values or should be computed in each case.
+including the specific combinations of parameters that can be provided based on which requirements classes are implemented, and which parameters assume default values or should be computed in each case.
 
 The "Scaling" requirements class also includes specific <<scaling-aspect-ratio,guidance for scale and aspect ratio considerations>>.
 

core/standard/recommendations/datetime/REC_actual-datetime.adoc

@@ -3,7 +3,7 @@
 [width="90%",cols="2,6a"]
 |===
 ^|*Recommendation {counter:rec-id}* |*/rec/datetime/actual-datetime*
-^|A |The server SHOULD add a HTTP header with `OGCAPI-datetime` as a name and a temporal geometry as a value, to indicate the instant or the temporal interval of the content of the resource. The temporal geometries value shall conform to the following syntax (using link:https://tools.ietf.org/html/rfc5234[ABNF]):
+^|A |The server SHOULD add an HTTP header with `OGCAPI-datetime` as a name and a temporal geometry as a value, to indicate the instant or the temporal interval of the content of the resource. The temporal geometries value shall conform to the following syntax (using link:https://tools.ietf.org/html/rfc5234[ABNF]):
 
 [source]
 ----
@@ -19,7 +19,7 @@ The syntax of `instant` is specified by link:https://tools.ietf.org/html/rfc3339
 ====
 [%metadata]
 identifier:: /rec/datetime/actual-datetime
-part:: The server SHOULD add a HTTP header with `OGCAPI-datetime` as a name and a temporal geometry as a value, to indicate the instant or the temporal interval of the content of the resource. The temporal geometries value shall conform to the following syntax (using link:https://tools.ietf.org/html/rfc5234[ABNF]):
+part:: The server SHOULD add an HTTP header with `OGCAPI-datetime` as a name and a temporal geometry as a value, to indicate the instant or the temporal interval of the content of the resource. The temporal geometries value shall conform to the following syntax (using link:https://tools.ietf.org/html/rfc5234[ABNF]):
 +
 [source]
 ----

core/standard/requirements/datetime/REQ_subset-definition.adoc

@@ -4,7 +4,7 @@
 ====
 [%metadata]
 identifier:: /req/datetime/subset-definition
-part:: A `subset` parameter with the following characteristics (using an Backus Naur Form (ABNF) fragment) SHALL be supported:
+part:: A `subset` parameter with the following characteristics (using an Augmented Backus Naur Form (ABNF) fragment) SHALL be supported:
 +
 [source,ABNF]
 ----