typos

Author: letmaik

custom-fields.md

@@ -1,6 +1,6 @@
 # Custom Fields
 
-Custom fields are typically used to add information that it is not (yet) covered by the CoverageJSON specification.
+Custom fields are typically used to add information that it is not covered by the CoverageJSON specification.
 An example would be to add fields for the publisher, license, and publication date.
 
 If you don't care much about interoperability or field name clashes with future versions of the format,

custom-types.md

@@ -4,7 +4,7 @@ CoverageJSON has several extension points where it allows you to use a custom *t
 In the following we walk through each of those extension points using simple examples.
 At the end you should feel comfortable inventing your own types.
 
-As for custom fields (see previous page), if you don't care much about interoperability or type name clashes with future versions of the format, then the easiest way to use custom types is to use a new simple name (e.g. replacing "Grid" by "MyGrid").
+As for custom fields (see previous page), if you don't care much about interoperability or type name clashes with future versions of the format, then the easiest way to use custom types is to use a new simple name (e.g. replacing `"Grid"` by `"MyGrid"`).
 This is fine if you don't intend to share your data more widely and you have control over all clients that make use of the data.
 
 In the following we focus on how to use custom types in a future-proof and interoperable way.
@@ -14,7 +14,7 @@ The CoverageJSON specification will never define a type with `"prefix:suffix"` f
 In order to establish a common understanding of extensions and to be able to easily combine them in one document, prefixes should be registered.
 Registration is not bound to any restrictions or obligations. The site <https://covjson.org/prefixes/> shows already registered prefixes and has instructions on how to add a new one (which amounts to a simple GitHub pull request).
 
-If you're into linked data and RDF, then consider having a look at the [JSON-LD section](http://covjson.org/spec/#json-ld) of the spec. 
+If you're into linked data and RDF, then consider having a look at the [JSON-LD section](https://covjson.org/spec/#json-ld) of the spec. 
 
 ## Custom domain type
 
@@ -48,7 +48,7 @@ Example:
 }
 ```
 
-Instead of the compact URI `uor:Transect` we could also have used an absolute URI, like `http://example.com/covjson-Transect`. This can make sense if there is no namespace as such and the concept is not part of a set of concepts. Publishers should decide for one variant and then stick to it -- this makes client development easier.
+Instead of the compact URI `uor:Transect` we could also have used an absolute URI, like `http://example.com/covjson-Transect`. This can make sense if there is no namespace as such and the concept is not part of a set of concepts. Publishers should decide for one variant and then stick to it - this makes client development easier.
 
 ## Custom axis value data type
 
@@ -82,8 +82,8 @@ Example:
 }
 ```
 
-Here, `uor:multiPolygon` defines that each axis values is a GeoJSON MultiPolygon (the `"coordinates"` of it).
-Instead of the compact URI `uor:multiPolygon` we could also have used an absolute URI, like `http://example.com/covjson-multiPolygon`. This can make sense if there is no namespace as such and the concept is not part of a set of concepts. Publishers should decide for one variant and then stick to it -- this makes client development easier.
+Here, `uor:multiPolygon` defines that each axis value is a GeoJSON MultiPolygon (the `"coordinates"` field of it).
+Instead of the compact URI `uor:multiPolygon` we could also have used an absolute URI, like `http://example.com/covjson-multiPolygon`. This can make sense if there is no namespace as such and the concept is not part of a set of concepts. Publishers should decide for one variant and then stick to it - this makes client development easier.
 
 ## Custom reference system type
 
@@ -111,7 +111,7 @@ Example:
 
 In the example above, `uor:HEALPixRS` refers to [HEALPix](http://healpix.jpl.nasa.gov/) which is a type of [geodesic discrete global grid system](https://en.wikipedia.org/wiki/Discrete_Global_Grid) (sometimes just called geodesic grid). Different to longitude/latitude or projected systems, grid cell indexing works in a 1D space. Also note that three additional custom fields are used to fully define the reference system.
 
-Instead of the compact URI `uor:HEALPixRS` we could also have used an absolute URI, like `http://example.com/healpix`. This can make sense if there is no namespace as such and the concept is not part of a set of concepts. Publishers should decide for one variant and then stick to it -- this makes client development easier.
+Instead of the compact URI `uor:HEALPixRS` we could also have used an absolute URI, like `http://example.com/healpix`. This can make sense if there is no namespace as such and the concept is not part of a set of concepts. Publishers should decide for one variant and then stick to it - this makes client development easier.
 
 ## Custom unit symbol type
 
@@ -141,7 +141,7 @@ Example:
 
 Here, `uor:UDUNITS` refers to the coding scheme of the [UDUNITS](http://www.unidata.ucar.edu/software/udunits/) software package. This scheme is also the official one used by the popular [CF Conventions](http://cfconventions.org/).
 
-Instead of the compact URI `uor:UDUNITS` we could also have used an absolute URI, like `http://example.com/udunits`. This can make sense if there is no namespace as such and the concept is not part of a set of concepts. Publishers should decide for one variant and then stick to it -- this makes client development easier.
+Instead of the compact URI `uor:UDUNITS` we could also have used an absolute URI, like `http://example.com/udunits`. This can make sense if there is no namespace as such and the concept is not part of a set of concepts. Publishers should decide for one variant and then stick to it - this makes client development easier.
 
 ## Custom range type (or: Custom type in custom fields)
 
@@ -177,7 +177,7 @@ Example:
         "axisNames": ["y","x"],
         "shape": [180, 360],
         "uor:channel": 0,
-        "url": "http://example.com/data.tiff"
+        "uor:url": "http://example.com/data.tiff"
       }
     }
   }
@@ -187,4 +187,4 @@ Example:
 In the example above, two alternative range encodings are provided, one based on a [DAP 2](http://opendap.org/documentation) endpoint, the other on TIFF images.
 The `uor:dap` and `uor:tiff` fields provide a convenient entry point to the alternative encodings. Within those custom fields, the `uor:DAP2NdArray` and `uor:TIFF2DArray` types define the actual range type, of which there may be more than one for a given entry point (similar to the built-in `NdArray` and `TiledNdArray` types).
 
-Instead of the compact URIs `uor:DAP2NdArray` and `uor:TIFF2DArray` we could also have used absolute URIs, like `http://example.com/covjson-DAP2NdArray`. This can make sense if there is no namespace as such and the concept is not part of a set of concepts. Publishers should decide for one variant and then stick to it -- this makes client development easier. In the examples above, compact URIs make more sense though, as there are custom fields which likely would belong to the same namespace.
+Instead of the compact URIs `uor:DAP2NdArray` and `uor:TIFF2DArray` we could also have used absolute URIs, like `http://example.com/covjson-DAP2NdArray`. This can make sense if there is no namespace as such and the concept is not part of a set of concepts. Publishers should decide for one variant and then stick to it - this makes client development easier. In the examples above, compact URIs make more sense though, as there are custom fields which likely would belong to the same namespace.

extensions.md

@@ -1,7 +1,7 @@
 # Extensions
 
 Although the specification tries to cover many common scenarios, there may be situations when this is not enough.
-Fortunately, CoverageJSON privides mechanisms to extend any document in a well-defined manner.
+Fortunately, CoverageJSON provides mechanisms to extend any document in a well-defined manner.
 In this section you will learn how easy it is to do just that.
 
 ## Use cases