search

3liz / lizmap-wps-web-client-module

Lizmap module for WPS Client support
Mozilla Public License 2.0
11 stars 9 forks source link

Computed layer from WPS are not displayed #19

Closed dmarteau closed 2 years ago

dmarteau commented 3 years ago

When running tests processes (Qgis buffer, centroids): computed layers appears in legend but are not displayed.

Qgis 3.16 Lizmap: 3.4.4

nboisteault commented 3 years ago

@pcav says it works : https://github.com/3liz/lizmap-wps-web-client-module/issues/12#issuecomment-877686560 Maybe issue occurs only with our test stack. @drillinP could you test WPS module with a fresh Lizmap instance?

chrimohr commented 3 years ago

I've ran into the same issue. As a workaround I'm using the server external IP and port instead of http://map:8080/ows in the WPS part of docker-compose.yml.

nboisteault commented 3 years ago

Thanks @chrimohr . @dmarteau any change in 3liz/qgis-wps that could explain this?

dmarteau commented 3 years ago

@nboisteault I have tested:

From wps/ows/ POV all is OK.

What I see is that Lizmap does not send any OWS request te the map service for fetching the result layer (but seems to get the correct status) - This has to be investigated in Lizmap.

Also there is no logs anywhere (in lizmap or in file) indicating potential errors (Lizmap should log remote requests at least for the sake of debugging).

rldhont commented 3 years ago

I have made 1 test:

  1. make pull
  2. make run
  3. Go to 127.0.0.1:9090
  4. Click on France parts map in Test repository
  5. Run a buffer algorithm on france_parts layer
  6. Check the HTML and find that OpenLayers using the host 127.0.0.1:9090:8080
  7. Check the WPS GetResult response it contains
<wps:ExecuteResponse xsi:schemaLocation="http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsExecute_response.xsd" service="WPS" version="1.0.0" xml:lang="en-US" serviceInstance="http://wps:8080/?service=WPS&request=GetCapabilities" statusLocation="http://wps:8080/ows/?service=WPS&request=GetResults&uuid=02eb3780-e550-11eb-b94e-0242ac120003">
  <wps:Process wps:processVersion="1.0generic">
    <ows:Identifier>pyqgiswps_test:qgisbuffer</ows:Identifier>
    <ows:Title>QGIS Buffer</ows:Title>
  </wps:Process>
  <wps:Status creationTime="2021-07-15T09:35:37Z">
    <wps:ProcessSucceeded>Task finished</wps:ProcessSucceeded>
  </wps:Status>
  <wps:ProcessOutputs>
    <wps:Output>
      <ows:Identifier>OUTPUT</ows:Identifier>
      <ows:Title>Buffered</ows:Title>
      <ows:Abstract>Buffered</ows:Abstract>
      <wps:Reference href="http://127.0.0.1:9090:8080/index.php/wps/ows/?MAP=wps-results:02eb3780-e550-11eb-b94e-0242ac120003/pyqgiswps_test_qgisbuffer.qgs&service=WMS&request=GetCapabilities&layers=tests" mimeType="application/x-ogc-wms"/>
    </wps:Output>
  </wps:ProcessOutputs>
</wps:ExecuteResponse>

When I launch make run, I have this message:

docker-compose rm -f || true
ERROR: The Compose file './docker-compose.yml' is invalid because:
services.map.ports contains an invalid type, it should be a number, or an object
services.web.ports contains an invalid type, it should be a number, or an object
services.wps.ports contains an invalid type, it should be a number, or an object
Creating environment file for docker-compose
dmarteau commented 3 years ago

No, this is a problem related to a bad docker-compose environment, it has nothing to do with this issue:

A correct configuration give the following result, which is correct from the docker-compose lizmap service. But the issue is still there. 

