re: CLI name. I imagine still calling it
ghc is risky enough? GeoHealthCheck doesn’t bother me too much but not sure about others. @justb4 / @archaeogeek ?
re: CLI name. I imagine still calling it
ghcis risky enough?GeoHealthCheckdoesn’t bother me too much but not sure about others. @justb4 / @archaeogeek ?
Yes ghc is Haskell-related. Always short commands and lowercase on Unix (he, I worked for the company that invented ls and cd, and C!), hence my suggestion for geohc. (Still need to go through PR & comments, but this was easy to answer).
There is an error popping on when running the resource tests of GHC with respect to pygeoapi. It does not validate the OpenAPI Compliance with this error:
I didn't dive into this yet, but was there a change with the specs or pygeoapi, or is this a big of GHC ?
GeoHealthCheck.probe - INFO - Result: success=False msg=Validate OpenAPI Compliance:HTTP Error 404: Not FoundI didn't dive into this yet, but was there a change with the specs or pygeoapi, or is this a big of GHC ?
Finally tracked it down I think: read here: opengeospatial/wps-rest-binding#63 , thus looks like no GHC nor pygeoapi error...
here is a screenshot of the issue
Here is the network tab: https://imgur.com/5iEX0Qa
Proxy settings: https://imgur.com/4vtoQOr
its weird if i refresh it works, if i refresh again it breaks again
Hi there, I have a question about using geohealthcheck with docker, I'm not sure if it's an issue or if my understanding is at fault. My problem is that if I pass a SCRIPT_NAME environment variable with the docker run command, whatever path I include seems to get used twice. My run command is:
docker run -d --name ghc_web -p 8083:80 -e SCRIPT_NAME=foo -v ghc_sqlitedb:/GeoHealthCheck/DB geopython/geohealthcheck:latest
... but then when I load the page at http://localhost:8083/foo then all the references in the page are to http://localhost:8083/foo/foo/?lang=en
If I don't include a SCRIPT_NAME variable then it loads as expected at http://localhost:8083, but unfortunately I need it to run in a sub directory
is this a bug or have I missed something in my understanding of how this should be working?
Well, first of all
SCRIPT_NAME is meant for the case where GHC is run behind a proxy like Apache or Traefik which you probably intend, though it should work in isolation as well. I remember this question came up before, and you contributed a nice piece of documentation for that case: https://docs.geohealthcheck.org/en/latest/install.html#running-under-a-sub-path . Is it maybe you forgot a slash i.e. /foo i.s.o. foo?
I can't get the nginx config to work (using my documentation from earlier :-) ) because it is creating the nested sub-directory. I have an older version (0.6 ish) working outside of docker with gunicorn and supervisord and that is working just fine and the nginx config ought to be the same
but... surely it should work in isolation (ignoring nginx) so adding a script name as an environment variable should not create the nested sub directory- it should just create one?
If I set -e SCRIPT_NAME=foo then the URLs are of the form http://localhost:8083/foo/foo/?lang=en when they should presumably be of the form http://localhost:8083/foo/?lang=en
ah- so docker run -d --name ghc_web -p 8083:80 -e SCRIPT_NAME=/foo -v ghc_sqlitedb:/GeoHealthCheck/DB geopython/geohealthcheck:latest seems to work
I'll try that in my server environment
Good day, I recently install GeoHealthCheck and I am in the process of adding resources. I have an error when I try to add probes to a WFS resource. For example, the probe WFS GetFeature in BBOX for ALL FeatureTypes give me an ‘Error getting Probe form for GeoHealthCheck.plugins.probe.wfs.WfsGetFeatureBboxAll’. The log error message says: ‘UnboundLocalError: local variable 'feature_type_entry' referenced before assignment’ for ‘crs_list = feature_type_entry.crsOptions’. I am using 0.8.dev0. Someone has an idea why I have this message? Thanks a lot!
Ok, I cannot reproduce on de demo.geohealthcheck.org site (runs latest
master) using a public WFS from the Dutch SDI: http://geodata.nationaalgeoregister.nl/bag/wfs . But I can see where it happens in the code. There a random feature type entry is fetched but it is appearantly empty (code should be more defensive though). I see two possible causes: 1) your WFS provides different options/encodings as e.g. the one above. Or 2) a mismatch with the OWSLib version you are using. So can you give the WFS URL you are using? And the OWSLib version?
I use OWSLib version 0.17.1. The WFS I use is password protected, there are no layers that can be accessed without being logged in. Is it possible that crs_list is done on an empty WFS (before authentication is performed)? I tried the public WFS from the Dutch SDI and it worked on my instance.
OWSLib 0.17.1 is ok (same as used on demo). The auth should not be the problem. All info is pared from the Capabilities doc, guess the Capabilities Probe works ok. As the public WFS URL works, there is something in the capabilities doc different. For one thing: I see that the WFS Probe fetches using WFS 1.1.0, could that be a problem (e.g. only 2.0.0 is supported). You may want to look into the Caps doc, it should read like:
The general structure of the GetCapabilities document is the same. However, I see a difference in the CRS. There are in my file 2 x ':' between EPSG and the code when there's only one in the public WFS from the Dutch SDI Caps. For example, '<DefaultCRS>urn:ogc:def:crs:EPSG::4326</DefaultCRS>'. I use GeoServer to publish data.