Enforce setting id, title and description?

[m-mohr]

Not sure whether this is the right place, but out there are tons of APIs that identify themselved in production as "stac-fastapi" in landing page id, title and description, leading to such weird STAC Browser renderings for many different APIs:

Is there a way to enforce setting those values so that people can't just be lazy and all expose such nonsense values for their APIs? That's a big discovery issue that's currently somewhat mitigated by STAC Index, but should probably be solved here...

[vincentsarago]

That will be an important breaking change 😬

We can certainly add a note in the readme 🤷. From stac-fastapi POV, I don't see why we would need to require this.

stac-fastapi/stac_fastapi/types/stac_fastapi/types/config.py

Lines 24 to 27 in 442b851

	stac_fastapi_title: str = "stac-fastapi"
	stac_fastapi_description: str = "stac-fastapi"
	stac_fastapi_version: str = "0.1"
	stac_fastapi_landing_id: str = "stac-fastapi"

[jonhealy1]

This would be difficult to enforce. We could add a random hexadecimal string on the title so it could say something like: stac-fastapi-0x465Gegwjs389jdeJKL333 or something like that, but I don't think this would improve anything haha. A note in the readme and then the same on the more popular stac-fastapi implementations would be the best.

[jonhealy1]

@vincentsarago what do you think about logging something to let people know that not changing the defaults could hurt discoverability?

[vincentsarago]

@jonhealy1 sounds good to me. I would also be ok adding a random key to the values

[m-mohr]

Adding a random key doesn't really help with discoverability that much as then it's just equally confusing that these values mean.

Adding a strong recommendation in the docs in a central place, showing how to change the values (e.g. also through ENV?) and logging a warning if the values are still the default would be a good start.

Why is it difficult to enforce though? Don't provide a default at all and error at startup when no values have been set as it would generate an invalid STAC ;-) Certainly breaking, but not impossible, or?

(Sidenote: I may force APIs to change this in the future in STAC Index by reading those information automatically into the database without a way to override it as it is now, which would then lead to a STAC Index with a lot of "stac-fastapi" APIs. This may force people to change it, but also leads to a period where the Index is less useful.)

[vincentsarago]

Why is it difficult to enforce though?

Because it is a breaking change.

Adding a strong recommendation in the docs in a central place, showing how to change the values (e.g. also through ENV?) and logging a warning if the values are still the default would be a good start.

This is already configurable through Env and already documented https://stac-utils.github.io/stac-fastapi/tips-and-tricks/#set-api-title-description-and-version

Certainly breaking, but not impossible, or?

We can certainly do this for v7.0

@m-mohr, how does someone register an API to the index? If it's on user demand then you can tell the user to change this instead of asking the library to change. Also could you ask the users to set a name on your system instead of relying on the values provided by the API itself?

[m-mohr]

This could be a step-by-step approach: Warn in 6.x, Require in 7.x.

I'm aware that this is configurable, I actually think I was involved some time ago to add this to the docs. Effectively, it seems people don't do it. I just had a very brief look: Out of all the APIs (incl. non stac-fastapi), 10+ (couldn't check all) have still stac-fastapi set in the ID or so. I'd assume thats about half of all stac-fastapi instances indexed in STAC Index. Which effectively means people seem to either not care or not find the information.

@vincentsarago STAC Index: Currently, you register it manually via a form on stacindex.org, where you provide title, description, etc. manually. As this comes with a maintenance burden, we plan to retrieve these information from the actual catalogs/APIs directly. In this case the whole stac-fastapi issue becomes much more obvious and prominent to everyone. Of course we can also warn there when submitting, but I think this is effectively an issue of stac-fastapi and should be tackled here, not downstream. The issue also occurs in other places, e.g. STAC Browser. It also seems to surface in pystac-client in certain cases, seer https://pystac-client.readthedocs.io/en/stable/tutorials/stac-metadata-viz.html (note: here's it's correct as Microsoft set it, but other servers would just return confusing information, all set to stac-fastapi in the output)

[jonhealy1]

We override these default values in SFEOS app.py

app_config = {
    "title": os.getenv("STAC_FASTAPI_TITLE", "stac-fastapi-elasticsearch"),
    "description": os.getenv("STAC_FASTAPI_DESCRIPTION", "stac-fastapi-elasticsearch"),
    "api_version": os.getenv("STAC_FASTAPI_VERSION", "6.19.0"),

and then again in our compose.yml

services:
  app-elasticsearch:
    container_name: stac-fastapi-es
    image: stac-utils/stac-fastapi-es-os
    restart: always
    build:
      context: .
      dockerfile: dockerfiles/Dockerfile.dev.es-os
    environment:
      - STAC_FASTAPI_TITLE=stac-fastapi-elasticsearch
      - STAC_FASTAPI_DESCRIPTION=A STAC FastAPI with an Elasticsearch backend
      - STAC_FASTAPI_LANDING_PAGE_ID=stac-fastapi-elasticsearch