Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
Maxime Audet-Roberge
@audetrobergem
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!
Just van den Broecke
@justb4
Hmm, sounds like an old bug. Have you tried the latest master version?
Maxime Audet-Roberge
@audetrobergem
I think it is the latest master version, I installed it 2 weeks ago from git.
Just van den Broecke
@justb4
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?
Maxime Audet-Roberge
@audetrobergem
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.
Just van den Broecke
@justb4
image.png
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:
Maxime Audet-Roberge
@audetrobergem
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.
Just van den Broecke
@justb4
That looks correct. Another public WFS uses same notation (double colon): https://geodata.nationaalgeoregister.nl/nationaleparken/wfs with <DefaultCRS>urn:ogc:def:crs:EPSG::28992</DefaultCRS> and works ok. Give that a try. Must be something else. Hard to figure out without the WFS url and your deployment context (Docker?, Python version, maybe lxml version). The capabilities Probe and other Resource types, w.g. WMS work ok for that GeoServer endpoint?
Hmm and https://geodata.nationaalgeoregister.nl/bag/wfs now suddenly also has double colons in CRSs.
But that is the correct notation.
Just van den Broecke
@justb4
See also: https://docs.geoserver.org/latest/en/user/services/wfs/axis_order.html urn:x-ogc:def:crs:EPSG:4326 and urn:ogc:def:crs:EPSG::4326 are equivalent.
(notice the subtle :x-ogc: vs :ogc:, 4 notations for the same thing causes headaches in many projects).
Just van den Broecke
@justb4
Forget the above, the problem (and fix) is clear to me, and already known: https://github.com/geopython/GeoHealthCheck/issues/9#issuecomment-562950148 : WfsGetFeatureBboxAll uses OWSLib WFS, which in 0.17.1 does not support auth headers. Was fixed geopython/OWSLib#613, even by me :-), in later version. There is even a geopython/GeoHealthCheck#312. (WFS Capabilities Probe works as it does not use OWSLib btw).
Maxime Audet-Roberge
@audetrobergem
All right, I will wait for the fix to add probes to my WFS. Thank you for taking the time to help me!
Just van den Broecke
@justb4
An activity for a GHC API specification has been started. In first instance geared to facilitate remote monitoring integrations and custom reporting, using the current GHC implementation. There is a broader plan to base a future GHC entirely on a full CRUD API. See work-in-progress on the Wiki: https://github.com/geopython/GeoHealthCheck/wiki/API-Specification . If you would like to comment or have suggestions, please do, best is via the related issue #325.
Astrid Emde
@astroidex
Hello all, I try to install GHC on windows without docker. Has someone good experience with it?
Just van den Broecke
@justb4
@astroidex sorry can't help you direct. Hopefully someone else here? Main thing to do is getting all dependencies installed. Understood Anaconda works well for that. Would be good to document installation steps to include in our docs.
Just van den Broecke
@justb4
Would like to bring out GHC 0.8.0 today. This is mainly the Py2->Py3 migration, no DB upgrades. Has been running stable on "demo" for about 6 months now. Several production deployments can then be upgraded (on 0.7.0). Then we can quickly move to Milestone/version 0.8.1 that has leftovers from Milestone 0.8.0. @tomkralidis I can do the release sequence ok?
Tom Kralidis
@tomkralidis
+1 thanks @justb4
Just van den Broecke
@justb4
@/all GHC release 0.8.0 is out. Main addition is the Py2->Py3 migration. Many thanks to @borrob for his efforts/patience with this! Also 0.8.0 Docker Image is available.
Tom Kralidis
@tomkralidis
thanks @justb4 !
Rob van Loon
@borrob

@/all GHC release 0.8.0 is out. Main addition is the Py2->Py3 migration. Many thanks to @borrob for his efforts/patience with this! Also 0.8.0 Docker Image is available.

:D

MacPingu
@cehbrecht

Hello, I have installed GHC with docker-compose and postgres support. I would like to change the admin password from the default one. How can I do this?

I looked into the docs:
https://docs.geohealthcheck.org/en/latest/admin.html#user-management

… but the admin account is not in the user table, right?

Just van den Broecke
@justb4
@cehbrecht The admin account is in the user table. Initial setting can be done via Docker Environment settings. Admit, not well-documented, but any GHC env var default can be overruled via Docker/docker-compose env vars. For the admin settings this should be done on the first run. The env vars are ADMIN_NAME and ADMIN_PWD. See for example the docker-compose env settings in the example. Changing the password later is more involved as one would need to encrypt the password and use e.g. psql to change it in the user table.
MacPingu
@cehbrecht
@justb4 Thanks :) I will do so.
Tom Kralidis
@tomkralidis

hey @justb4 FYI for the OSGeo AGM, given GHC is a community project, any chance you/others can update the AGM deck at https://docs.google.com/presentation/d/1C6llSnWZ28c2aWQgttPiOnoo6dttdqKg07ugU_yr6Uc/edit#slide=id.g9401e4b2da_178_0 (currently slide 74).

FYI AGM is this Thursday.

Thanks

Just van den Broecke
@justb4
Ok, will do (slide 78 by now).
Just van den Broecke
@justb4
Done. Add apply for OSGeo Project in 2020-2021?
Tom Kralidis
@tomkralidis
Sounds good!
Just van den Broecke
@justb4
done
MacPingu
@cehbrecht
@justb4 would it be possible to export/import the configured list of checked services? By this I could make changes to the config only by using ghc.env and restart the docker container (dropping the volume with the db before). But I would like to keep the service list.
Just van den Broecke
@justb4
@cehbrecht not at the moment, there is a long-standing issue for a similar service: geopython/GeoHealthCheck#120 . I think the DB format is a bit too low-level now. We need an easy-to-use YAML format. The unit tests also load data, could be a temporary shortcut, but beware it clears entire DB.
Rob van Loon
@borrob
@cehbrecht @justb4 I once wrote a set of SQL-scripts to deal with "reusable" configurations scripts. Certainly not ideal, but it got the job done (and it sounds more work than it actually is).
Tom Kralidis
@tomkralidis
would hitting the /json endpoint help? i.e. https://demo.geohealthcheck.org/json
Just van den Broecke
@justb4
I would opt for a two-way format for in/export. I actually got quite far with (and contributed to) sqla-yaml-fixtures. On the other hand this is somewhat low-level, tied to SQLAlchemy (so for both Postgres and SQLite) though this could be behind the (upcoming) API.
Tom Kralidis
@tomkralidis
+1
Tom Kralidis
@tomkralidis
@justb4 are you attending the AGM today? Would you be able to talk to the GHC slide (slide 83)?
Just van den Broecke
@justb4
Yes, I also do slides 104/105 (OSGeo.nl Local Chapter). You not there at all?
Tom Kralidis
@tomkralidis
I’m there, yup, presenting other things.
Just van den Broecke
@justb4
Aha, yes I am in the panel there.
KoalaGeo
@KoalaGeo
GeoHealthCheck (distantly) related question: anyone know of any examples of people using Prometheus + Grafana for monitoring & testing OGC Services?
Just van den Broecke
@justb4
Using Prometheus + Grafana for years for systems monitoring (Linux/Docker via nodeAdvisor/cAdvisor). Thinking out loud: GHC wishlist are integrations with existing monitoring tools. Would IMHO be trivial to have a minimal Prometheus Pull Exporter by extending the GHC API, fetching and exposing metrics from internal GHC Resources' status/Probe Runs.
1 reply
KoalaGeo
@KoalaGeo

Hi All, I'm trying to setup with Docker and am doing:

FROM geopython/geohealthcheck:latest

COPY content/bgs_config.py GeoHealthCheck/GeoHealthCheck/config_main.py
ADD content/resources.json GeoHealthCheck/GeoHealthCheck/

CMD [ "python", "./GeoHealthCheck/GeoHealthCheck/models.py", "load", "GeoHealthCheck/GeoHealthCheck/resources.json", "y" ]

However this doesn't seem to be applying my config, am I missing something?

Just van den Broecke
@justb4
@KoalaGeo try: COPY content/bgs_config.py GeoHealthCheck/instance/config_site.py. This overrides the installed config.
In theory you would not need to build an extended Docker Image: you could do Docker Volume mounting for the config and GeoJSON files. And execute models.py via Docker exec/run, overruling the default CMD.
KoalaGeo
@KoalaGeo
Cheers for that, config_site.py fixed it. I'm using k8s so trying to avoid volume mounts or persistant volumes so wanted a way to bake in the config and all the services to be monitored in the container at startup. Had hoped for nice copy in of a .yml like pygeoapi :-)
KoalaGeo
@KoalaGeo
I'll have a go with 'kubectl exec'
Just van den Broecke
@justb4
@KoalaGeo Good to hear! Yes, with k8s you want complete/self-contained Images.