Home · All Classes · Functions · Building · Tuning 

How to tune SVMT for other purposes

Although SVMT was originally developped to serve the purpose of monitoring large ESO surveys operations, a lot of care has been taken to keep the client and the server generic enough to allow re-using it for other purpose.

Tuning the Client

As explained in the Architecture Overview section, the SVMT client dynamically re-download its configuration and GUI files at each startup. Changing the look & feel and tuning the list of categories displayed in the right panel is therefore just a matter of changing the corresponding files on the server side. Because the client itself doesn't need to be changed at all, the same binary as the one used for the ESO survey can be used for different purposes. It just needs to know where the modified SVMT Web Service is located.

By default, the SVMT client will assume that the SVMT Web Service is located at http://svmt.hq.eso.org/1.0.1 . To change this default behaviour, simply set a different web service root URL in the main stellarium configuration file config.ini. This is done by adding (or modifying) the following lines to your config.ini file:

[SVMT]
remoteServiceBaseUrl                = http://myServiceUrl/

Tuning the Server

Now that we told our client where to look for our modified version of the SVMT Web Service, we need to set it up. The work required to do that is the following:

1- Create the fieldsList.json

The fieldsList.json file defines the list of fields which you want to be able to query on in the client. This file must be tailored to your own data and be deployed on our modified Web Service. It is composed of a list of JSON object, one per field with the following format:

[
...,
{
    "fieldId": "instrument",            // The name used to reference a field in the queries
    "humanName": "Instrument",          // Human name displayed in the GUI
    "type": "string",                   // The type of data. Must be one of string, float, int, list, map, or spatialRegion.
    "widgetType": "tags",               // Define the widget to use in the GUI for displaying/querying the field. Must be one of tags, range, 
                                        // fullTextSearch or can be left undefined if the no GUI element should relfect this field.
    "priority": 5,                      // Lower values will cause the field to appear higher in the category list of the GUI.
    "description": "Instrument name"    // A longer description of the field.
},
...
]

Optionnally a description of the axis can be added, e.g. if the field has a unit. This axis property is a list of one or more axis defining a label (for display only), a unit (for display only) and a scaling and invert scaling function which is used to scale the values when displaying them in the GUI, e.g. in the range/histogram widget.

{
    "fieldId": "area",
    "humanName": "Footprint Area",
    "type": "float",
    "axis": [{"label": "area", "unit": "deg^2", "scaleFunction": "return x*3282.8063500117441;", "invertScaleFunction": "return x/3282.8063500117441;"}],
    ...
}

2- Prepare the main JSON files

Now comes the real work: you need prepare and store your real content metadata in a number of structured JSON files which are going to be ingested by the queryEngine (provided you to tell the queryEngine where to find them). Those base input files should be a list of structured JSON objects, one per item. In our animal example, one could use as input a JSON file with one JSON object per animal:

[
{
    "id": "cow",
    "biotop": "ground",
    "morphology": {
        "nbLegs": 4,
        "skinType": "hair",
        "sound": "Moow",
        "color": ["white", "black", "brown"]
    }
},
{
    "id": "snake",
    etc...
},
...
]

This file doesn't need to perfectly match the format of the indexed table as defined in this table, but must contain at least all the information necessary to generate it. Apart from that, the format is pretty much free and the focus should be made on simplicity, completeness and consistency.

These JSON objects are then going to be scanned by the queryEngine and used for 2 different purposes: they will first be copied as-is in a binary storage file so that they can be completely retrieved later from the online API using the getEntries method of the cgi. Secondly, they will be processed by the MiniCrawler in order to assign a value to each of the fields defined in fieldsList.json and produce a flat table as defined in this table. Only this processed flat version is going to be indexed for later fast querying through the query method of the queryEngine cgi.

Once the JSON files have been created, you need to store them on your server.

3- Modify the MiniCrawler

The MiniCrawler.cpp file from the queryEngine's code needs to be modified so that it properly creates the flat table from the complete JSON objects. TODO this is going to be simplified in later versions.

4- Modify the GUI files

If you want to change the information displayed by default in the layer summary and in the detailed information panel from the paged list you will need to tune the GUI .qml files. The modified files also have to be copied in the gui/ directory from our modified Web Service.

svmt-logo.png
Generated on Fri Sep 10 15:36:04 2010 for SVMT by  doxygen 1.6.3