Skip to content
This repository has been archived by the owner on Oct 11, 2024. It is now read-only.

Server generated offering identifier #76

Open
glegal opened this issue Apr 18, 2017 · 6 comments
Open

Server generated offering identifier #76

glegal opened this issue Apr 18, 2017 · 6 comments
Assignees
Labels
Milestone

Comments

@glegal
Copy link

glegal commented Apr 18, 2017

I try to use the sos importer with the automtic offering generation mode

<SosMetadata>
............................................
   <Offering generate="true"/>
............................................
</SosMetadata>

After the InsertSensor request sent, my SOS server respond the following :

<swes:InsertSensorResponse>
  <swes:assignedProcedure>urn:sensor:csv-sensor</swes:assignedProcedure>
  <swes:assignedOffering>offering-urn:sensor:csv-sensor</swes:assignedOffering>
</swes:InsertSensorResponse>

But the value of "assignedOffering" is never used.

I see that the InsertSensor request contains a block :

<sml:capabilities name="offerings">
   <swe:SimpleDataRecord>
      <swe:field name="csv-sensor">
         <swe:Text definition="urn:ogc:def:identifier:OGC:1.0:offeringID">
            <swe:value>urn:sensor:csv-sensor</swe:value>
         </swe:Text>
      </swe:field>
   </swe:SimpleDataRecord>
</sml:capabilities>

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

@EHJ-52n EHJ-52n self-assigned this Jun 27, 2017
@EHJ-52n EHJ-52n added the bug label Jun 27, 2017
@EHJ-52n EHJ-52n added this to the 0.5.0 milestone Jun 27, 2017
@EHJ-52n
Copy link
Member

EHJ-52n commented Jun 27, 2017

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.

@EHJ-52n EHJ-52n closed this as completed Jun 27, 2017
@glegal
Copy link
Author

glegal commented Jul 7, 2017

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>

@EHJ-52n EHJ-52n reopened this Jul 7, 2017
@EHJ-52n
Copy link
Member

EHJ-52n commented Jul 7, 2017

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.

@glegal
Copy link
Author

glegal commented Jul 7, 2017

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

@EHJ-52n
Copy link
Member

EHJ-52n commented Jul 7, 2017

Which version of the SOS server are you using?

I tested with the latest version and the assigned offering was <sensor-name>-offering.

@glegal
Copy link
Author

glegal commented Jul 7, 2017

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.

@EHJ-52n EHJ-52n modified the milestones: 0.5.0, 0.5.1 Jul 21, 2017
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
Projects
None yet
Development

No branches or pull requests

2 participants