Design and implementation of a system for the improved searching and accessing of real-world SOS services

Design  and  implementa.on  of  a  system  for  the  improved  searching  and  

accessing  of  real-­‐world  SOS  services    

Ben  Knoechel  ([email protected])  Chih-­‐Yuan  Huang  ([email protected])  Steve  Liang  ([email protected])  

University  of  Calgary    

Outline  

•  Introduc.on  •  Methodology  •  Experimental  Results  •  Conclusions  

2  

Introduc.on  

3  

Introduc.on  

•  The  Open  Geospa.al  Consor.um  (OGC)  has  developed  the  Sensor  Web  Enablement  (SWE)  

•  SWE  is  a  set  of  standards  to  allow  people  to  share  and  interact  with  sensor  data  over  the  Internet  

•  The  Sensor  Observa.on  Service  (SOS)  is  a  standard  for  sharing  data  collected  by  sensors  – SOS  will  refer  to  version  1.0.0  

4  

Sensor  Observa.on  Service  

•  SOS  defines  three  core  opera.ons  – GetCapabili.es  – DescribeSensor  – GetObserva.on  

•  A  GetObserva.on  request  must  define  an  observa.on  offering  and  at  least  one  observed  property  

•  Addi.onal  filters  include  spa.al-­‐temporal  bounding  box,  feature  of  interest  

5  

Phenomenon  Layer  

•  A  SOS  service  may  provide  varied  data  •  We  define  a  phenomenon  layer  to  refer  to  data  specific  to  a  single  observa.on  offering  and  observed  property  

•  A  phenomenon  layer  can  be  used  to  generate  more  specific  data  requests  to  a  SOS  service  

•  This  defini.on  is  specific  to  our  group  

6  

Enhancing  SOS  

•  SOS  accomplishes  the  goal  of  transferring  sensor  data  

•  We  can  extend  the  u.lity  of  SOS  by  designing  a  system  to  collect  data  from  mul.ple  SOS  services  

•  Our  team’s  use  case:  – To  display  all  the  sensors  measuring  the  same  phenomenon  from  all  SOS  services  

7  

Problems  

•  A  number  of  problems  were  encountered  when  developing  a  system  for  our  use  case  

1.  Large  variety  of  the  observed  property  URI  represen.ng  the  same  phenomenon  

2.  Sensor-­‐centric  SOS  services  3.  Non-­‐compliant  SOS  services  

8  

Different  Observed  Property  URIs  For  Wind  Speed  

9  

urn:x-­‐ogc:def:property:OGC::WindSpeed

urn:ogc:def:property:universityofsaskatchewan:ip3:windspeed

urn:ogc:def:phenomenon:OGC:1.0.30:windspeed

urn:ogc:def:phenomenon:OGC:1.0.30:WindSpeeds

urn:ogc:def:phenomenon:OGC:windspeed

urn:ogc:def:property:geocens:geocensv01:windspeed

urn:ogc:def:property:noaa:ndbc:Wind  Speed

urn:ogc:def:property:OGC::WindSpeed

urn:ogc:def:property:ucberkeley:odm:Wind  Speed  Avg  MS

urn:ogc:def:property:ucberkeley:odm:Wind  Speed  Max  MS hdp://ws.sensordatabus.org/Ows/Swe.svc/?service=SOS&request=GetResourceByID&ResourceID=urn:renci:sdb:property:1.0.0:Wind%20Speed hdp://marinemetadata.org/cf#wind_speed

An  Example  of  a  Sensor-­‐Centric  SOS  Service  

 Observation Offering Observed Property

offering_44040 http://ws.sensordatabus.org/Ows/Swe.svc/?service=SOS&request=GetResourceByID&ResourceID=urn:renci:sdb:property:1.0.0:Wind%20Speed

offering_nos.8411250.WL http://ws.sensordatabus.org/Ows/Swe.svc/?service=SOS&request=GetResourceByID&ResourceID=urn:renci:sdb:property:1.0.0:Wind%20Speed

offering_pwaw3 http://ws.sensordatabus.org/Ows/Swe.svc/?service=SOS&request=GetResourceByID&ResourceID=urn:renci:sdb:property:1.0.0:Wind%20Speed

offering_mqtt2 http://ws.sensordatabus.org/Ows/Swe.svc/?service=SOS&request=GetResourceByID&ResourceID=urn:renci:sdb:property:1.0.0:Wind%20Speed

offering_nws.SBCP.metar http://ws.sensordatabus.org/Ows/Swe.svc/?service=SOS&request=GetResourceByID&ResourceID=urn:renci:sdb:property:1.0.0:Wind%20Speed

10  

Proposed  Solu.on  

•  We  propose  a  logical  layer  service  to  manage  heterogeneous  observed  property  URIs  

•  We  propose  a  transla8on  engine  to  provide  efficient  communica.on  with  SOS  services  

11  

Contribu.on  

•  Our  system  has  three  contribu.ons  1.  Summarizes  and  inves.gates  the  current  status  