<!-- py-qgis-wps 1.5.4 -->
<wps:ExecuteResponse xsi:schemaLocation="http://www.opengis.net/wps/1.0.0 http://schemas.opengis.net/wps/1.0.0/wpsExecute_response.xsd" service="WPS" version="1.0.0" xml:lang="en-US" serviceInstance="http://wps:8080/?service=WPS&request=GetCapabilities" statusLocation="http://wps:8080/ows/?service=WPS&request=GetResults&uuid=cf14f35e-e551-11eb-b559-0242ac120005">
<wps:Process wps:processVersion="1.0generic">
<ows:Identifier>pyqgiswps_test:qgisbuffer</ows:Identifier>
<ows:Title>QGIS Buffer</ows:Title>
</wps:Process>
<wps:Status creationTime="2021-07-15T09:48:29Z">
<wps:ProcessSucceeded>Task finished</wps:ProcessSucceeded>
</wps:Status>
<wps:ProcessOutputs>
<wps:Output>
<ows:Identifier>OUTPUT</ows:Identifier>
<ows:Title>Buffered</ows:Title>
<ows:Abstract>Buffered</ows:Abstract>
<wps:Reference href="http://map:8080/ows/?MAP=wps-results:cf14f35e-e551-11eb-b559-0242ac120005/pyqgiswps_test_qgisbuffer.qgs&service=WMS&request=GetCapabilities&layers=buffer1" mimeType="application/x-ogc-wms"/>
</wps:Output>
</wps:ProcessOutputs>
</wps:ExecuteResponse>
rldhont commented 3 years ago

To do not display the map:8080, the host is replaced. So it has to be fixed in the module.

dmarteau commented 3 years ago

map:8080 is the qgis server host as see by all services defined in the docker-compose and it is perfectly valid.

rldhont commented 3 years ago

I have to understand why jUrl::full("wps~ows:index"); provides http://127.0.0.1:9090:8080/index.php/wps/ows/

rldhont commented 3 years ago

I logged some information about domain like that:

jLog::log('domainName: '.jApp::config()->domainName, 'error');
jLog::log('HTTP_HOST: '.$_SERVER['HTTP_HOST'], 'error');
jLog::log('SERVER_NAME: '.$_SERVER['SERVER_NAME'], 'error');

And I give this:

2021-07-15 16:28:44     172.18.0.1      error   domainName: 127.0.0.1:9090
2021-07-15 16:28:44     172.18.0.1      error   HTTP_HOST: 127.0.0.1:9090
2021-07-15 16:28:44     172.18.0.1      error   SERVER_NAME: 127.0.0.1:9090

So the domainName defined in config files is 127.0.0.1:9090 but I found nothing about domainName in config files:

@dmarteau is the LIZMAP_PORT environment variable used to defined domainName ?

dmarteau commented 3 years ago

is the LIZMAP_PORT environment variable used to defined domainName ?

No, this is just the variable name for the docker-compose environment (.env file)

rldhont commented 3 years ago

Ok I did not understand how the domainName in config is set. But if it is dynamically set with the port. The solution is to update tests/lizmap/var/lizmap-config/localconfig.ini.php by adding forceHTTPPort=True.

laurentj commented 3 years ago

We found the issue :

  1. nginx sets SERVER_NAME with $http_host, which itself comes from HTTP headers. So it can contains the port (although the PHP documentation says that SERVER_NAME should contain the server name (so, from what i understand, without the port)...
  2. during the configuration processing, Jelix sets domainName with SERVER_NAME if domainName is empty. It doesn't check if there is a port (because it should not have one IMHO).

On a production server, most of time the server is on standard port (80 or 443) so no port into http_host, so there is no issue. However, if the web server is on a non-standard port, this is an issue.

So there is two mistakes here :

Anyway, I should make a change into Jelix to support SERVER_NAME having a port number.

laurentj commented 3 years ago

An update of Jelix has been landed into all branches. It fixes the support of port number into SERVER_NAME. Bonus: forceHTTPPort and forceHTTPSPort are guessed automatically when the port is present into HTTP_HOST or SERVER_NAME.