make WCS/WMS client more configurable

[Peter Baumann]

when deployed some client behavior is site dependent. It should be possible to easily configure parameters like service endpoint, WMS and WCS WorldWind starting position, and likely more.

2 options I see:

• have a specific JS source file with constant definitions available for admin editing. This file would get loaded as any JS file.
  • Pro: powerful, con: easy to mess up if used wrongly.
• add config file parameters. Pro:
  • Pro: somewhat cleaner approach. Con: more effort for parsing, config file error handling, etc.

Opinions?

[Vlad Merticariu]

A file called wcs-client.properties should be added to etc/ and served by petascope.

Initially, the file would only contain example queries to be shown in the Examples dropdown in the ProcessCoverages tab, later we can add other properties as well (e.g. which tabs to show / hide, wwd position etc).

I propose the following format for the file:

• normal properties file, just like petascope.properties
• special section for defining queries:
  • delimited by keywords QUERY_SECTION_START and QUERY_SECTION_END
  • in-between, each query definition starts with a line of the form QUERY: SomeTitle, and ends with the line QUERY_END. The query body is represented by all characters in between the lines of QUERY: and QUERY_END, which allows formatting, breaklines etc to be captured.

Example wcs-client.properties attached.

[Bang Pham Huu]

I don't like (strongly object) the idea from Vlad because it is too verbose, one should use JSON-like as with WCST_Import ingredients file configuration and can be consumed from WSClient directly as Javascript code.

{
   "wcps-queries: [
       { 
	       "name": "query1",
			"description": "test",
			"query": `very long query1`,
        },
		{ 
	       "name": "query2",
			"description": "test",
			"query": `very long query2`,
        }
    ]
}

[Vlad Merticariu]

Having settings files as code is bad practice. We would need to call eval() in the client to evaluate the code, and even then we don't know what the code does (how do you know how the admin called the variable containing the queries, so you can access it? conventions on variable names? what if there's a clash?)

Besides that, we add a requirement on the administrator to know javascript.

[Vlad Merticariu]

P.S. Please write the queries in the attached wcs-client.properties in the JS syntax that you proposed, then compare verbosity of the 2 files.

[Dimitar Misev]

My small changes for a slightly simplified syntax:

#Comments start with #, like in all properties files

#Dummy property setting the default zoom in wwd
wwd.default-zoom-level = 100
 
query = perform ndvi
image>>for $c in (Sentinel) return
  encode(
    ($c.0 - $c.1) / ($c.0 + $c.1)
  "jpeg")
===

query = subset 2D coverage
image>>for $c in (Sentinel) return
  encode($c[Lat(0:10), Long(0:10)], "jpeg")
===

• configurations are key = value
• if key is query, then the value is the query description
  • the query itself starts on the next line until a line that starts with === is reached