istsos / istsos2 Goto Github PK

DescribeSensor request yields in exception:

http://istsos.org/istsos/demo?request=DescribeSensor&procedure=GARBOW&service=SOS&version=1.0.0&outputFormat=text/xml;subtype=%22sensorML/1.0.1%22

<Exception locator="outputFormat" exceptionCode="InvalidParameterValue">
<ExceptionText>
Supported "outputFormat" values are: text/xml;subtype="sensorML/1.0.1"
</ExceptionText>
</Exception>
</ExceptionReport>

See also this possibly related issue in java-core:
istSOS/java-core#3

In order to differentiate access to data it seems that one currently has to define different services with different access rights. However, having e.g. a service per project would be quite cumbersome and I have no idea if it would be possible to make data available across services (in case access constraints are removed)...

It would be good to be able to distinguish access rights within a service (e.g. specific sensors are only visible for different users / roles), e.g. at offerings or procedure level?

For related discussion on ML, see:
https://groups.google.com/forum/#!topic/istsos/NAMGUxQWIE4

Hello,
I am trying to use istSOS2 in a research project about sensor web standards and protocols. My problem is I can't register a new procedure once after having set up everything following the tutorial.

I have dockerised istSOS using the installation guide, which, as mentioned by SunveerSingh in issue #33, needs to be updated (e.g. the wns folder referred to in the installation guide it seems has been renamed to wnslib). I adapted the steps slightly to the newest istSOS2 stable version (2.3.1)

My Dockerfile looks like...

========================================

FROM ubuntu:14.04

RUN apt-get update \
                && apt-get install -y --no-install-recommends apache2 libapache2-mod-wsgi python-psycopg2

COPY ./istsos-2.3.1.tar.gz .

RUN tar -zxvf ./istsos-2.3.1.tar.gz -C /usr/local/ \
                && chmod 755 -R /usr/local/istsos \
                && chown -R www-data:www-data /usr/local/istsos/services \
                && chown -R www-data:www-data /usr/local/istsos/logs \
                && chown -R www-data:www-data /usr/local/istsos/wnslib \
		&& rm ./istsos-2.3.1.tar.gz

COPY ./000-default.conf /etc/apache2/sites-enabled/000-default.conf
	
EXPOSE 80
	
CMD apachectl -D FOREGROUND

========================================

and my docker-compose.yaml file like...

========================================

version: '2'

services:
  istsos:
    build: .
    ports:
      - 8083:80    
    depends_on:
      - database

  database:
    image: mdillon/postgis:9.3
    environment:
      - POSTGRES_DB=istSOS
      - POSTGRES_USER=istSOS
      - POSTGRES_PASSWORD=ChangeMe
    ports:
      - 5436:5432
    volumes:
      - ./data:/var/lib/postgresql/data

========================================

In the Admin UI I can connect successfully to the database and the app status is "up", so it seems everything is running correctly:

I can create new services, insert observable properties and offerings with no problems. When I want to create a new procedure, this error is thrown:

I have made sure all the values I entered into the fields contain no special characters, as visible in the screenshot. I checked the apache log files, which don't show any errors.

Has anyone run into this issue, or have an idea about any possible solution?

Thanks for any advice

Daniel

Hello,

