Open glegal opened 7 years ago
The problem is fixed in #82. Background: the generated offering was the same as the sensor/procedure id, hence ignored by the SOS but later on used by the importer.
I still have a problem here. When the InsertSensor is send, the response is :
<swes:InsertSensorResponse ......>
<swes:assignedProcedure>urn:sensor:csv-sensor</swes:assignedProcedure>
<swes:assignedOffering>offering-urn:sensor:csv-sensor</swes:assignedOffering>
</swes:InsertSensorResponse>
but the insertObservation still send :
<sos:InsertObservation ......>
<sos:offering>urn:sensor:csv-sensor-offering</sos:offering>
Which version of the feeder and OX-F did you use? Can you provide any log details? You should rebuild the latest version from the develop branch which uses OX-Fv2.0.0.
I just test on the latest version this morning (branch develop on OX-framework, branch develop on sos-importer). I see a change now the offering name is "< sensor-name >-offering" but it still not the offering assigned by the sos server. I have a patch on my fork, i'll make a pull request soon
Which version of the SOS server are you using?
I tested with the latest version and the assigned offering was <sensor-name>-offering
.
I use my own SOS server, not a 52N one. So the politics is not to assign <sensor-name>-offering
but offering-<sensor-name>
. But that's not the point, the sos-importer should use the offering identifier returned by the sos in the InsertSensorResponse.
I try to use the sos importer with the automtic offering generation mode
After the InsertSensor request sent, my SOS server respond the following :
But the value of "assignedOffering" is never used.
I see that the InsertSensor request contains a block :
This value is used after in InsertObservation request and my server launch an error as the offering is not registered.
Is this somehow normative ? the importer should be able to use the value assigned by the server.
I join the configuration file used and the insertSensor request/response config-files.zip