Skip to content

Web Interface

Jump to bottom Edit New page
Julien Eberle edited this page Jan 16, 2015 · 23 revisions

This is a presentation of the web interface bundled with GSN. It can be used as a starting point for creating another one.

In GSN we separated the look and feel of the web interface from the underlying processing components. This design enables other users to provide their own web interface over the GSN. In this section we describe both the current server side protocol and the currently available web interface which visualizes the data from the server. While the server side component is fixed with GSN, the client side web interface can be changed based on the users and applications.

Server-Side protocol

GSN provides several HTTP request handlers that can be used to request data about sensors. These are presented hereafter.

/GSN

In GSN, the main requests are received by the the /gsn (gsn.http.ControllerServlet). In GSN we provide several request handlers each of them implements the gsn.http.RequestHandler interface. Each request from the clients has a REQUEST parameter (e.g., http://server/gsn?REQUEST=type) where type is an integer. If there is no type specified, !ControllerServlet assumes type 0. Here are the list of the parameters and the Contant representing them.

  • 0, REQUEST_LIST_VIRTUAL_SENSORS (default).
  • 113, REQUEST_OUTPUT_FORMAT.
  • 114, REQUEST_ONE_SHOT_QUERY.
  • 115, REQUEST_ADDRESSING.
  • 116, REQUEST_ONE_SHOT_QUERY_WITH_ADDRESSING.
  • 901, REQUEST_GML.

The RequestHandler interface two methods:

  • isValid (HttpServletRequest, HttpServletResponse) verifying the validity of the request (presence and validity of the parameters) or responding by and error message if not.
  • handle (HttpServletRequest, HttpServletResponse) which treat the request and send the response in XML format

REQUEST_LIST_VIRTUAL_SENSORS (http://localhost:22001/gsn)

Has the following informations:

  • GSN information from the gsn.xml file (name, author, email, description) .
  • For each valid virtual sensor
  • Virtual Sensor name, description and the timestamp of the most recently produced stream element.
  • The list of the addressing predicates (category=”predicate”)
  • The list of the output fields,their types and their most recent value. The value of the field is only included in the output if it can be easily converted to String format. If the type of a field is binary (e.g., a JPEG image), as the value, the controller returns a URL pointing to the /field servlet gsn.http.FieldDownloadServlet to retrive the actual binary data.

Example output:

<gsn name="Container" author="EPFL" email="ali.salehi@epfl.ch" description="Not Provided">
  <virtual-sensor name="invmaccess" last-modified="1173280806000" description="MyVS">
    <field name="image" type="binary:image/jpeg">/field?vs=invmaccess&field=DATA&pk=2868</field>
    <field name="timed" type="long" description="The timestamp associated with the stream element">1174999988339</field>
    <field name="geographical" category="predicate">BC 143, EPFL, Lausanne </field>
  </virtual-sensor>
</gsn>

REQUEST_OUTPUT_FORMAT (http://server:port/gsn?REQUEST=113&name=VirtualSensorName)

Provides the output structure of a given virtual sensors. The only parameter needed is name of the virtual sensor the user want the description of.

REQUEST_ONE_SHOT_QUERY (http://server:port/gsn?REQUEST=114&name=VirtualSensorName)

This request is handled by the class gsn.vsensor.http.!OneShotQueryHandler. This servlet executes a one shot query over the GSN's internal table and presents the results in the form of the stream elements. This request needs the following parameters:

  • name, the name of the virtual sensor [mandatory]
  • condition: the WHERE part of the request (ex: LATITUDE > 100 AND light < 10) [optional]
  • fields: an array of the requested fields in the stream elements. If not present, * is used [optional]
  • window: the number last elements wanted (1 if not present) [optional]

Example: get latest three (3) values for sensor wan7 http://localhost:22001/gsn?REQUEST=114&name=wan7&window=3

result:

<result>
  <stream-element>
    <field name="RECORD">73707</field>
    <field name="RELATIVE_HUMIDITY">98.0</field>
    <field name="AIR_TEMPERATURE">7.04</field>
    <field name="WIND_SPEED_SCALAR_AV">1.563</field>
    <field name="timed">25/06/2009 08:10:00 +0100</field>
  </stream-element>
  <stream-element>
    <field name="RECORD">73706</field>
    <field name="RELATIVE_HUMIDITY">98.6</field>
    <field name="AIR_TEMPERATURE">6.866</field>
    <field name="WIND_SPEED_SCALAR_AV">1.43</field>
    <field name="timed">25/06/2009 08:00:00 +0100</field>
  </stream-element>
  <stream-element>
    <field name="RECORD">73705</field>
    <field name="RELATIVE_HUMIDITY">96.9</field>
    <field name="AIR_TEMPERATURE">6.813</field>
    <field name="WIND_SPEED_SCALAR_AV">1.419</field>
    <field name="timed">25/06/2009 07:50:00 +0100</field>
  </stream-element>
</result>

Example: get latest value from sensor wan7 that satisfies the condition that relative_humidity >= 99 http://localhost:22001/gsn?REQUEST=114&name=wan7&condition=relative_humidity%3E=99

Result:

<result>
  <stream-element>
    <field name="RECORD">73698</field>
    <field name="RELATIVE_HUMIDITY">99.8</field>
    <field name="AIR_TEMPERATURE">5.567</field>
    <field name="WIND_SPEED_SCALAR_AV">0.354</field>
    <field name="WIND_SPEED_VECTOR_AV">0.285</field>
    <field name="WIND_DIRECTION">60.51</field>
    <field name="WIND_DIRECTION_STDEV">26.12</field>
    <field name="WIND_SPEED_MAX">1.721</field>
    <field name="SNOW_SURFACE_TEMPERATURE">5.731</field>
    <field name="SNOW_HEIGHT">1.842</field>
    <field name="INCOMING_SHORTWAVE_RADIATION">279.8</field>
    <field name="OUTGOING_SHORTWAVE_RADIATION">81.2</field>
    <field name="INCOMING_LONGWAVE_RADIATION">246.7</field>
    <field name="OUTGOING_LONGWAVE_RADIATION">345.8</field>
    <field name="timed">25/06/2009 06:40:00 +0100</field>
  </stream-element>
</result>

REQUEST_ADDRESSING (http://localhost:22001/gsn?REQUEST=115&name=VirtualSensorName)

Given the name of the virtual sensor, it provides the addressing predicates associated with the virtual sensor. It is very similar to REQUEST_OUTPUT_FORMAT.

Example output:

<virtual-sensor name="invmaccess" last-modified="1173280806000">
  <predicate key="geographical">BC 143, EPFL, Lausanne</predicate>
</virtual-sensor>

REQUEST_ONE_SHOT_QUERY_WITH_ADDRESSING (http://localhost:22001/gsn?REQUEST=116&name=VirtualSensorName)

This request is actually the combination of the REQUEST_ONE_SHOT_QUERY and REQUEST_ADDRESSING in one request. The parameters are the union of the specified types.

Example output:

<result>
  <stream-element>
    <field name="DATA">/field?vs=invmaccess&field=DATA&pk=15102</field>
    <field name="timed">1175006917711</field>
    <field name="geographical">BC 143, EPFL, Lausanne</field>
  </stream-element>
</result>

You might ask why we need this request if we can get the same result by combining the 115 and 114 ? The answer is the performance, establishing the TCP connections are expensive.

REQUEST_GML (http://localhost:22001/gsn?REQUEST=901&name= VirtualSensorName)

This is similar to /gsn request (request for listing virtual sensors) but returns data in the standard GML format (Geography Markup Language). If a sensor name is provided through parameter name, it will provide data only for the specified sensor.

Example output:

<gsn:FeatureCollection xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="./gsn.xsd" xmlns:gsn="http://gsn.ch/" xmlns:gml="http://www.opengis.net/gml"> 
  <gml:featureMember>
    <gsn:sensors fid="wan3">
      <gsn:geometryProperty>
        <gml:Point>
          <gml:coordinates>9.7791416666,46.802105555</gml:coordinates>
        </gml:Point>
      </gsn:geometryProperty>
      <gsn:sensor>wan3</gsn:sensor>
      <gsn:geographical>Davos, Switzerland.</gsn:geographical>
      <gsn:latitude>46.802105555</gsn:latitude>
      <gsn:longitude>9.7791416666</gsn:longitude>
      <gsn:altitude>2341</gsn:altitude>
      <gsn:name>WAN3</gsn:name>
      <gsn:gps_precision>10</gsn:gps_precision>
      <gsn:slope>0</gsn:slope>
      <gsn:exposition>NULL</gsn:exposition>
      <gsn:metadata>http://www.swiss-experiment.ch/index.php/Wannengrat:Wan3</gsn:metadata>
      <gsn:record>892</gsn:record>
      <gsn:relative_humidity>99.8</gsn:relative_humidity>
      <gsn:air_temperature>7.828</gsn:air_temperature>
      <gsn:wind_speed_scalar_av>1.722</gsn:wind_speed_scalar_av>
      <gsn:wind_speed_vector_av>1.575</gsn:wind_speed_vector_av>
      <gsn:wind_direction>283.8</gsn:wind_direction>
      <gsn:wind_direction_stdev>23.71</gsn:wind_direction_stdev>
      <gsn:wind_speed_max>3.833</gsn:wind_speed_max>
      <gsn:snow_surface_temperature>11.43</gsn:snow_surface_temperature>
      <gsn:snow_height>9.45</gsn:snow_height>
      <gsn:incoming_shortwave_radiation>-2.694</gsn:incoming_shortwave_radiation>
      <gsn:outgoing_shortwave_radiation>0.364</gsn:outgoing_shortwave_radiation>
      <gsn:incoming_longwave_radiation>336.3</gsn:incoming_longwave_radiation>
    </gsn:sensors>
  </gml:featureMember>
</gsn:FeatureCollection>

Understanding The Outputs

As explained in the design section, the gsn webapp use an xml api to give data. All the information concerning a virtual sensor is regrouped into a single virtual-sensor block. All the different types of data (dynamic, structure, predicate,..) are merged into a single entity as it is much more efficient than having to query multiple times the servlet. The overall size of a single block, as it is only text, costs far less than the latency of multiple queries. Moreover, the main gsn webapp page requires all types of data at the initialization, thus merging them makes sense.

Every type of data is mapped into the field block following the rules below. Field names are converted into lowercase and fields are sorted by type in the same order than below.

To begin with, the virtual-sensor block is opened with the following included attributes:

  • name: virtual sensor name (unique) ;
  • last-modified: last-modified datetime in unix format ;
  • description: virtual sensor description.

Here is a sample of the xml output from the servlet:

<gsn name="gsn" author="cb" email="a.b@epfl.ch" description="none">
  <virtual-sensor name="vs" last-modified="1171105166765">
    <field name="temp" type="long" description="none">-5</field>
  </virtual-sensor>
</gsn>

Then, the dynamic fields with their data are mapped from the output-structure block of the xml config of the virtual sensor into a unique field block. Below is a xml config sample:

<gsn name="gsn" author="cb" email="cb@epfl.ch" description="none">
  <virtual-sensor name="vs" last-modified="1171105166765">
    <field name="temp" type="long" description="none">-5</field>
  </virtual-sensor>
</gsn>

It would be mapped into the following line in the xml output from the servlet:

<gsn name="gsn" author="cb" email="cb@epfl.ch" description="none">
  <virtual-sensor name="vs" last-modified="1171105166765">
    <field name="temp" type="long" description="none">-5</field>
  </virtual-sensor>
</gsn>

An additional dynamic field is added with the timestamp in unix format as in the following xml sample:

<gsn name="gsn" author="cb" email="cb@epfl.ch" description="none">
  <virtual-sensor name="vs" last-modified="1171105166765">
    <field name="temp" type="long" description="none">-5</field>
  </virtual-sensor>
</gsn>

Afterwards, the static predicate fields are mapped from the adressing block of the xml config of the virtual sensor into a unique field block as well if they exist. Below is a predicate xml config sample:

<gsn name="gsn" author="cb" email="cb@epfl.ch" description="none">
  <virtual-sensor name="vs" last-modified="1171105166765">
    <field name="temp" type="long" description="none">-5</field>
  </virtual-sensor>
</gsn>

It would be mapped into the following line in the xml output from the servlet:

<field name="latitude" category="predicate">37.4</field>

Additionally, the webinputs block from the xml config of the virtual sensor are mapped into a unique field block if they exist. They are not kept hierarchically by command anymore. Below is a xml config sample:

<web-input password="test">
  <command name="cmd1">
    <field name="control" type="*binary:2mb">Binary upload</field>
  </command>
</web-input>

It would be mapped into the following line in the xml output from the servlet:

<field command="cmd1" name="control" category="input" type="*binary:2mb" description="Binary upload"/>

Finally, the virtual-sensor block is closed.

</virtual-sensor>

/DATA

Allows getting aggregated data from a sensor as CSV or XML. The /data requests are handled by gsn.http.DataDownload servlet.

Parameters:

  • vsName, the name of the virtual sensor we need.
  • fields, there can be multiple parameters with this name pointing to different fields in the stream element.
  • display, if the output in CSV format is needed, the value of this parameter should be CSV otherwise XML is the default.
  • delimiter, useful for CSV output (can be "tab", "space", "other")
  • otherdelimiter, useful in the case of having delimiter=other
  • groupby, can point to one of the fields in the stream element. In case groupby=timed then the parameter groupbytimed points to the period for which data should be aggregated [in milliseconds].
  • nb, gives the maximum number of elements to be outputed (most recent values first). If no number is given, all data is returned.

Example: Getting 5 latest values for virtual sensor wan3, for the fields air_temperature and timed http://localhost:22001/data?vsName=wan3&fields=air_temperature%20&fields=timed&nb=5

Result:

<data>
  <line>
    <field>air_temperature </field>
    <field>timed</field>
  </line>
  <line>
    <field>7.828</field>
    <field>28/06/2009 20:50:00 +0100</field>
  </line>
  <line>
    <field>7.762</field>
    <field>28/06/2009 20:40:00 +0100</field>
  </line>
  <line>
    <field>8.02</field>
    <field>28/06/2009 20:10:00 +0100</field>
  </line>
  <line>
    <field>8.23</field>
    <field>28/06/2009 19:50:00 +0100</field>
  </line>
  <line>
    <field>8.39</field>
    <field>28/06/2009 19:40:00 +0100</field>
  </line>
</data>

/MULTIDATA

This complex request allow downloading data from multiple virtual sensors and is the cornerstone to implement the data download part of the web UI. Requests from /multidata are handled by [gsn.http.MultiDataDownload] servlet. This query supports the features listed below and the combination of them.

  • Data selection per field/vs name
  • Multiple output format (xml, csv, ..)
  • Limits on the resultset
  • Aggregation of fields
  • Conditions on fields

General Options

Option Description Allowed Values Default
vs[n] Virtual sensor. n specifies the number of the virtual sensor for later options, e.g. vs[0]=ts, vs[1]=rh All or the name of the vs mandatory
field[n] Parameter name. n must match the n in the vs option All or the names of the parameters (comma separated) mandatory
time_format The format of the time stamp unix, iso unix
download_format The format of the download csv, xml, pdf csv

Example: Getting all the data from the memorymonitorvs http://localhost:22001/multidata?vs[0]=memorymonitorvs&field[0]=All

Result:

##vsname:memorymonitorvs
##query:select heap, non_heap, pending_finalization_count, timed from memorymonitorvs order by timed desc 
#heap,non_heap,pending_finalization_count,timed
5.9354368E7,2.0081632E7,0.0,20/07/2010 10:37:03 +0200
9.598524E7,2.0081632E7,0.0,20/07/2010 10:37:00 +0200
1.21801808E8,2.0081632E7,0.0,20/07/2010 10:36:56 +0200
...

Example: Getting all the data from a subset of fields of the memorymonitorvs http://localhost:22001/multidata?vs[0]=memorymonitorvs&field[0]=heap,non_heap

Result:

##vsname:memorymonitorvs
##query:select heap,non_heap, timed from memorymonitorvs order by timed desc 
#heap,non_heap,timed
1.26997632E8,2.0094296E7,20/07/2010 10:36:05 +0200
9.036648E7,2.0086296E7,20/07/2010 10:36:03 +0200
1.2811284E8,2.0086296E7,20/07/2010 10:36:00 +0200
9.7357296E7,2.0086296E7,20/07/2010 10:35:58 +0200
...

Example: Getting all the data from the field heap of any virtual sensor http://localhost:22001/multidata?vs[0]=All&field[0]=heap

Result:

##vsname:memorymonitorvs
##query:select heap, timed from memorymonitorvs order by timed desc 
#heap,timed
7.0959168E7,20/07/2010 10:40:37 +0200
7.516016E7,20/07/2010 10:38:54 +0200
1.1344448E8,20/07/2010 10:38:51 +0200
...
##vsname:memorymonitorvs2
##query:select heap, timed from memorymonitorvs2 order by timed desc 
#heap,timed
9.0615168E7,20/07/2010 10:40:37 +0200
1.0960336E8,20/07/2010 10:40:35 +0200
...

Example: Getting from a set of virtual sensor / fields http://localhost:22001/multidata?vs[0]=memorymonitorvs&field[0]=heap&vs[1]=memorymonitorvs2&field[1]=non_heap

Result:

##vsname:memorymonitorvs
##query:select heap, timed from memorymonitorvs order by timed desc
#heap,timed
1.0851668E8,20/07/2010 10:46:36 +0200
6.381104E7,20/07/2010 10:46:33 +0200
...
##vsname:memorymonitorvs2
##query:select non_heap, timed from memorymonitorvs2 order by timed desc
#non_heap,timed
2.0189496E7,20/07/2010 10:46:36 +0200
2.0189496E7,20/07/2010 10:46:32 +0200
...

Example: Format options

http://localhost:22001/multidata?vs[0]=memorymonitorvs&field[0]=All&download_format=xml&time_format=iso&download_mode=inline

Result:

<result>
  <!-- select heap, non_heap, pending_finalization_count, timed from memorymonitorvs order by timed desc  -->
  <data vsname="memorymonitorvs">
    <header>
      <field>heap</field>
      <field>non_heap</field>
      <field>pending_finalization_count</field>
      <field>timed</field>
    </header>
    <tuple>
      <field>7.738044E7</field>
      <field>2.0516416E7</field>
      <field>0.0</field>
      <field>2010-07-20T12:06:30.449+0200</field>
    </tuple>
    ...
    <tuple>
      <field>1.16923184E8</field>
      <field>2.0516416E7</field>
      <field>0.0</field>
      <field>2010-07-20T12:06:26.185+0200</field>
    </tuple>
  </data>
</result>

Limit Options

Option Description Allowed Values Default
nb Enable (SPECIFIED) or Disable the count based limit SPECIFIED, ALL ALL
nb_value The number of points (used where nb=SPECIFIED) Number of points - this can be limited by the gsn instance no default
from Start time of the query dd/MM/yyyy+hh:mm:ss e.g. 01/06/2009+00:00:00 no default - if not entered, the number of points will be from the latest x points
to End time of the query dd/MM/yyyy+hh:mm:ss e.g. 01/07/2009+00:00:00 no default - if not entered, the number of points will be from the latest x points

Example: Limiting the number of results (count based) http://localhost:22001/multidata?vs[0]=memorymonitorvs&field[0]=All&nb_value=1&nb=SPECIFIED

Result:

##vsname:memorymonitorvs
##query:select heap, non_heap, pending_finalization_count, timed from memorymonitorvs order by timed desc (size: 1 offset: 0)
#heap,non_heap,pending_finalization_count,timed
9.8472568E7,2.0189496E7,0.0,20/07/2010 10:47:46 +0200

Example: Limiting the number of results (time based) http://localhost:22001/multidata?vs[0]=memorymonitorvs&field[0]=All&from=20/07/2010+10:52:00&to=20/07/2010+10:53:00

Result:

##vsname:memorymonitorvs
##query:select heap, non_heap, pending_finalization_count, timed from memorymonitorvs where  timed > 1279615920000 and  timed <= 1279615980000 order by timed desc 
#heap,non_heap,pending_finalization_count,timed
8.5764784E7,2.020156E7,0.0,20/07/2010 10:52:57 +0200
1.17890024E8,2.020156E7,0.0,20/07/2010 10:52:54 +0200
...
1.04680808E8,2.0199512E7,0.0,20/07/2010 10:52:01 +0200

Aggregation Options

Option Description Allowed Values Default
agg_function The aggregation function applied to the data -1 = disabled, avg = average, max = maximum, min = minimum disabled
agg_period The period over which the aggregation is to be performed Value of aggregation period, -1 = disabled. disabled
agg_unit A multiplier for the aggregation period 1 = ms, 1000 = s, 60000 = min, 3600000 = hours, -1 = disabled. Any value can be used. disabled

Example: Aggregation http://localhost:22001/multidata?vs[0]=memorymonitorvs&field[0]=All&agg_function=avg&agg_unit=60000&agg_period=2

Result:

##vsname:memorymonitorvs
##query:select avg(heap) as heap, avg(non_heap) as non_heap, avg(pending_finalization_count) as pending_finalization_count, avg(timed) as timed, floor(timed/120000) as aggregation_interval from memorymonitorvs group by aggregation_interval desc 
#heap,non_heap,pending_finalization_count,aggregation_interval,timed
9.364184E7,2.01426E7,0.0,1.0663469E7,20/07/2010 10:58:05 +0200
9.1961435368421E7,2.0158626947368E7,1.2368421052632,1.0663468E7,20/07/2010 10:56:58 +0200
9.7796401513514E7,2.0189900756757E7,1.0810810810811,1.0663467E7,20/07/2010 10:54:56 +0200
...

Condition on Fields

Option Description Allowed Values Default
c_join[n] The equivalent of the AND/OR selection box in the conditions section on the web interface. n should match the n in the vs option and, or, -1 = disabled disabled
c_vs[n] The virtual sensor to which the condition is to be applied (e.g. you can select wan 1(rh) where 0<wan2(ta)<20). n should match the n in the vs option All or the name of the vs All (not used if c_join=-1)
c_field[n] The parameter to which the condition is to be applied (e.g. you can select wan 1(rh) where 0<wan2(ta)<20). n should match the n in the vs option All or the name of the parameter All (not used if c_join=-1)
c_min[n] The minimum value of the condition to be met. n should match the n in the vs option -inf or the minimum value All (not used if c_join=-1)
c_max[n] The maximum value of the condition to be met. n should match the n in the vs option -inf or the maximum value All (not used if c_join=-1)

Example: Conditions (max value on all fields) http://localhost:22001/multidata?vs[0]=memorymonitorvs&field[0]=heap&c_vs[0]=memorymonitorvs&c_field[0]=All&c_join[0]=and&c_min[0]=-inf&c_max[0]=80000000

Result:

##vsname:memorymonitorvs
##query:select heap, timed from memorymonitorvs where  heap <= 80000000 order by timed desc 
#heap,timed
6.654476E7,20/07/2010 11:21:06 +0200
7.0699696E7,20/07/2010 11:21:00 +0200
7.3262672E7,20/07/2010 11:20:54 +0200
...

Example: Conditions (min value on all fields) http://localhost:22001/multidata?vs[0]=memorymonitorvs&field[0]=heap&c_vs[0]=memorymonitorvs&c_field[0]=All&c_join[0]=and&c_min[0]=80000000&c_max[0]=%2Binf

Result:

##vsname:memorymonitorvs
##query:select heap, timed from memorymonitorvs where  heap > 80000000 order by timed desc 
#heap,timed
9.8710184E7,20/07/2010 11:19:34 +0200
9.3268336E7,20/07/2010 11:19:30 +0200
...

Example: Conditions (range of values) http://lsir-hydrosys01:22007/multidata?vs[0]=All&field[0]=heap&c_vs[0]=memorymonitorvs&c_field[0]=All&c_join[0]=and&c_min[0]=50000000&c_max[0]=60000000

Result:

##vsname:memorymonitorvs
##query:select heap, timed from memorymonitorvs where  heap > 50000000 and  heap <= 60000000 order by timed desc
#heap,timed
5.8624072E7,20/07/2010 11:12:09 +0200
5.79398E7,20/07/2010 11:04:51 +0200
5.7980264E7,20/07/2010 11:01:32 +0200
##vsname:memorymonitorvs2
##query:select heap, timed from memorymonitorvs2 order by timed desc
#heap,timed
9.1545288E7,20/07/2010 11:13:23 +0200
1.19064056E8,20/07/2010 11:13:21 +0200
8.7706664E7,20/07/2010 11:13:16 +0200
...

Extended Options for the pdf download format

Option Description Allowed Values Default
reportclass The name of the compiled Jasper report class. report-default report-default

/FIELD

This request allows downloading the value of a field given sensor name, fieldname and primary key. This request is useful for downloading binary data. Requests from /field are handled by gsn.http.FieldDownloadServlet servlet.

Example: Requesting the plot of an R simpleplot http://localhost:22001/field?vs=SIMPLEPLOT&field=GSN_PLOT&pk=10

Result: binary object (image in this case)

chart

/UPLOAD

Allows uploading data to a virtual sensor, which supports uploads from web. Requests from /upload are handled by gsn.http.FieldUpload servlet.

/GRIDDATA

Allows downloading grid data saved in GSN using the Grid-data-wrapper.

Parameters:

  • sensor: virtual sensor name
  • from: starting timestamp (format yyyy-MM-dd'T'HH:mm:ss)
  • to: ending timestamp (format yyyy-MM-dd'T'HH:mm:ss)

Example: http://localhost:22001/griddata?sensor=grid1&from=2013-10-01T00:00:00&to=2013-11-29T00:00:00

Result:

# Query: select * from grid1 where timed >= 1380578400000 and timed <= 1385679600000
# PK 1
timed 1385333993000
NCOLS 4
NROWS 6
XLLCORNER 0.0
YLLCORNER 0.0
CELLSIZE 50.0
NODATA_VALUE -9999.0
-9999.0 -9999.0 5.0 2.0 
-9999.0 120.0 100.0 36.0 
3.0 8.0 35.0 10.0 
32.0 42.0 50.0 6.0 
88.0 75.0 27.0 9.0 
13.0 5.0 1.0 -9999.0 

PK 2
timed 1385333994000
NCOLS 4
NROWS 6
XLLCORNER 0.0
YLLCORNER 0.0
CELLSIZE 50.0
NODATA_VALUE -9999.0
-9999.0 -9999.0 5.0 2.0 
-9999.0 2.0 100.0 36.0 
3.0 8.0 35.0 10.0 
32.0 42.0 50.0 6.0 
88.0 75.0 27.0 9.0 
13.0 5.0 1.0 -9999.0 

PK 3
timed 1385333995000
NCOLS 4
NROWS 6
XLLCORNER 0.0
YLLCORNER 0.0
CELLSIZE 50.0
NODATA_VALUE -9999.0
-9999.0 -9999.0 5.0 2.0 
-9999.0 29.0 100.0 36.0 
3.0 8.0 35.0 10.0 
32.0 42.0 50.0 6.0 
88.0 75.0 27.0 9.0 
13.0 5.0 1.0 -9999.0 

PK 4
timed 1385333996000
NCOLS 4
NROWS 6
XLLCORNER 0.0
YLLCORNER 0.0
CELLSIZE 50.0
NODATA_VALUE -9999.0
-9999.0 -9999.0 5.0 2.0 
-9999.0 25.0 100.0 36.0 
3.0 8.0 35.0 10.0 
32.0 42.0 50.0 6.0 
88.0 75.0 27.0 9.0 
13.0 5.0 1.0 -9999.0 

PK 5
timed 1385333997000
NCOLS 4
NROWS 6
XLLCORNER 0.0
YLLCORNER 0.0
CELLSIZE 50.0
NODATA_VALUE -9999.0
-9999.0 -9999.0 5.0 2.0 
-9999.0 23.0 100.0 36.0 
3.0 8.0 35.0 10.0 
32.0 42.0 50.0 6.0 
88.0 75.0 27.0 9.0 
13.0 5.0 1.0 -9999.0 

PK 6
timed 1385333998000
NCOLS 4
NROWS 6
XLLCORNER 0.0
YLLCORNER 0.0
CELLSIZE 50.0
NODATA_VALUE -9999.0
-9999.0 -9999.0 5.0 2.0 
-9999.0 22.0 100.0 36.0 
3.0 8.0 35.0 10.0 
32.0 42.0 50.0 6.0 
88.0 75.0 27.0 9.0 
13.0 5.0 1.0 -9999.0

/GEODATA

This call allows making basic spatial queries using the open-source Java GIS toolkit JTS (Java Topology Suite) or PostGIS extension to Postgres. Result is returned as comma-separated values. It allows composing the tables corresponding to stations in columns or in rows.

/MODELDATA

This call allows making queries on models attached to modelling virtual sensors. Result is returned as xml values.

Add a custom footer

Welcome to the gsn wiki!

Clone this wiki locally