As I mentionned in the IstSOS google group we have developped a small frontend to see sensors and plot their data based on the istSOS API : https://groups.google.com/g/istsos/c/YIl6tFgs7So
Everything work well until we put serve our application behind a domain (different that the istSOS one) ang got CORS issues.
Our istSOS is protected by the HTTP Basic Authentication following the dedicated doc, but the istSOS always check the authentification, even for OPTIONS request (which it looks like to be not standard : https://fetch.spec.whatwg.org/#http-responses)
I had to "hack" a little bit my Apache conf to manage this issue :

SetEnvIf Request_Method "OPTIONS" noauth=1
        <RequireAny>
            Require env noauth
            Require valid-user
        </RequireAny>

but maybe it would better to do it at the application level.
I could propose a pull request if you aggree with this evolution ?

Thank you

Not sure this issue should be opened in this istSOS repo, but as this is the one with interface/admin, hopefully it is the right place

When I try to query the istSOS demo service with SOS version 1.0.0, the following query works without a problem:

http://istsos.org/istsos/demo?service=SOS&
    version=1.0.0&
    request=GetObservation&
    offering=temporary&
    observedProperty=urn:ogc:def:parameter:x-istsos:1.0:meteo:air:rainfall&
    responseFormat=text/xml;subtype="om/1.0.0"&
    eventTime=2015-05-28T00:00:00+0200/2015-06-02T00:00:00+0200&
    procedure=BELLINZONA

However, when I try to change the SOS version (1.0.0 to 2.0.0) and the response format (text/xml;subtype="om/1.0.0" to http://www.opengis.net/om/2.0) as in the following query, I always get an error saying Invalid parameter value in 'procedure' parameter: temporary.

http://istsos.org/istsos/demo?service=SOS&
    version=2.0.0&
    request=GetObservation&
    offering=temporary&
    observedProperty=urn:ogc:def:parameter:x-istsos:1.0:meteo:air:rainfall&
    responseFormat=http://www.opengis.net/om/2.0&
    eventTime=2015-05-28T00:00:00+0200/2015-06-02T00:00:00+0200&
    procedure=BELLINZONA

Seems like the offering attribute is somehow erroneously parsed into the procedure one.

There are currently 3 drop-down lists: service, property and procedure.
Between property and procedure, there should be another one: observedProperty, in order to view in the last dropo-down list only the procedures with the desired property.

Running docker-compose starts the application, however the postgres host defaults to localhost, and the connections fails. A workaround is to manually change the PostGIS Host in the Database section of the interface to the current db service name ("istsos-db" with the current compose). Or modify the config files before the install.

Wouldn't be better to have a fully working docker start? Would it be a solution to manage the configuration parameters as environmental variables, including the postgis host, also for the istsos container? Maybe adding an entrypoint with commands to edit the configuration files (default.cfg.sample) or similar. Crudini could help (https://github.com/pixelb/crudini)

Some more feedback from sos4R tests:

The describeSensor function in the R package returns an InvalidParameterValue exception.

The corresponding request:
http://istsos.org/istsos/demo?request=describeSensor&procedure=T_LUGANO&outputFormat=text/xml;subtype=%27sensorML/1.0.1%27&service=SOS&version=1.0.0
returns the same exception!

Also if I change the output format value to those supported according to documentation here (and even if I copy the request from there):
http://istsos.org/en/latest/doc/examples/describesensor.html

Steps to reproduce:

• Create a service (demo) following instructions in tutorial
• Log into Admin web UI
• Select "Delete service"
• Enter "demo" in text box
• Click Update

What happens

The following message is displayed and the service remains.

Service demo already exist

Status response: OK
Resource: waServices
Method: PUT
Path /istsos/services/demo

Expected behaviour

Confirmation message displayed and service is removed.

Software version

ISTSOS Version 2.4.0-RC4 (running via Docker)

Non-ascii characters in 'Service Provider' or 'Service identification' Metadata submitted through the admin Web-UI lead to Unicode Error:

'ascii' codec can't encode character u'\xf8' in position 1: ordinal not in range(128)

Status response: OK
Resource: waProvider
Method: PUT
Path /istsos/services/default/configsections/provider

When we (me and @pesekon2) tried using the sos4R client (https://cran.r-project.org/web/packages/sos4R/index.html) to fetch data from istSOS we ran into issues with spatial data of the response.
In particular, bounding box of the offerings was returned as NULL.

When looking at the response here:
http://istsos.org/istsos/demo?request=getCapabilities&section=contents&service=SOS
it seems that the bounding box is given differently from GML definition of envelope (www.datypic.com/sc/niem21/e-gml32_boundedBy.html). In fact, the response does not seem to be correct as only one coordinate pair is given (not both upper and lower corner). A second point and maybe the proper XML tags seem to be missing...

In comparison, http://sensorweb.demo.52north.org/52n-sos-webapp/service?service=SOS&request=GetCapabilities gives the BBOX exactly as in the GML definition... Maybe a bug?

In the aggregation panel, the function Apply to all is not working with Firefox, while with Chrome is ok

The vertical grid spacing, corrisponding to the time in the orizontal axis, should correspond to the end of the day (or month and so on...)
With this improvement, the comprehension of the time series plot will increase

Maurizio

Not all the colors should be possible, but only color shades that are clearly visible in the chart

When restarting Apache on OSGeoLive there is the following warning:

[Wed Jul 03 23:57:19.532526 2019] [core:warn] [pid 32238] AH00114: Useless use of AllowOverride in line 7 of /etc/apache2/sites-enabled/istsos.conf/istsos.conf.

Caused by line

It looks like this line can be removed as it is not in a Location section?
http://httpd.apache.org/docs/2.2/mod/core.html#allowoverride

Hello, this installation http://istsos.org/en/latest/doc/installation.html doc is outdated and need to be updated such as the first part of installing PostgreSQL and Postgis, you cannot install it using one line command in Ubuntu 16 and above.

I would like to fix this, if someone can get me started

Thank You
Sunveer

When you delete an existing service from the interface in istSOS 2.4 there's no error message but the service is not deleted.

Hi,

Coordinates in SensorML document are in XY axis order with EPSG:4326 code, and not in YX order.
Is there a reason for that ?

I also wonder about the relevance of Z axis with standard. Is Z axis strictly mandatory in IstSOS ?

<sml:location>
    <gml1:Point srsName="EPSG:4326" gml1:id="foo">
        <gml1:coordinates>5.1,42.1,0</gml1:coordinates>
    </gml1:Point>
</sml:location>

m431m

In the GetCapabilities response the spatialFilter allowedValues provided without Reference System.

I setup ISTSOS server successfully and receiving observation data from Arduino clients. Now i want to publish data to MQTT server. I already setup a MQTT server locally (mosquitto) and put MQTT settings in ISTSOS web backend. But ISTSOS server not publishing any data to MQTT broker.

Please answer if anyone already setup this.

when use the data editor in the webAdmin interface, submitted data value and qualityIndex columns are inverted, resulting in inserting values as QI and QI as values

Example:
data=18°C, QI=100 result after insertion in data=100°C, QI=18

Here the example of incorrect JSON request to walib:
{"AssignedSensorId":"9c2e54345cbdc00e1c5c8d19ac812930","ForceInsert":"true","Observation":{"name":"LOCARNO","samplingTime":{"duration":"P513DT10H50M","beginPosition":"2015-10-26T23:00:00Z","endPosition":"2015-10-28T23:00:00Z"},"result":{"DataArray":{"elementCount":"3","values":[["2015-10-26T23:00:00Z","0","200","200","0"],["2015-10-27T23:00:00Z","18.2","200","200","0"],["2015-10-28T23:00:00Z","2","200","200","0"]],"field":[{"definition":"urn:ogc:def:parameter:x-istsos:1.0:time:iso8601","name":"Time"},{"definition":"urn:ogc:def:parameter:x-istsos:1.0:meteo:air:rainfall","name":"air-rainfall","uom":"mm"},{"definition":"urn:ogc:def:parameter:x-istsos:1.0:meteo:air:rainfall:qualityIndex","name":"air-rainfall:qualityIndex","uom":"-"},{"definition":"urn:ogc:def:parameter:x-istsos:1.0:meteo:air:temperature","name":"air-temperature","uom":"\u00b0C"},{"definition":"urn:ogc:def:parameter:x-istsos:1.0:meteo:air:temperature:qualityIndex","name":"air-temperature:qualityIndex","uom":"-"}]}},"featureOfInterest":{"geom":"<gml:Point srsName='EPSG:4326'><gml:coordinates>8.792120000000001,46.155149999999999,197.800000000000011</gml:coordinates></gml:Point>","name":"urn:ogc:def:feature:x-istsos:1.0:Point:LOCARNO"},"observedProperty":{"component":["urn:ogc:def:parameter:x-istsos:1.0:time:iso8601","urn:ogc:def:parameter:x-istsos:1.0:meteo:air:rainfall","urn:ogc:def:parameter:x-istsos:1.0:meteo:air:rainfall:qualityIndex","urn:ogc:def:parameter:x-istsos:1.0:meteo:air:temperature","urn:ogc:def:parameter:x-istsos:1.0:meteo:air:temperature:qualityIndex"],"CompositePhenomenon":{"dimension":"5","id":"comp_3","name":"timeSeriesOfObservations"}},"procedure":"urn:ogc:def:procedure:x-istsos:1.0:LOCARNO"}}

The default EPSG of a new service is not taken from the filed but only from default service configuration

please refer to istsos2 / Tutorial / vp / FAO56.py

reference is to lines 81 thru 84 -- day of year == J

specifically line 83

why is the day of year reduced by one?