search

EMODnet / emodnet.wfs

Access EMODnet Web Feature Service data through R
https://emodnet.github.io/emodnet.wfs/
Other
8 stars 4 forks source link

explore wfs biology_new_data_products #154

Closed maelle closed 8 months ago

maelle commented 1 year ago

it seems it's not ready? @salvafern it's in the text file you created, but .emodnet_get_wfs_info() fails on it because there are no layer names?

maelle commented 1 year ago

this raises an issue: if we read the text file directly from GitHub, and a new service is added, we might inadvertently a "not ready" service to users of the R packages.

should EMODnetWFS contain a list of service names, so we can filter services that we've already tried with the R package? For now I have a "manual" exclusion of "biology_new_data_products" for instance, but instead we might want to exclude any service that's not in a list of known services.

salvafern commented 1 year ago

I overlooked that one :/ I just turned the markdown tables in the README into txt files.

This service in particular it is because we are uploading some of the data products of emodnet biology to the emodnet geoserver instead of the VLIZ one. But only some due to technical constrains. ~It should work eventually tho.~ edit: currently we add here only raster data, no vector. See https://github.com/EMODnet/EMODnetWFS/issues/154#issuecomment-1504994073

should EMODnetWFS contain a list of service names, so we can filter services that we've already tried with the R package?

I agree. Maybe a CI/CD check that tries every new service added to the list - and raises a github issue if it fails?

maelle commented 1 year ago

I added an internal function curated_services() with the services we currently "know".

Would there be a simpler way to follow services being added to the fleet, so they can be tested?

And regarding this service in particular, when do you think it will work, and how should we document how it differs from/complements the other biology service?

maelle commented 1 year ago

I'm looking for a simpler way because I'm not sure we're expecting that many new services? And hopefully the new services are advertised somewhere, maybe a newsletter, mailing list?

salvafern commented 1 year ago

However with curated_services() we come back to having a hard coded list of services, don't we? I don't have a good solution tho. Maybe a test that checks new services?

Regarding biology_new_data_products I have news :). In this phase IV we are not adding any vector data to this service, but instead all the products are served as raster via netcdf stores. When we have data products as vector data, we are adding them in the vliz geoserver. This is the current state due to technical reasons. Ideally we would serve all data from only the emodnet geoserver, and hopefully we will get there at some point.

But for now biology_new_data_products has no purpose for EMODnetWFS since there is no vector data, and no purpose either in the list of web services imo. I raised it here: https://github.com/EMODnet/Web-Service-Documentation/commit/86df44c5e9fbacf7ebbbbf6abaf38dd0ddc3f6d0#r108593181

maelle commented 1 year ago

However with curated_services() we come back to having a hard coded list of services, don't we?

yes but their URLs are not hard coded. :sweat_smile:

I still think that instead of having an automated system, the most important thing is ensuring a human looks for new services "once in a while", when preparing a new package release, or when getting notified of a new service in a mailing list. Are new services announced somewhere else than the documentation repo? :thinking: