ThinkHazard must be able to request map overlays

[gubuntu]

ThinkHazrd, like any other standards-compliant client, fetches overlays from GeoNode-GeoServer via WMS.

Once GeoNode-QGIS is implemented, TH must still be able to fetch overlays, either:

• as WMS, which GeoNode-QGIS currently does not support, by design, or
• as TMS, which would need some modification to TH

(from #160)

[gubuntu]

I discussed this with @lucernae and we think that we can enable WMS requests against the geonode url where geonode will proxy the requests to QGIS server, since most of the infrastructure to do that is there.

• authentication will then be handled by geonode
• metadata management will have to populate the correct WMS urls

[gubuntu]

geonode-QGIS already has this link in layer metadata: http://staging.geonode.kartoza.com/qgis-server/ows. How does that get there @lucernae? Geonode or Kartoza code?

All we need to do is make it work i.e. by proxying full, standard OWS requests through GeoNode url.

We do NOT need to worry about authentication for the launch since all layers are public.

[lucernae]

geonode-QGIS already has this link in layer metadata: http://staging.geonode.kartoza.com/qgis-server/ows. How does that get there @lucernae? Geonode or Kartoza code?

This is from Kartoza code. Last time I check, WMS is working. I'm still confused on what is the difference between OWS and WMS? Should I name the endpoint OWS or WMS, because Geoserver uses WMS as endpoint hardcoded in their code.

[gubuntu]

@lucernae OWS = OGC web service = common endpoint for WMS, WFS, WCS, etc.

Perhaps WMS GetMap is working but GetCapabilities is not. @fvanderbiest @fjacon @stufraser1 must Labs GeoNode WMS support GetCapabilities for the launch or is TH aware of the available layers and thus able to operate with only GetMap working?

@lucernae we will have to make WMS fully compliant which includes supporting GetCapabilities. Hopefully we can focus on this after the launch. Since layers are in multiple QGIS projects, generally one per project in the current architecture, we need some backend logic to aggregate these into a single GetCapabilities response through GeoNode.

Some ideas:

• Poll or trigger GetCapabilities requests to each backend QGIS project and maintain the content required to respond with an aggregate GetCapabilities response as a Django model and the response as a view. OR -trust (or ensure) that GeoNode/PyCSW metadata is complete and sufficient to use to generate a WMS or WFS or WCS GetCapabilities response. i.e. rely on CSW to represent the layer index and write a Django view that builds a GetCapabilities doc from one or more CSW responses.
  • possibly cache the doc until the service status changes (e.g. new layer or layer deleted)
• Sending GetCapabilities requests to each QGIS project on the fly is not an option - too slow and too much server load.