Human-readable "Region name" for bbox/geometry?

[m-mohr]

What do others think about a free-form text field that encodes a "region" name for the given bbox or geometry? For example if you cover the island of Hawaii, you could include the human-readable name "Hawaii" in addition to the bbox/geometry.

We've seen this in some extensions like https://github.com/stac-extensions/osc and https://github.com/stac-extensions/noaa-mrms-qpe where the extensions define a specific set of region names for the given location.

Does this make sense?

[gadomski]

So I've thought about this sort of thing before, and I've come to the conclusion that I think title should be an optional field on Item. That way, we keep the same field name as the other structures, and some existing data might Just Work™ (I think I've seen items with titles before in the wild). We could have text in the spec that says "the title, if provided, should describe the geographic region of the Item" or something like that.

By keeping the same name (title), it lets tooling look for the same attribute when building nice representations of a generic STAC object, as well.

[m-mohr]

I don't think I agree. The NOAA MRMS QPE would just have 5 or 6 titles for thousands of items, that doesn't lead to a very good UX, I think.

By the way, title on Items exists and is optional.

[gadomski]

I don't think I agree. The NOAA MRMS QPE would just have 5 or 6 titles for thousands of items, that doesn't lead to a very good UX, I think.

Fair enough :-).

By the way, title on Items exists and is optional.

I don't see it here: https://github.com/radiantearth/stac-spec/blob/master/item-spec/item-spec.md#item-fields

[m-mohr]

@gadomski Common Metadata - Basics: https://github.com/radiantearth/stac-spec/blob/master/item-spec/common-metadata.md#basics

[gadomski]

Huh ... yeah I guess I've been relying on those top-level tables to enumerate the fields available. I wouldn't be surprised if others miss the common metadata stuff, or mis-apply it (e.g. I see a lot of STAC in the wild w/ license on every item, even though it doesn't change). But this is off-topic for this issue, apologies...thanks for pointing that out.

[m-mohr]

Thanks for your thoughts anyway!

(re license: I think some people like to explicitly state their license in all files just to make sure everybody sees it) (re common metadata: Yeah, I also think people may miss it altough we really tried to highlight it)

[constantinius]

I think the region, if adopted, would also make sense on Catalog/Collections. There it would clash with title imho as a descriptive name.

[m-mohr]

The catalog has no spatial reference so a name for geometry/bbox doesn't really apply. It would make sense for Collections, but what's the use case on Catalogs? You can't search Catalogs anyway.

[emmanuelmathot]

Shouldn't it be put in a structured keyword such as proposed in subjects extensions?

[m-mohr]

@emmanuelmathot Interesting idea, I think this could also work (although a bit less easy to use in search, I guess?).

[emmanuelmathot]

Yes indeed. A simple common region could be useful for search but I think it should be regions to have the possibility to define different administrative levels. My proposal to use subjects is to cover further requests such as country or city or any other administrative division. Geonames has done the normalization job and this is very efficient for both free text and structured search

[m-mohr]

Closing in favor of the https://github.com/stac-extensions/subjects extension as you'd anyway need to define a vocabulary that is used for the names.