CSAPI tests failing

[tomkralidis]

As per #1012 (comment), looks like the server in the unit tests is offline.

@ChainReaction31 can you help here (given #928)? Thanks (cc @Sam-Bolling).

[tipatterson-dev]

@tomkralidis sorry for lack of response on my end. I will get a fix for the tests pointed to a newer test server. That instance was removed a while back in a cleanup and relocated. There should be a replacement already available that I can aim the tests at.

[Sam-Bolling]

@tomkralidis sorry for lack of response on my end. I will get a fix for the tests pointed to a newer test server. That instance was removed a while back in a cleanup and relocated. There should be a replacement already available that I can aim the tests at.

Greetings, @tipatterson-dev. As an interested stakeholder of this activity, I am excited to see this movement! I do have a potential request for you to consider that aligns closely with this task. Essentially, we would like to validate that a generic OGC API - Features client (for example, a QGIS client without a plugin) can connect to an OGC API - Connected Systems server without any issues, extra effort, and work as intended out of the box. With a couple of generic OGC API - Features clients, we tried connecting to https://api.georobotix.io/ogc/t18/api/ that was referenced by the official OGC API - Connected Systems OAS definition yaml file but were unsuccessful. In discussion with GeoRobotix, we learned that the link was outdated and was marked for removal.

When you resolve this OWS Lib Issue 1013, can you also help us validate that a generic OGC API - Features client can connect to the OGC API - Connected Systems server?

Respectfully,

Sam

[geographika]

@tomkralidis sorry for lack of response on my end. I will get a fix for the tests pointed to a newer test server. That instance was removed a while back in a cleanup and relocated. There should be a replacement already available that I can aim the tests at.

@tipatterson-dev - to ensure long-term CI robustness, would you be able to capture the output from the live server and create a test using pytest_httpserver (see for example https://github.com/pvgenuchten/OWSLib/blob/9808cc0620fa28f11152792e6032f2136eb86c59/tests/test_csw_inspire.py) or the older monley-patching approach (see for example https://github.com/KaiVolland/OWSLib/blob/efa6c201b6cf2b33e281b9887b6594cefcaf3cee/tests/test_wfs_schema_arcgis_server.py)?

[tipatterson-dev]

Greetings, @tipatterson-dev. As an interested stakeholder of this activity, I am excited to see this movement! I do have a potential request for you to consider that aligns closely with this task. Essentially, we would like to validate that a generic OGC API - Features client (for example, a QGIS client without a plugin) can connect to an OGC API - Connected Systems server without any issues, extra effort, and work as intended out of the box. With a couple of generic OGC API - Features clients, we tried connecting to https://api.georobotix.io/ogc/t18/api/ that was referenced by the official OGC API - Connected Systems OAS definition yaml file but were unsuccessful. In discussion with GeoRobotix, we learned that the link was outdated and was marked for removal.

When you resolve this OWS Lib Issue 1013, can you also help us validate that a generic OGC API - Features client can connect to the OGC API - Connected Systems server?

Respectfully,

Sam

@Sam-Bolling Once the new server is up, you should be able to validate against it. I am working on updating our implementation today to fix some non-compliant parts that came from a pre-release version.

I will speak to Chris Tucker and Alex Robin about helping out with this more actively so we can make sure that it's nothing server-side holding you back.

Ian

[tipatterson-dev]

@geographika I think I can get around to writing mock results for the pytest server once I am freed up from more of my current obligations. The tests have to be modified anyway since a new server won't provide the same resource ids as the old one would.

[Sam-Bolling]

Greetings, @tipatterson-dev. As an interested stakeholder of this activity, I am excited to see this movement! I do have a potential request for you to consider that aligns closely with this task. Essentially, we would like to validate that a generic OGC API - Features client (for example, a QGIS client without a plugin) can connect to an OGC API - Connected Systems server without any issues, extra effort, and work as intended out of the box. With a couple of generic OGC API - Features clients, we tried connecting to https://api.georobotix.io/ogc/t18/api/ that was referenced by the official OGC API - Connected Systems OAS definition yaml file but were unsuccessful. In discussion with GeoRobotix, we learned that the link was outdated and was marked for removal.

When you resolve this OWS Lib Issue 1013, can you also help us validate that a generic OGC API - Features client can connect to the OGC API - Connected Systems server?

Respectfully,

Sam

@Sam-Bolling Once the new server is up, you should be able to validate against it. I am working on updating our implementation today to fix some non-compliant parts that came from a pre-release version.

I will speak to Chris Tucker and Alex Robin about helping out with this more actively so we can make sure that it's nothing server-side holding you back.

Ian

Thank you, greatly appreciated!

Respectfully,

Sam