Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

A few grammar errors #1163

Merged
merged 3 commits into from
Feb 25, 2022
Merged

A few grammar errors #1163

Changes from all commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
4ecbabc
Merge pull request #1128 from radiantearth/dev
matthewhanson May 11, 2021
789e90f
Merge pull request #1139 from radiantearth/dev
cholmes May 25, 2021
d40bb30
a few grammar errors
jonhealy1 Dec 12, 2021
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
10 changes: 5 additions & 5 deletions best-practices.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -255,7 +255,7 @@ Both are compliant with OGC API - Features, adding richer search capabilities to
As [described in the Item spec](item-spec/item-spec.md#additional-fields-for-assets), it is possible to use fields typically
found in Item properties at the asset level. This mechanism of overriding or providing Item Properties only in the Assets
makes discovery more difficult and should generally be avoided. However, there are some core and extension fields for which
providing them at at the Asset level can prove to be very useful for using the data.
providing them at the Asset level can prove to be very useful for using the data.

- `datetime`: Provide individual timestamp on an Item, in case the Item has a `start_datetime` and `end_datetime`,
but an Asset is for one specific time.
Expand Down Expand Up @@ -283,7 +283,7 @@ providing them at at the Asset level can prove to be very useful for using the d
[Media Types](https://en.wikipedia.org/wiki/Media_type) are a key element that enables STAC to be a rich source of information for
clients. The best practice is to use as specific of a media type as is possible (so if a file is a GeoJSON then don't use a JSON
media type), and to use [registered](https://www.iana.org/assignments/media-types/media-types.xhtml) IANA types as much as possible.
The following table lists types that commonly show up in STAC assets. And the the [section](#formats-with-no-registered-media-type)
The following table lists types that commonly show up in STAC assets. And the [section](#formats-with-no-registered-media-type)
past that gives recommendations on what to do if you have a format in your asset that does not have an IANA registered type.

#### Common Media Types in STAC
Expand Down Expand Up @@ -729,7 +729,7 @@ database, but it could just as easily be a server-based process.

Any tool that crawls a STAC implementation or encounters a STAC file in the wild needs a clear way to determine if it is an Item,
Collection or Catalog. As of 1.0.0 this is done primarily
with the `type` field, and secondarily in Items with `stac_version`, or optionally the `rel` of the link to it.
with the `type` field, and secondarily in Items with `stac_version`, or optionally with the `rel` of the link to it.

```shell
if type is 'Collection'
Expand All @@ -744,8 +744,8 @@ else

When crawling a STAC implementation, one can also make use of the [relation type](catalog-spec/catalog-spec.md#relation-types
) (`rel` field) when following a link. If it is an `item` rel type then the file must be a STAC Item. If it is `child`, `parent` or
`root` then it must be a Catalog or a Collection, though the final determination between the two requires looking at the the `type` field
in the Catalog or Collection JSON that is linked to. Note that there is also a `type` field in STAC Link and Asset objects, but that
`root` then it must be a Catalog or a Collection, though the final determination between the two requires looking at the `type` field
in the Catalog or Collection JSON that it is linked to. Note that there is also a `type` field in STAC Link and Asset objects, but that
is for the Media Type, but there are not specific media types for Catalog and Collection. See the sections on [STAC media
types](catalog-spec/catalog-spec.md#media-types), and [Asset media types](item-spec/item-spec.md#asset-media-type) for more information.

Expand Down