Add support for REST services

[xhqiao89]

jirikadlec2[CodePlex]
We need to add support for REST services in the Download plugin: 1) Recognizing a valid data sites layer: If a point layer has the columns: SiteCode, VarCode, StartDate, EndDate, WaterMLUri, then it is a valid REST-enabled Data Sites layer. This layer should have the pop-up functionality enabled.

2) Downloading the data in DownloadManager: If the layer has a WaterMLUri column, then the download manager should get the xml from this Url instead of using WaterOneFlowClient / SOAP. For example,

http://midgewater.twdb.state.tx.us/tpwd/GetValues?location=TPWD:275107_970132variable=TPWD:seawater_salinitystartDate={time:start}endDate={time:end}

is a valid WaterML REST uri. The tokens {time:start} and {time:end} should be replaced by the values of the StartTime and EndTime columns in this case.

Attached is a shapefile that has the WaterMLUri column.

[xhqiao89]

jirikadlec2[CodePlex]
Here is an example of a valid WaterML REST GetValues URL used by the PHP HydroServer version:

http://ogimet.hydrodata.org/services/cuahsi_1_1.asmx/GetValuesObject?location=OGIMETEU:080750-99999%20LEBG=OGIMETEU:Prec%20%28mm%29==

The scheme is {SERVER}/services/cuahsi_1_1.asmx/GetValuesObject?location={SITE_CODE}variable={VARIABLE_CODE}startDate={START_DATE}endDate={END_DATE}

SITE_CODE, VARIABLE_CODE, START_DATE, END_DATE are the parameters. If START_DATE or END_DATE are not specified than all data from the site and variable is downloaded.

[xhqiao89]

ericch[CodePlex]
See similar issue: https://hydrodesktop.codeplex.com/workitem/8691

[xhqiao89]

cuylerfris[CodePlex]
Discussion required - leaving marked as proposed

[xhqiao89]

jirikadlec2[CodePlex]
Please hold off working on this item until the WaterML 2.0 data cart schema is approved (expected end February 2012)

[xhqiao89]

jirikadlec2[CodePlex]
My vote is to support RecordType = ObservationsCore. (see attached document)

Reason for my vote: Some services still don't support the REST protocol and only support the SOAP protocol.

This also changes the format of the Data Sites layer. The Data Sites layer should also have the same fields as the required fields in ObservationsCode (search result layer creation needs to be changed)

[xhqiao89]

twhitvine[CodePlex]
Yes, bold indicates required field. I agree that the Data Sites layer should comply with the spec. Let's see if we can get agreement from the team about which spec to use.

[xhqiao89]

jirikadlec2[CodePlex]
Tim, Thank you for attaching the document. I suggest that the HydroDesktop Data Sites layer is modified to comply with the specification. What is the meaning of the bold field names? are these required fields?

[xhqiao89]

twhitvine[CodePlex]
WaterMLURI could also represent the URI for a SOAP service. We need to nail down the catalog spec first so we know what fields to expect. For example, there's a version with RecordType = ObservationsCore in which the ServType field indicates the service type, REST or SOAP, and WaterMLURI then is either the REST or SOAP endpoint. But there's another version with RecortType = ObservationsREST and another one with RecordType = ObservationsRESTLite in which there is no ServType field, and the WaterMLURI field is assumed to store the REST URI to directly access the time series.

Note that the salinity shapefile example in the file attachments is not a correctly formed observations catalog. I'll attach a document which lists the fields for the MANY different varieties of the catalog floating around. We really need to pick one and stick with it.