of  SOS  services  online  today  2.  Highlights  issues  with  developing  a  system  to  

address  a  common  use  case  3.  Presents  a  system  architecture  for  handling  

these  solu.ons  

12  

Related  Work  

•  The  OGC  Catalogue  Service  provides  informa.on  about  available  OGC  services  

•  Not  all  SOS  services  are  registered  in  a  Catalogue  Service  

•  Also,  the  system  must  also  account  for  communica.ng  with  mul.ple  SOS  services  

13  

Related  Work  

•  A  search  engine  is  commonly  used  for  answering  advanced  queries  

•  This  is  a  difficult  process  due  to  varying  URNs  of  observed  proper.es  

•  This  also  doesn’t  account  for  managing  communica.on  with  mul.ple  SOS  services  

14  

Methodology  

15  

Overview  

16  

Logical  Layer  Service  

•  Manages  and  maps  the  logical  concept  of  an  observed  property  to  corresponding  phenomenon  layers  

•  We  use  a  dic.onary  to  manage  our  list  of  observed  proper.es  

•  The  dic.onary  is  manually  created  by  a  data  processing  team  that  interprets  sensor  data  by  phenomenon  types  

17  

Logical  Layer  Service  

•  Dic.onary  terms  are  managed  by  hierarchies  to  facilitate  user  searches  

•  The  mapping  from  dic.onary  terms  to  phenomenon  layers  is  also  done  manually  

•  The  textual  informa.on  of  the  observa.on  offering  and  observed  property  URI  are  interpreted  manually  and  mapped  to  corresponding  dic.onary  terms  

18  

Logical  Layer  Service  

19  

Earth  

Atmosphere   Hydro  

Air   Soil  

.de  level  water  temp  soil  moisture  soil  temp  air  temp  

1

Hierarchy   Dic.onary   Phenomenon  Layer  

(1)  hdp://app.geocens.ca:8171/sos,  Temperature,  urn:ogc:def:property:noaa:ndbc:Air  Temperature  

Transla.on  Engine  

•  The  transla.on  engine  has  four  components  1.  Controller  2.  SOS  Connector  3.  Feeder  4.  Cache  Database  

20  

Transla.on  Engine  

21  

Client  

•  Web  based  front  end  •  Users  select  a  hierarchy,  and  use  the  hierarchy  to  select  an  observed  property  

•  The  client  automa.cally  loads  all  data  for  that  observed  property  from  all  available  SOS  services  

22  

Client  

23  

Experimental  Results  

24  

Data  Mapping  

•  Data  mapping  is  performed  manually,  we  will  not  focus  on  valida.ng  correctness  of  mapping  

•  Instead,  we  will  summarize  the  overall  mappings  

25  

Data  Mapping  

•  The  dic.onary  defines  76  observed  proper.es  •  The  mapping  defines  phenomenon  layers,  so  the  user  does  not  need  to  create  mul.ple  requests  to  mul.ple  SOS  services  

•  For  example,  there  are  369  wind  speed  phenomenon  layers,  across  7  different  SOS  services  

26  

Top  Ten  Observed  Proper.es  with  Highest  Number  of  Mappings  

 Observed Property URN Number of Mappings Number of Services

horizontal_wind_speed 402 2

wind_direction 369 7

wind_speed 55 12

dew_point_temperature 31 4

min_air_temperature 25 14

air_temperature 25 14

max_air_temperature 20 10

dry_bulb_temperature 19 9

mean_air_temperature 18 9

atmospheric_pressure 18 14

27  

Number  of  instances  in  the  real-­‐world  SOS  services  and  the  logical  layer  service  

28  

Data  Access  

•  To  evaluate  the  performance  of  data  access,  we  used  our  system  approach  versus  the  naïve  approach  

•  We  downloaded  recent  observa.on  data  from  sensors  

•  Tes.ng  was  performed  on  Acer  Aspire  M3910  with  Intel®  Core  ™  i7-­‐870  @  2.93GHz  and  4  gigabyte  DIMM  Synchronous  1333  MHz  

29  

Data  loading  latencies  by  using  naïve  solu.on  and  proposed  scheme  

30  

Conclusions  

31  

Conclusions  

•  A  logical  layer  service  and  transla.on  engine  are  proposed  to  solve  data  access  to  mul.ple,  heterogeneous  SOS  services  

•  The  data  mapping  aggregates  similar  phenomenon  layers  

•  The  proposed  data  access  scheme  is  efficient  when  compared  to  a  naïve  approach  

32  

Future  Work  

•  The  work  here  can  be  extended  by  inves.ga.ng  automa.c  and  semi-­‐automa.c  methods  of  mapping,  dic.onary  genera.on,  and  informa.on  retrieval  

•  We  can  leverage  recent  research  in  the  seman.c  web  and  data  mining  for  opening  the  sensor  web  to  end  users  for  data  browsing  

33  

Acknowledgements  

34