The server will provide data and images in response to a command given in the URL. Commands are given as Key - Value pairs and all commands must have a Service key and a Request key. The server conforms to the OGC convention where the key can be of any case, but the value is case sensitive. This means you can have SERVICE=Hilltop or Service=Hilltop, but Service=hilltop won't work.
Valid Service keys are Hilltop, WFS and SOS. WFS will provide a list of sites and measurements. You can provide a bounding box so you get sites that will display on a map. Use SOS to get the time series data for a site and measurement combination. The WFS and SOS components try to comply with the OGC standards and you can view these at www.opengeospatial.org .
The Hilltop service supplies data and images. It will also accept forms data from a table. Contact Hilltop Software for a copy of the documentation.
Information about the available data is returned using the Web Feature Service, WFS. The Hilltop Server implements three requests, being GetCapabilities, DescribeFeatureType, and GetFeature. The capabilities request lists the available feature types, and also describes the very limited filters the server will accept. The DescribeFeatureType gives details for the feature types. You can see the response from these requests in a web browser, as follows. Neither of the commands takes any other parameters.
http://host/data.hts?Service=WFS&Request=GetCapabilities
http://host/data.hts?Service=WFS&Request=DescribeFeatureType
The SiteList feature type is a list of sites, hence the name. Each entry in the list is the name of the site and its location. The MeasurementList feature type expands on the site list, but gives the measurements at the site, and the time range of the measurement. The GetFeature request sends the data for the feature identified in the TypeName key. The request will also accept a bounding box. The default coordinate reference system is latitude and longitude in WGS84, but you can define the box in eastings and northings with a urn at the end. Valid urn's are urn:ogc:def:crs:EPSG::2193 for NZTM2000, and 27200 for NZ Map Grid.
http://host/data.hts?Service=WFS&Request=GetFeature&TypeName=SiteList
http://host/data.hts?Service=WFS&Request=GetFeature&TypeName=MeasurementList
http://host/data.hts?Service=WFS&Request=GetFeature&TypeName=SiteList&BBox=-46.48797124,-167.65999182,-44.73293297,168.83236546
The Hilltop Server uses Sensor Observation Service, SOS, to transmit the data. The SOS implementation is restricted and the server only accepts the GetCapabilites and GetObservation requests. The SOS service doesn’t provide any meta-data, and only sends the data in WaterML 2. The GetObservation request accepts a site name, measurement and time range. The names are of the keys are:
| Site Name | FeatureOfInterest |
| Measurement | ObservedProperty |
| Time Range | TemporalFilter |
The TemporalFilter key determines the time range of the request. The format is a "Time Interval" as defined in ISO8601, and there is nice article in Wikipedia about this standard. You can provide both a start time and a finish time, or combinations of time and duration. A time by itself makes the server start at the given time and read to the end of the data. A duration by itself sets the start time back from the end of the available data. Examples are:
TemporalFilter=om:phenomenonTime,2010-01-01T12:00:00/2011-07-01T14:00:00
TemporalFilter=om:phenomenonTime,2010-01-01T00:00/P1Y
TemporalFilter=om:phenomenonTime,2010-01-01T00:00
TemporalFilter=om:phenomenonTime,P1Y
A temporal filter is optional, and not providing one will make the server deliver the most recent value. An example of a GetObservation request is:
http://host/data.hts?Service=SOS&Request=GetObservation&FeatureOfInterest=Alphabet River at Crossword&
ObservedProperty=Stage&TemporalFilter=om:phenomenonTime,2012-01-01T00:00/2012-11-01T00:00