Collection id not added to base URL for OGC API Features

[dblodgett-usgs]

I scanned through open issues and didn't see anything that stood out to document this.

To reproduce, see:

https://radiantearth.github.io/stac-browser/#/external/reference.geoconnex.us/collections/hu10?f=json

go to one of the features and notice that the collection id is dropped:

https://radiantearth.github.io/stac-browser/#/external/reference.geoconnex.us/collections/items/0101000204

but if we add the collection id back we get:

https://radiantearth.github.io/stac-browser/#/external/reference.geoconnex.us/collections/hu10/items/0101000204

[m-mohr]

Has been identified as being a server issue, base self-link was incorrectly missing a trailing slash. See also https://github.com/radiantearth/stac-spec/blob/master/best-practices.md#consistent-uris

[dblodgett-usgs]

Maybe I'm missing something. I see that the stac browser is requesting the conformance document for the server and getting the collections from the server. It then shows the OGC API Features collections that are compatible with the STAC API as if they will work. A user navigates into what they expect to work and get an error.

It seems like we should be able to use conformance / openapi to determine how to deal with trailing slashes in the case that we are dealing with OAF items vs STAC items. Is this not possible?

[m-mohr]

No. How to handle trailing slashes is not determined by an OpenAPI document. It is defined by the IETF and you have to follow it if you want to be STAC compliant. I'm not sure how conformance classes relate to this.

[dblodgett-usgs]

OK, so since the conformance section of the OGC-API in question does not state that the API is STAC compliant, shouldn't that trigger a more nuanced approach to trailing slashes? Should there be a way to declare that the server is STAC compliant to avoid trying to represent OGC-API Features as if it were a STAC catalog?

I'm having a hard time following your hard stop attitude to trailing slashes here.

[m-mohr]

This has nothing to do with STAC or me. STAC doesn't require trailing slashes, but then you need to provide your relative links differently.

This is defined by IETF RFC 1808 (ch. 4) and RFC 3986 (ch. 5) and also applies to OGC standards. We just follow the standard and use URI libraries that follow that standard, no attitude here. Please inform yourself first before attacking me, who provides you with free support and free software.

[dblodgett-usgs]

Apologies for the impression that I'm being negative toward you -- I did not intend to come off that way.

It seems that there is confusion about implementation of links in OGC-API Features. I see that you've engaged over in the issue I linked above. Thanks.

[dblodgett-usgs]

OK, I tracked this down to this.

This gets called https://github.com/radiantearth/stac-browser/blob/main/src/store/index.js#L851

url = Utils.toAbsolute(`items/${item.id}`, baseUrl);

and makes its way down to this: https://github.com/radiantearth/stac-browser/blob/main/src/utils.js#L151

If baseUrl there has a / at the end, urijs.absoluteTo returns the value of baseUrl otherwise, it strips the basename of the path as would be expected.

But in this case, since items/$item.id} is a relative URL constructed in code and baseUrl may not have been constructed expecting that it would be used as a baseUrl in this way.

I'm not going to claim to know how to fix the issue, but this does seem to be what's going on that's causing the trip up.