Adding (content-)type to links about stac-spec

[cholmes]

Where's the section on WFS links? I'm definitely interested in consistency with them. And picked this style of rel links so that type could be possible. Does WFS require that all links have a type?

I'm not sure if there will be many cases with the 'rel' + type being the same. Hrm, except for if we do a 'source' and like a mosaic could have multiple 'source' files it refers to. Though what's the use case for the client to figure out the unique resources?

[joshfix]

FYI we do have a type property for links, it's just not required. See the swagger spec:

https://github.com/radiantearth/stac-spec/blob/dev/api-spec/spec.yaml#L200-L215

[cholmes]

Setting this for 0.6.0 - as I think there's growing need for this. I'm looking more at 'assets', but I think it'd be good for links too.

I think we also need to figure out types and 'sub-types', like tiff / geotiff, and then 'cloud optimized geotiff'.

It may next sense to enumerate the link and asset 'keys' so people know what the good options are (tif vs tiff vs geotiff).

[m-mohr]

WFS3 itself refers only to RFC5988, which itself is pretty imprecise:

The "type" parameter, when present, is a hint indicating what the
media type of the result of dereferencing the link should be. Note
that this is only a hint; for example, it does not override the
Content-Type header of a HTTP response obtained by actually following
the link. There MUST NOT be more than one type parameter in a link-
value.

Regarding content types and sub types for completeness and as "inspiration":
WPS 1.0 has a proposal on non-existing mime types/content types: http://www.opengis.net/doc/wps1.0-best-practice-dp - section 6. I am not suggestion to use it though, IMO it looks rather odd...

It might also be useful to add a title to the links as discussed in #81. This would be covered by RFC5988, too.

[mojodna]

Some WMS/WCS servers seem to use image/geotiff (and variants, see https://lists.osgeo.org/pipermail/gdal-dev/2006-April/008487.html) even it it's not standardized.

My inclination would be for something along the lines of:

image/geotiff; cloud-optimized=true; type=byte

Or, if we wanted to be strict about it:

image/tiff; georeferenced=true; cloud-optimized=true; type=byte

(This is highly relevant to STAC as it covers types other than COGs, but may actually belong in COG discussions.)

[jeffnaus]

Sprint-3-static

We want to support this.
We want to support our custom times which is
image/geotiff (lets get this really registered)
image/geotiff+cog

For other types we generally recommend that use standard mime types. including
the vendor prefix.
example: vnd.digitalglobe/til

[m-mohr]

Type and title are both available now for assets and links.