tim@906: \section{Model of transitions} hans@911: \subsection{Overview of Subject-Specific Configuration: From FIS, Products, States, hans@911: Transitions and SQL-statements} tim@910: hans@911: The GNV-system provides several expert information systems (FIS). Within a FIS hans@911: users can select products for analysing and visualising different hans@911: subject-specific issues like timeseries diagrams and different types of hans@911: profiles. In order to generate these products, different kind of data out of the hans@911: dataware house is needed. tim@910: hans@911: The configuration is mainly split up into two steps\footnote{Except for hans@911: integrating the MapViewer. There is a third step necessary by configuring hans@911: additional tables in the datawarehouse}: hans@911: \begin{enumerate} hans@911: \item FIS and their according products (Metainformation) tim@943: \item Products with their states, transitions, outputs and SQL-statements hans@911: (Implementation) hans@911: \end{enumerate} tim@910: hans@947: %% TODO to improve: Add a Screenshot of the GNV WebClient marking GUI elements for FIS, hans@911: %% product, states and transitions tim@910: tim@943: Main entry point for the configuration also is the file {\tt conf/conf.xml } hans@911: defining the list of FIS and the according products based on the different tim@943: datamodels in the datawarehouse. tim@943: tim@943: The provided datamodels are: tim@910: hans@911: \begin{enumerate} hans@911: \item ESRI ArcMarineBSH with following subtypes hans@911: \begin{enumerate} hans@911: \item TimeSeriesPoints hans@911: \item MeshFeatures hans@911: \item Measurements/InstantaneousPoints tim@914: \item Marine Features hans@911: \end{enumerate} hans@911: \item ESRI ArcS57, hans@911: \item CONTIS hans@911: \end{enumerate} tim@910: hans@911: Each product configuration consists of a datamodel specific configuration tim@941: organized in a product specific folder in {\tt conf/products} \footnote{The tim@941: special case of a {\tt Horizontales Schnittprofil} is configured in tim@941: {\tt conf/horizontalprofile/conf\_mesh\_cross.xml} }. The directory layout looks hans@911: like this: hans@911: hans@911: \begin{verbatim} hans@911: products/ hans@911: |-- horizontalcrosssection hans@911: | `-- conf_mesh.xml hans@911: |-- horizontalprofile hans@911: | |-- conf_instantaneouspoint.xml hans@911: | |-- conf_mesh.xml hans@911: | `-- conf_mesh_cross.xml hans@911: |-- layer hans@911: | `-- conf.xml hans@911: |-- timeseries hans@911: | |-- conf_mesh.xml hans@911: | |-- conf_timeseriespoint.xml hans@911: | `-- timegap_definition.xml hans@911: |-- verticalcrosssection hans@911: | `-- conf_mesh.xml hans@911: `-- verticalprofile hans@911: |-- conf_instantaneouspoint.xml hans@911: |-- conf_mesh.xml hans@911: `-- conf_timeseriespoint.xml hans@911: \end{verbatim} hans@911: hans@911: The subtypes of the ArcMarineBSH based datamodel are configured in the files below: tim@910: \begin{itemize} tim@941: \item TimeSeriesPoints: {\tt conf\_timeseriespoint.xml} tim@941: \item Mesh: {\tt conf\_mesh.xml} tim@941: \item InstantaneousPoints: {\tt conf\_instantaneouspoint.xml} tim@910: \end{itemize} tim@910: hans@911: Within each of these files, the steps for gathering the values for the hans@911: parameterisation are configured by defining states, transitions and outputs tim@920: (c.f. \ref{ref:config-a-product}). The definition of states, transitions and hans@931: outputs reference the actual SQL-statements via an identifier. The SQL-statements tim@941: are gathered in the file {\tt conf/queries.properties}. hans@911: tim@910: hans@947: \subsection{Background information of the XML configuration} tim@907: tim@908: It is possible to configure the GNV in many ways. tim@940: It is possible to add or remove FIS, add or remove products from a FIS or hans@947: to manipulate the steps which must be prepared until products like hans@947: a diagram or CSV-export can be generated. tim@908: tim@920: The configuration of the provided FIS are divided in three main parts. tim@908: tim@908: \begin{itemize} tim@941: \item Configuration of the list of FIS via {\tt artifact-factories} tim@941: \item Configuration of main {\tt artifacts} which will be instantiated if an tim@941: {\tt artifact-factory} was called. tim@941: \item Configuration of the different {\tt artifacts} which provides products which can be tim@907: served by the FIS. tim@908: \end{itemize} tim@907: tim@910: \subsubsection{Configuration of a FIS} tim@941: The point of entry into the system is to configure an {\tt artifact-factory}. hans@947: Each artifact-factory represents one FIS. hans@947: It is possible to configure several {\tt artifact-factories}, which hans@947: represent the list of FIS in GUI. tim@941: The {\tt artifact-factories} will be configured in the section hans@948: \texttt{/artifact-database/artifact-factories} of the configuration-file. tim@907: tim@907: \begin{lstlisting} hans@931: tim@907: de.intevation.gnv.artifacts.GNVProductArtifactFactory tim@907: tim@907: \end{lstlisting} tim@907: hans@947: At this moment the following attributes of an {\tt artifact-factory} are hans@947: configurable: tim@908: \begin{itemize} tim@941: \item {\tt name}: The name of the {\tt artifact}. Must be unique in one {\tt artifact-server} tim@941: \item {\tt description}: Short description which job the {\tt artifact-factory} has to do. hans@947: \item {\tt ttl}: The time to live: The time using milliseconds an hans@947: {\tt artifact}, created using this factory, can live without any hans@947: user-interaction. tim@941: \item {\tt artifact}: The name of the class of the {\tt artifact} which should be created. tim@908: \end{itemize} tim@907: tim@940: The next listing shows the dependencies between the FIS and the name tim@941: of the {\tt artifact-factory} which belongs to it. hans@911: hans@911: \begin{itemize} tim@941: \item Marnet: {\tt fis\_marnet} tim@941: \item IMIS: {\tt fis\_imis} tim@941: \item STAUN: {\tt fis\_staun} tim@941: \item Modeldata {\tt fis\_modeldata} tim@941: \item Iceclimatology: {\tt fis\_eisklimatologie} tim@941: \item Ice Station Report: {\tt fis\_icestations} tim@941: \item SST: {\tt fis\_sst} tim@941: \item Delphin: {\tt fis\_delphin} tim@941: \item Thermosalinograph: {\tt fis\_thermosalinograph} tim@941: \item Chemusurvey: {\tt fis\_chemusurvey} tim@941: \item GTS: {\tt fis\_gts} tim@941: \item CTD: {\tt fis\_bsh\_ctd} tim@941: \item XBT: {\tt fis\_bsh\_xbt} tim@941: \item SeaCat: {\tt fis\_seacat} tim@941: \item Sea State: {\tt fis\_seastate} tim@941: \item Current Meter: {\tt fis\_currentmeter} tim@941: \item Nauthis: {\tt fis\_nauthis} tim@941: \item Contis: {\tt fis\_contis} tim@941: \item Marine Features: {\tt fis\_marinefeatures} hans@911: \end{itemize} hans@911: tim@907: \subsubsection{Configuration of main Artifact} tim@941: For each {\tt artifact-factory} it is necessary to configure one {\tt artifact} which will be tim@940: created using the factory. tim@941: This {\tt artifact} is the representation of the specific FIS. tim@940: It contains the configuration which products will be served for this FIS. tim@907: tim@941: The {\tt artifacts} are configured in the section {\tt /artifact-database/artifacts} of tim@940: the configurationfile. tim@907: tim@907: \begin{lstlisting} hans@931: tim@907: tim@907: ... tim@907: tim@907: tim@907: \end{lstlisting} tim@907: tim@941: The key is to use the same name for the {\tt artifact} as used for the {\tt artifact-factory}. tim@940: The name has to be unique. tim@941: In the section {\tt /artifact/products} it is possible to define several products as tim@940: explained in the next section. tim@907: hans@947: \subsection{Products to an FIS} tim@940: One FIS can provide several products. tim@940: To do this it is required to configure them as shown below in the section tim@941: {\tt /artifact/products} tim@907: tim@907: \begin{lstlisting} tim@907: tim@907: tim@907: de.intevation.gnv.artifacts.GNVArtifactFactory tim@907: tim@907: tim@907: tim@907: tim@907: tim@907: tim@907: \end{lstlisting} tim@907: hans@947: Each {\tt product} is also represented by an {\tt artifact}. In order to hans@947: create this {\tt artifact}, the {\tt artifact-factory} has to be used. hans@947: It is configured in each product tim@941: ({\tt /product/artifact-factory}). tim@907: hans@947: Each product can have several parameters ({\tt hans@947: /product/parameters/parameters}). The {\tt parameter} named {\tt hans@947: sourceid} and {\tt fisname} are required parameters. tim@907: hans@947: The parameter {\tt fisname} contains the key to the name of the FIS. The hans@947: key must be unique. The parameter {\tt sourceid} contains the key to hans@947: identify the FIS in the datawarehouse. ({\tt MEDIAN.SOURCEINFO}) tim@907: tim@907: tim@910: \subsubsection{Configuration of an Product} hans@911: \label{ref:config-a-product} tim@941: The {\tt products} of the different FIS are also modeled as artifact-objects. tim@940: The different products which are currently available are stored in separate tim@941: files in the folder {\tt project}. tim@908: tim@940: In those files the workflow of each product is configured. Each step which is tim@941: required to model a new diagram is represented using a {\tt state} in the hans@947: configuration-file. tim@908: hans@947: %% FIXME: fix wording tim@941: To move between those {\tt states} it is required to model {\tt transitions} which define tim@940: between which states it is possible to move and which conditions must be tim@908: fulfilled. tim@908: tim@941: The last step is called {\tt output-state}. This state is responsible to generate the tim@941: output for the different formats which can be served from the product ({\tt Diagram, tim@941: CSV, ODV, WMS,..}.). tim@908: tim@907: \paragraph{States} tim@941: A {\tt state} is one step which is required to fetch the data for generating e.g. an tim@940: diagram. tim@908: tim@940: For example in each product it is possible to choose one or more parameters. tim@908: tim@940: To configure a state you have to use a XML-fragment as shown below: tim@908: tim@908: \begin{lstlisting} tim@908: tim@908: timeseries_parameter tim@908: parameterid tim@908: true tim@908: tim@913: ... tim@908: tim@908: tim@908: \end{lstlisting} tim@908: tim@941: At this moment the following attributes of an {\tt state} are configurable. tim@908: \begin{itemize} tim@941: \item {\tt id}: The name of the artifact. Must be unique in one artifact-server tim@941: \item {\tt description}: Short description which job the artifact-factory has to do. tim@941: \item {\tt queryID}: The id of the query which should be used to fetch the data tim@940: displayed in this state. All queries are defined in the file tim@920: conf/queries.properties tim@941: \item {\tt dataname}: The id of the data which will be displayed in this state. tim@940: The id will be use to localize the description of the data. tim@940: The localization is located in module gnv-artifacts in folder tim@934: src/main/resources. tim@941: \item {\tt data-multiselect}: {\tt true} it is possible to select 1 or more items. tim@941: {\tt false} it is possible to select only one item. tim@941: \item {\tt inputvalues}: The values which can be "feed" to this state and which tim@940: will be used as values in SQL-statements. tim@909: \end{itemize} tim@908: tim@913: \paragraph{Input Values of a State} tim@941: At section {\tt /state/inputvalues} it is possible to add definitions for inputvalues. tim@941: Those values have two meanings for the {\tt state}. tim@913: tim@913: \begin{itemize} tim@940: \item They were used to fill the SQL-statements to fetch the data. tim@913: (Each entry replace one ore more "?" ) tim@940: \item They were used to validate the inputdata which is "feed" to tim@940: the FIS in the current state. tim@913: \end{itemize} tim@913: hans@947: {\bf WARNING: The order of the input-values is significant at which position the value will hans@947: be put into the SQL-statement!} tim@913: tim@940: It is possible to add one inputvalue twice or more often to put its value at tim@920: different positions of the SQL-statement. tim@913: tim@913: \begin{lstlisting} tim@913: tim@913: tim@913: tim@913: tim@913: tim@913: \end{lstlisting} tim@913: tim@913: \begin{itemize} tim@941: \item {\tt name}: Name of the value that could be feed or should be used in SQL-statment. tim@940: The name must fit to one dataname configured in this state or one other tim@940: state which was visited before. tim@941: \item {\tt type}: The type of the value. This is required for the validation tim@940: of the value. tim@913: This might be String, Integer, Double, Date, Point, LineString, hans@945: Polygon, Coordinate, Geometry and AttributeName. \\ tim@940: Coordinate is a format which accepts geographical coordinates in hans@945: the following Syntax: 56n30 6e20 \\ tim@940: AttributeName marks a stringvalue which will be used in tim@940: SQL-statement without surrounding with "'" in the statement. tim@940: Usage is e.g. for determining the Axis (i or j) in the workflow tim@940: of Horizontalprofiles. tim@941: \item {\tt multiselect}: true if more than on value can be feed or put into the SQL-statement. tim@940: false if one on value will be accepted. tim@941: \item {\tt usedinquery}: Number how often the value should be put into the SQL-statement: tim@940: 0: Value will not out into the statement. tim@940: 1: Value will put once into the statement, tim@913: 2 or more: Value will be put as often as configured tim@940: into the SQL-statement (this is useful if tim@940: inner-selects are used) tim@913: \end{itemize} tim@913: tim@913: The next part will explain the usage of inputvalues. tim@913: tim@940: This SQL-statement is configured to use in the state above, which will fetch tim@940: all parameter-ids with the according german name which are reffered to the given tim@934: TimeSeriesPoint (e.g.Arkona Basin Buoy FeatureID = 100011 ) tim@913: tim@934: tim@913: \begin{lstlisting} tim@913: SELECT DISTINCT tim@913: p.PARAMETERID KEY, tim@913: p.GERMANNAME || ' ['|| p.UNIT ||']' VALUE, tim@913: p.GERMANNAME tim@913: FROM MEDIAN.PARAMETER P, tim@913: MEDIAN.TIMESERIES TS, tim@913: MEDIAN.TIMESERIESVALUE TSV, tim@913: MEDIAN.MEASUREMENT M, tim@913: MEDIAN.TIMESERIESPOINT TSP tim@913: WHERE M.FEATUREID = TSP.FEATUREID AND tim@913: M.MEASUREMENTID = TSV.MEASUREMENTID AND tim@913: TS.TIMESERIESID = TSV.TIMESERIESID AND tim@913: P.PARAMETERID = TS.PARAMETERID AND tim@913: TSP.FEATUREID = ? tim@913: ORDER BY P.GERMANNAME tim@913: \end{lstlisting} tim@913: hans@947: Including inputvalues, the example for choosing the FIS ({\tt fisname}) hans@947: and the Station 342 ({\tt featureid}: Arkona Basin Buoy) will look like hans@947: this: tim@913: \begin{itemize} hans@947: \item {\tt featureid}: 100011 (Marnet $\rightarrow$ Arkona Basin Buoy) tim@941: \item {\tt fisname}: fis\_marnet tim@941: \item {\tt parameterid}: not set because it's the value that should be tim@913: chosen in this state. tim@913: \end{itemize} tim@913: tim@913: \begin{lstlisting} tim@913: SELECT DISTINCT tim@913: p.PARAMETERID KEY, tim@913: p.GERMANNAME || ' ['|| p.UNIT ||']' VALUE, tim@913: p.GERMANNAME tim@913: FROM MEDIAN.PARAMETER P, tim@913: MEDIAN.TIMESERIES TS, tim@913: MEDIAN.TIMESERIESVALUE TSV, tim@913: MEDIAN.MEASUREMENT M, tim@913: MEDIAN.TIMESERIESPOINT TSP tim@913: WHERE M.FEATUREID = TSP.FEATUREID AND tim@913: M.MEASUREMENTID = TSV.MEASUREMENTID AND tim@913: TS.TIMESERIESID = TSV.TIMESERIESID AND tim@913: P.PARAMETERID = TS.PARAMETERID AND tim@934: TSP.FEATUREID = 100011 tim@913: ORDER BY P.GERMANNAME tim@913: \end{lstlisting} tim@913: tim@941: The value of {\tt featureid} will be inserted into the query because tim@941: the attribute {\tt usedinquery} is set to "1". tim@913: tim@941: The values of the inputvalues {\tt fisname} and {\tt parameterid} will be tim@941: excluded because the attribute {\tt usedinquery} is set to "0" tim@913: tim@913: tim@941: If the attribute {\tt usedinquery} of the inputvalue {\tt featureid} is set to "2" tim@913: this might happen. tim@913: tim@913: \begin{lstlisting} tim@913: tim@913: tim@913: tim@913: tim@913: tim@913: \end{lstlisting} tim@913: tim@913: \begin{lstlisting} tim@913: SELECT DISTINCT tim@913: ... tim@913: TSP.FEATUREID = ? AND tim@913: TSP.FEATUREID = ? tim@913: ORDER BY P.GERMANNAME tim@913: \end{lstlisting} tim@913: tim@913: This SQL-statement will be modified to tim@913: tim@913: \begin{lstlisting} tim@913: SELECT DISTINCT tim@913: ... tim@934: TSP.FEATUREID = 100011 AND tim@934: TSP.FEATUREID = 100011 tim@913: ORDER BY P.GERMANNAME tim@913: \end{lstlisting} tim@913: tim@913: tim@940: At the next step of the workflow it is nessesary to determine all depths where tim@940: the choosen parameters are measured. tim@940: To do this we might have the following inputvalues: tim@913: tim@913: \begin{lstlisting} tim@913: tim@913: tim@934: tim@934: tim@934: tim@913: tim@913: \end{lstlisting} tim@913: tim@934: \begin{itemize} hans@947: \item {\tt featureid}: 100011 (Marnet $\rightarrow$ Arkona Basin Buoy) tim@941: \item {\tt fisname}: fis\_marnet tim@941: \item {\tt parameterid}: 2 (Salzgehalt [pSal]) tim@941: \item {\tt measurementid}: not set because it's the value that should be tim@934: chosen in this state. tim@934: \end{itemize} tim@913: tim@913: \begin{lstlisting} tim@934: SELECT DISTINCT tim@934: M.MEASUREMENTID KEY, tim@934: M.ZLOCATION VALUE, tim@934: P.PARAMETERID PARAMETERID tim@934: FROM MEDIAN.MEASUREMENT M, tim@934: MEDIAN.TIMESERIESVALUE TSV, tim@934: MEDIAN.TIMESERIES T, tim@934: MEDIAN.PARAMETER P tim@934: WHERE M.MEASUREMENTID = TSV.MEASUREMENTID AND tim@934: TSV.TIMESERIESID = T.TIMESERIESID AND tim@934: T.PARAMETERID = P.PARAMETERID AND tim@934: M.FEATUREID = ? AND tim@934: M.FEATUREID = ? AND tim@934: P.PARAMETERID IN (?) tim@934: ORDER BY m.ZLOCATION DESC tim@913: \end{lstlisting} tim@913: tim@913: This SQL-statement will be modified to tim@913: tim@913: \begin{lstlisting} tim@913: SELECT DISTINCT tim@934: M.MEASUREMENTID KEY, tim@934: M.ZLOCATION VALUE, tim@934: P.PARAMETERID PARAMETERID tim@934: FROM MEDIAN.MEASUREMENT M, tim@934: MEDIAN.TIMESERIESVALUE TSV, tim@934: MEDIAN.TIMESERIES T, tim@934: MEDIAN.PARAMETER P tim@934: WHERE M.MEASUREMENTID = TSV.MEASUREMENTID AND tim@934: TSV.TIMESERIESID = T.TIMESERIESID AND tim@934: T.PARAMETERID = P.PARAMETERID AND tim@934: M.FEATUREID = 100011 AND tim@934: M.FEATUREID = 100011 AND tim@934: P.PARAMETERID IN (2) tim@934: ORDER BY m.ZLOCATION DESC tim@913: \end{lstlisting} tim@913: tim@942: The queries which are shown above are configurable. hans@948: Configuring takes place in the \\ file \texttt{queries.properties } which will tim@942: be explained in the next paragraph. tim@942: tim@942: \paragraph{Query-configuration (queries.properties)} hans@947: \label{ref:queries.properties} tim@942: tim@942: This file contains key-value-pairs to define SQL-statements. tim@942: All queries will be handle using the prepared-statement-syntax using "?" tim@942: to define a place where an dynamic value should be placed into the statement. tim@942: tim@942: There is one special implementation to support spatial access to the hans@947: {\tt ESRI ArcSDE}-database. This mechanism is used to realize the access to spatial- tim@942: objects. tim@942: hans@947: All queries containing the following literals will be handled separatly hans@947: using the ESRI ArcSDE-API. tim@942: tim@942: \begin{itemize} tim@942: \item {\tt ST\_ASTEXT(SHAPE)}: Will return the geometry as an WellKnowText (WKT) tim@942: \item {\tt ST\_ASTEXT(RASTER)}: Will return the raster in an readable way. tim@942: \item {\tt INTERSECTS(SHAPE,"?")}: Will only return the elements which geometry tim@942: intersects the given geometry ("?" will be tim@942: replace with an WKT) tim@942: \end{itemize} tim@942: tim@908: tim@907: \paragraph{Transitions} tim@908: hans@947: To move between two states it is necessary to configure dependencies hans@947: between the different states. This dependencies are called {\tt hans@947: transitions}. tim@908: tim@941: There are different kinds of {\tt transitions} which can be used. tim@908: \begin{itemize} tim@940: \item Transitions which only link two states tim@940: \item Transition which link two states with a additional condition. tim@908: (e.g. If a region was selected in the Regionfilter or not ) tim@908: \end{itemize} tim@908: tim@940: The listing below shows a transition with an additional condition. tim@908: \begin{lstlisting} tim@908: tim@908: tim@908: tim@908: tim@908: tim@908: \end{lstlisting} tim@908: tim@908: \begin{itemize} tim@941: \item {\tt from}: The {\tt id} of the {\tt state} which you have to come from tim@941: \item {\tt to}: The {\tt id} of the {\tt state} which can be reached. tim@941: \item {\tt condition}: The condition which have to be fulfilled. tim@908: \end{itemize} tim@934: tim@941: At this moment only {\tt EQUAL} and {\tt NOTEQUAL} are supported as tim@941: {\tt condition} for an {\tt ValueCompare\-Transition}. tim@908: tim@907: \paragraph{Outputstate} tim@907: hans@947: The {\tt outputstate} is a special {\tt state} which was created to define tim@940: the different possibilities of outputs for each product. hans@947: An {\tt outputstate} is handled as a {\tt state} which is described above. tim@909: Additionally you are able to configure which kind of outputs should tim@909: be provided. tim@909: tim@941: There are several {\tt outputstates}. Each one is designed to create tim@940: the output for one special product. tim@909: tim@915: \begin{itemize} tim@941: \item TimeSeries: {\tt TimeSeriesOutputState} tim@941: \item Horizontalprofile: {\tt HorizontalProfileOutputState} tim@941: \item Horizontalprofile on Meshes: {\tt HorizontalProfileMeshOutputState} tim@941: \item Verticalcrosssection: {\tt VerticalCrossSectionOutputState} tim@941: \item Verticalprofiles: {\tt VerticalProfileOutputState} tim@941: \item Horizontalcrosssections: {\tt HorizontalCrossSectionMeshOutputState} tim@941: \item Layer: {\tt LayerOutputState} tim@915: \end{itemize} tim@915: tim@941: All these outputstates are implemented in {\tt package de.intevation.gnv.state} tim@941: and its {\tt sub\-packages}. tim@915: hans@947: The fullqualified name of the {\tt outputstate} to the attribute hans@947: {\tt state} is shown below. tim@909: hans@947: An example for an {\tt outputstate}: tim@909: tim@909: \begin{lstlisting} tim@909: tim@909: timeseries_chart_data tim@909: ... tim@909: tim@909: tim@909: ... tim@909: tim@909: tim@909: tim@909: \end{lstlisting} tim@909: tim@941: At section {\tt /state/outputsModes} it is possible to add one ore more tim@941: {\tt outputmodes} to one state as shown in the next paragraph. tim@909: tim@909: \paragraph{OutputModes} tim@909: tim@941: It is possible to configure several {\tt outputmodes} in one {\tt outputstate}. hans@947: Inserting or deleting the configuration of a special hans@947: {\tt outputmode} will control if an item in the GUI will be displayed. tim@909: hans@947: {\bf tim@909: WARNING: IT MIGHT BE POSSIBLE THAT ONE OR MORE OUTPUTMODES ARE NOT tim@909: SUPPORTED BY AN PRODUCT. IN THAT CASE IT IS NECESSARY TO tim@909: IMPLEMENT THE REQUIRED FUNCTIONALITY BEFORE IT IS POSSIBLE tim@909: TO OFFER THIS OUTPUTMODE. hans@947: } tim@909: tim@941: Currently the following {\tt outputmodes} are supported: tim@909: tim@909: \begin{itemize} tim@941: \item {\tt chart} tim@941: \item {\tt histogram} tim@941: \item {\tt csv} tim@941: \item {\tt odv} tim@941: \item {\tt statistics} tim@941: \item {\tt wms} tim@941: \item {\tt shapefile} tim@909: \end{itemize} tim@909: tim@941: The following example shows how to configure an {\tt outputmode chart}: tim@909: tim@909: \begin{lstlisting} tim@909: tim@909: tim@909: tim@909: tim@909: tim@909: tim@909: tim@909: tim@909: tim@909: tim@909: tim@909: tim@909: \end{lstlisting} tim@909: tim@909: tim@909: \begin{itemize} tim@941: \item {\tt name}: The name of the mode. This must not be changed because it tim@941: is used by the program. tim@941: \item {\tt description}: a short description of this outputmode. tim@941: \item {\tt parameters}: one ore more parameters which will be shown in the tim@941: GUI e.g. for changing the size of an chart. tim@941: \item {\tt exportModes} : one or more formats which can be served. tim@909: \end{itemize} tim@909: tim@907: hans@947: \section{Adding a new FIS} hans@947: In this section it will be explained which steps have to be done to integrate a tim@941: new FIS into the {\tt artifact-server}. This will be done using the configuration for hans@947: a FIS which uses data from the table {\tt MEDIAN.TIMESERIES} section of hans@947: the datawarehouse (e.g. MARNET or STAUN). tim@906: hans@947: For publishing the changes to the {\tt artifact-server}, it needs to be hans@947: restarted. tim@906: hans@947: \subsection{Adding a new Artifact-factory} tim@941: First step is to add a new {\tt artifact-factory} to the configuration conf/conf.xml tim@940: To do this you have to add a new XML-fragment into the section tim@906: /factories/artifact-factories which look like that: tim@906: tim@906: \begin{lstlisting} hans@947: tim@906: de.intevation.gnv.artifacts.GNVProductArtifactFactory tim@906: tim@906: \end{lstlisting} tim@906: tim@941: In this XML-fragment you only have to replace the placeholder {\tt NEWFISNAME} tim@941: with a unique short name for the new FIS. tim@906: hans@947: \paragraph*{Example} hans@947: This example shows how to add a FIS and illustrates the effect on the hans@947: artifact-server's output. tim@916: hans@947: First , the following {\tt artifact-factory} has to be added into the file tim@941: {\tt conf/conf.xml} in section {\tt /artifact-database/artifact-factories} hans@947: adding a new FIS called {\tt justanewfis} to the server: tim@916: tim@916: \begin{lstlisting} hans@947: tim@916: de.intevation.gnv.artifacts.GNVProductArtifactFactory tim@916: tim@916: \end{lstlisting} tim@916: hans@947: Restart the {\tt artifact-database} executing: tim@916: tim@920: \begin{lstlisting} hans@947: /etc/init.d/artifact-server restart tim@920: \end{lstlisting} tim@916: hans@947: Checking if the new FIS is served by the REST-Server tim@916: calling the following command: tim@916: tim@920: \begin{lstlisting} hans@947: curl http://localhost:8181/factories | xmllint --format - | grep fis_justanewfis tim@920: \end{lstlisting} tim@916: hans@947: If the FIS was added, the new {\tt artifact-factory} will be found in the generated hans@947: XML-output. Otherwise no XML-output will be shown. tim@916: hans@947: \subsection{Adding a new Artifact for Artifact-factory} tim@940: The next step is to define the artifact itself. tim@941: For this it is necessary to add an XML-fragment into the section tim@941: {\tt /artifacts} of the main configurationfile {\tt /conf/conf.xml}. tim@941: tim@906: \begin{lstlisting} hans@947: tim@906: tim@906: ... tim@906: tim@906: tim@906: \end{lstlisting} tim@906: tim@941: In this XML-fragment it is also required to replace the placeholder {\tt NEWFISNAME} tim@941: with the name which was used to configure the {\tt artifact-factory}. tim@906: tim@941: Now the {\tt artifact-server} can handle an additional FIS without any products yet. tim@906: hans@947: To prevent needless configuration-work, it is a useful way to clone an hans@947: existing artifact handling the same kind of work. tim@906: tim@917: hans@947: \paragraph*{Example} hans@947: Now will an artifact to the FIS {\tt fis\_justanewfis}, will be configured. tim@917: hans@947: The following XML-fragment has to be added to the file tim@941: {\tt conf/conf.xml} in section {\tt /artifact-database/artifacts}: tim@917: tim@917: \begin{lstlisting} hans@947: tim@917: tim@917: tim@917: tim@917: \end{lstlisting} tim@917: hans@947: Restart the artifact-server tim@917: tim@919: \begin{lstlisting} hans@947: /etc/init.d/artifact-server restart tim@919: \end{lstlisting} tim@917: hans@947: Now it should be possible to choose the artifact. tim@919: hans@947: The listbox in the GUI would be empty. tim@919: \begin{lstlisting} tim@919: curl -d "@sample-documents/create-artifact.xml" http://localhost:8181/create | xmllint --format - tim@919: \end{lstlisting} tim@917: hans@947: \subsection{Adding/Removing Products to the Specific Artifact} hans@947: Next step is, to configure the different products which the FIS should hans@947: be able to provide. To do this it is necessary to copy the hans@947: XML-fragments of the products into the XML-element {\tt products} of the hans@947: previously integrated artifact. hans@947: tim@906: \begin{lstlisting} hans@947: tim@906: tim@906: tim@906: tim@906: de.intevation.gnv.artifacts.GNVArtifactFactory tim@906: tim@906: tim@906: tim@906: tim@906: tim@906: tim@906: tim@906: tim@906: de.intevation.gnv.artifacts.GNVArtifactFactory tim@906: tim@906: tim@906: tim@906: tim@906: tim@906: tim@906: tim@906: tim@906: \end{lstlisting} tim@906: hans@947: In this XML-fragment the placeholders {\tt NEWFISNAME} have to be hans@948: replaced. The source-id \texttt{VALUEOFSOURCEID} with the value for the new hans@947: FIS as defined in the table {\tt MEDIAN.SOURCEINFO} needs to be added. tim@906: hans@947: \paragraph*{Example} hans@947: Adding a product to the new FIS, choosing sourceid of an existing FIS hans@947: (e.g 4 $\rightarrow$ Marnet). tim@918: hans@947: Add the following XML-fragment to the new artifact. tim@918: \begin{lstlisting} tim@918: tim@918: tim@918: de.intevation.gnv.artifacts.GNVArtifactFactory tim@918: tim@918: tim@918: tim@918: tim@918: tim@919: tim@918: \end{lstlisting} tim@918: hans@947: Restart the artifact-server tim@918: tim@919: \begin{lstlisting} hans@947: /etc/init.d/artifact-server restart tim@919: \end{lstlisting} tim@919: hans@947: If tim@919: \begin{lstlisting} tim@919: curl -d "@sample-documents/create-artifact.xml" http://localhost:8181/create | xmllint --format - tim@919: \end{lstlisting} tim@919: hans@947: is called, the product {\tt timeSeries} should be available for the FIS {\tt justanewfis}. tim@918: hans@947: Now, it should be able to choose the product. hans@947: This product including the definied outputformats should be available in hans@947: the GUI. tim@918: tim@906: \subsection{Adding a new Product} tim@940: To add a new product to the system it is necessary that the required tim@941: artifact representation is implemented in the {\tt sourcecode}. tim@940: Without doing that step it is not possible to create a new product. tim@906: hans@947: All products are configured in separated files that will be included into the tim@940: main configuration using Xlink-references. tim@906: hans@947: First step is to create a new file in the folder {\tt products} and in the tim@941: sub-folder where the product belongs to ({\tt timeseries,verticalprofile, tim@941: horizontalprofile,horizontal\-crosssection,layer,...}) tim@906: hans@947: Then the new product can be referenced in the file {\tt /conf/conf.xml} in the tim@941: section {\tt/artifacts} using the following XML-fragment. tim@906: tim@906: \begin{lstlisting} tim@906: tim@906: \end{lstlisting} tim@906: tim@941: The placeholder {\tt PATHTOFILE} has to be replaced with the relative path and tim@941: the name of the file starting in the folder products. tim@906: tim@906: Then it is possible to add the product to a FIS as explained in the next section. tim@941: Please note that the defined name of the {\tt artifact-factory} has to match to the tim@940: name of the added products which is also designed as an artifact. tim@906: hans@947: \subsection{Adding an additional Product to a FIS} hans@947: To add an additional product to a FIS the XML-fragment which tim@940: represents the product to the artifact-configuration of the FIS in section hans@947: {\tt /artifacts/artifact/products} needs to be added. tim@906: tim@906: \begin{lstlisting} tim@906: tim@906: tim@906: de.intevation.gnv.artifacts.GNVArtifactFactory tim@906: tim@906: tim@906: tim@906: tim@906: tim@906: tim@906: \end{lstlisting} tim@906: hans@947: Please note that the placeholders have to be explained above.